Run the work.
Understand the resources.

1. Choose how this computer operates

Installing or opening the desktop alone does not start all the servers. Version 1.1.0 requires explicit desktop starts. Version 1.2.0 adds an explicit service-install option; service mode is never enabled without approval. Installing service mode does not convert, stop or import an existing broker automatically.

A computer normally needs its own local CPU/GPU services only if it will execute that work. A fleet normally needs one reachable coordinator, not a separate coordinator on every computer. Viewing a fleet is not the same as joining it, and joining is not the same as starting reporting.

2. What runs where?

The local GPU broker is the admission authority. The fleet server's display is not a GPU grant. Installing rBroker also does not automatically make unrelated programs use its leases or turn their work into registered CPU jobs; those programs must integrate with the supplied client/API.

3. Requirements and permission boundaries

• Native x64 Windows 10 build 19041 or later, or Windows 11. This is not a 32-bit, ARM-native or S-mode package. Minimum build targeting is not a promise that every Windows edition remains vendor-supported; current .NET support on Windows 10 is edition-specific.
• Python, Node.js and the .NET runtime are included. You do not have to install them separately for bundled Windows hosting.
• Fleet membership, system RAM/CPU reporting, CPU workers and coordinator hosting do not require an NVIDIA GPU.
• Local GPU admission supports one dedicated NVIDIA or AMD GPU, its compatible installed driver, and fresh hardware-bound telemetry. Multiple supported discrete GPUs and Intel GPU admission are not qualified. CPU work remains available without a supported GPU.
• A private fleet needs a reachable coordinator, appropriate joining/viewing credentials and trusted HTTPS for other computers. A purchase does not supply your domain, server or an included paid hosting subscription.
• Service mode uses the restricted Windows LocalService account with an ASL-specific service identity. It does not save your Windows password or run workloads as LocalSystem.
• Normal use changes no firewall, router, driver, antivirus, certificate trust or Windows security setting. If a preview installer is blocked, record the exact message; do not weaken protection to force it through.

4. First setup: run inside the desktop

1. Install and open ASL rBroker. Choose Refresh now. A fresh computer may correctly show unavailable GPU/Parallel services until you start them.
2. For CPU work, open Host & setup, choose a modest worker limit such as 1–2 on a laptop, and select Start Parallel Work. Then run Run small CPU self-test. This processes four small JSON records using actual workers.
3. For GPU work on a supported machine, choose Detect GPU, review the physical capacity and single system allowance, and select Create and start private broker.
4. If either default/selected local port already belongs to a service, stop here for that component. Connect to the existing service with its authorized configuration; do not create a competing authority.
5. If using an existing fleet, follow Connect and join. Creating a local fleet server is optional and not required to connect to our hosted server.
6. Keep the app open while its hosted components are needed. On reopening the desktop, these manual components are not automatically started again.

Desktop Stop my idle broker and Stop my idle Parallel Work affect only children started by that desktop instance. An active lease or accepted CPU job prevents normal shutdown. Unexpected loss of the owning UI tells the surviving hosts to drain new admissions while existing work finishes. Forced process termination, power loss or Windows shutdown can still interrupt work.

5. Install the optional always-running service

1. In rBroker 1.2.0, go to Host & setup → Export Windows service installer. Save to a new ZIP filename. Export prepares files only; it does not install, start or elevate anything.
2. Use Windows Extract All. Do not run setup from inside the compressed folder. Inside the extracted folder, open service\RBroker.Service.exe. Keep the complete extracted bundle together.
3. Choose Administrator setup / management. Approve Windows if you want to proceed. Cancellation is respected; the app does not repeatedly reopen the prompt.
4. Choose the components this computer should run: Parallel Work, GPU broker, optional fleet coordinator, and optional fleet reporting. GPU is not selected merely because hardware exists.
5. Set the CPU worker limit. For a GPU, use Detect supported GPU and review the single allowance. Hardware is checked again by setup; a manually supplied capacity is not blindly trusted.
6. Optionally approve one specific local read-only file folder. Blank means JSON tasks only. This approval does not grant new Windows filesystem rights; the service identity must already be able to read the folder. Do not approve a whole drive, network share or mapped drive.
7. For unattended reporting to an existing fleet, check reporting and enter its trusted HTTPS origin, a joining-enabled fleet key and a computer name. Choose resource and work-label sharing. The key is used once for joining and is not stored. The service creates its own protected identity; it does not copy the desktop's identity.
8. Select Install selected components and start automatically. Setup validates the package and selected ports, creates protected versioned files, provisions private state, registers the service and requests start.
9. Choose Refresh service status, then check actual GPU/Parallel health in the desktop with Refresh now. A Windows service marked Running is a supervisor state, not proof that every component or every GPU counter is healthy.

What installation creates

• Service name: ASLrBrokerHost; display name: ASL rBroker Background Host.
• Versioned program files: C:\Program Files\ASL rBroker Service\1.2.0.0 on a normal Windows installation.
• Protected machine state: C:\ProgramData\ASL-rBroker-Service. Windows may locate Program Files/ProgramData differently; the app uses the system's actual locations.
• Administrator-writable configuration and code. The selected Windows operator has read/client access. The ASL-specific service identity can write runtime data/logs, not its program code or configuration.
• Automatic boot startup and bounded Windows recovery attempts for supervisor failure. This is ordinary local service code, not an AI task or paid-model loop.

The service installer is a native companion. The Store package does not silently declare privileged packaged-service or elevation capabilities. Installing it is an explicit Windows administrator operation outside the MSIX; it is not proof Microsoft has certified the companion.

6. Use, configure, stop and remove service mode

Daily use

Once installed and running, you can close rBroker and the setup window. The service keeps its selected components running while the computer is awake. It starts without an interactive login at the next normal Windows boot. Sleep suspends execution/network availability; “always-running” does not override sleep, shutdown, power loss or an unavailable network.

Open Check Windows service status in the desktop. To manage it, choose Open installed service management folder, open RBroker.Service.exe, then approve Administrator setup. The normal monitor does not require an elevated desktop.

Change worker limits, components or reporting choices

1. Load existing saved service selections in its setup window.
2. Choose Drain and stop. Wait until Windows reports Stopped.
3. Change the explicit selections. Enter the joining-enabled fleet key again if reporting is selected; it was never saved. Keep the existing service operator/account.
4. Choose Apply selections to a stopped service and start it. Existing signing keys, local credentials and replay/lease state are preserved.
5. Refresh service and component status. If a settings update fails, startup is blocked by an incomplete-update marker until the intended settings are successfully reapplied. Do not remove the marker to bypass validation.

Stop safely

The service's stop command means drain: stop new GPU/CPU admissions and wait for accepted jobs/leases to finish. Windows may show Stopping while this happens. Check job owners rather than force-killing the service. A desktop idle-only stop and a service drain are different actions. The latter intentionally closes new admission while waiting.

Unexpected component exits are timestamped in the supervisor log and shown as degraded component state. The supervisor does not repeatedly recreate a failed GPU broker or scheduler over old work. Recovery checks ports and previous exact process identities; surviving children prevent a replacement. The original failure remains evidence, not something to clear by deleting the database.

Remove or restore registration

Choose Remove stopped service registration only after it is Stopped. This removes the Windows service registration and preserves versioned binaries and private state. It does not erase identities, credentials, lease/replay databases or logs. Uninstalling the desktop does not remove this independent service.

To restore the same preserved installation, choose Re-register preserved installation with its matching setup version. It verifies protected storage and package integrity and keeps existing keys/settings. This is not an automatic upgrade to different code. Retained files are explicitly preserved, not a promise of a disk-cleaning uninstall.

7. Connect and join a fleet

1. Get the coordinator's HTTPS address and an authorized fleet key from its operator. The hostname is configurable; an ASL address is optional.
2. Open Fleet, enter the address/key and Connect. A working view proves viewing permission, not joining permission.
3. Review the computer name and select Join fleet. The app sends a signed public identity. No private signing key is uploaded and no JSON copy/paste is required.
4. Joining registers membership only. On Connect this machine, choose what to share and select Start reporting for desktop-session reporting.
5. For service-mode reporting, use the service setup's reporting option instead. It owns a distinct identity and continues when the desktop closes. Do not start a second desktop reporter for the same computer unless you deliberately want separate entries.
6. Repeat on the other computers. They can be on different networks. Each node sends outbound HTTPS to the common server; no shared drive or same-subnet connection is required.

Join requires coordinator 0.5.0+ and explicit join permission on the connected key. New private servers give their creator key permission. Existing server operators can run node setup.mjs enable-join STATE_DIRECTORY FLEET_ID during a coordinator-only maintenance stop. Later authorized joins do not require a restart. Existing GPU work does not need to be stopped for joining.

Manual public JSON export/import remains available. It is an alternative onboarding mechanism, not a replacement for Start reporting. A normal instance supports up to 32 enrolled identities. Repeated Join for the same identity is idempotent; reinstalling or inventing a new identity to clear an error can consume extra membership and confuse ownership.

If you switch from desktop to service reporting, the old desktop identity is not silently overwritten. Stop the old reporter and have the fleet operator disable/remove the old membership if appropriate. Old reports should become stale/offline; do not interpret them as newly running work.

8. Host your own fleet on LAN or the internet

You can explicitly host a coordinator in the desktop, select coordinator in the Windows service companion, or deploy the standalone Node.js source on Linux. For unattended Linux hosting, use the included installation guide and systemd template. The Windows app can export the standalone server source. A local-only coordinator can be evaluated without a domain; access from other computers requires proper HTTPS setup.

1. Choose one coordinator computer/server and preserve its private state directory.
2. Desktop mode: Create private server, Start server, then View my local fleet. Service mode: select coordinator during setup; it creates the private my-fleet configuration and viewer key.
3. Configure your own trusted certificate, DNS and HTTPS reverse proxy to the coordinator's loopback port 28810. The app does not make router/firewall changes for you.
4. Publish only /health, /v1/fleet, /v1/fleet/join and /v1/fleet/nodes/{nodeId}/sync. Join is POST with a 4096-byte limit. Preserve authorization/signature headers and do not cache private fleet responses.
5. Never expose GPU port 28793 or Parallel Work port 28792 to the LAN/internet. Remote reporting is not an arbitrary remote-execution interface.
6. Distribute the private fleet key securely to authorized people. Service coordinator key location: config\server\viewer-token.txt within the protected service state folder. Do not put it in URLs, screenshots, public pages or support logs.

To begin unattended reporting to a newly self-hosted coordinator, first establish its reachable HTTPS endpoint. Then load saved service selections, drain/stop, enable reporting with that endpoint/key and apply. Selected reporting remains opt-in.

9. Run CPU work through Parallel Work

Parallel Work is a real local scheduler, not merely a CPU graph. Start it in desktop mode or select it in service mode. Its registered handlers include a small JSON task lane and approved read-only file work. A GPU is not needed.

1. Start with a modest maximum worker count. The budget is shared across concurrent jobs; requesting eight workers in two jobs does not authorize sixteen workers.
2. Run the desktop small CPU self-test only against the desktop's own host. For a service-owned host, use the documented service configuration and local client below.
3. Have each project submit a registered task type and declare its project, purpose, owner and unique session ID. The scheduler records worker PID, process creation identity, parent, job and exit evidence.
4. Use an explicit approved local folder for file tasks. A path permission error is not a reason to grant whole-drive access.
5. Keep job receipts and poll the returned job ID for its terminal result. A caller timeout does not mean its accepted job never ran.

For a Store installation, the app provides the rbroker.exe execution alias. For the standalone preview, use the installed RBroker.exe path. Save GPU and Parallel consumer instructions from the desktop for the desktop mode's paths. For service mode, replace the configuration path:

rbroker.exe --parallel-client "C:\ProgramData\ASL-rBroker-Service\config\parallel\config.json" GET /health

rbroker.exe --parallel-client "C:\ProgramData\ASL-rBroker-Service\config\parallel\config.json" GET /v1/activity

To submit work, invoke POST /v1/jobs with this JSON on standard input. Use your language's process API or an equivalent shell pipe; credentials are read locally, not inserted into the command line.

{
  "taskType": "core.sha256-json",
  "workers": 1,
  "items": [{"id": "example-1", "payload": {"message": "small test"}}],
  "work": {
    "project": "my-project",
    "purpose": "Verify one small CPU task",
    "owner": "other",
    "sessionId": "my-unique-session-id"
  }
}

The supplied client restricts operations to documented registered routes. Program work uses the separate task.program handler: an approved ZIP containing a Python program or Windows executable and its data. There is no shell command field. To inspect capabilities, request GET /v1/capabilities. Local-only work stays local. Explicitly approved fleet workflows transfer the selected input and result artifacts through the encrypted coordinator; activity reports themselves remain bounded descriptions.

10. Run a GPU workload with its own lease

A GPU lease is an owned reservation for a workload. A visible free-memory number, a fleet entry or another project's lease is not permission to use the GPU. Each integrated workload uses the official local client to obtain a fresh grant, attach its process and maintain heartbeats.

rbroker.exe --client --config "C:\ProgramData\ASL-rBroker-Service\config\gpu\config.json" launch --owner other --session-id UNIQUE_SESSION --label "Project: what this GPU job is doing" --requested-mib 4096 --minimum-mib 1024 -- PROGRAM ARGUMENTS

The example is for a service-owned broker. Use the desktop's exported configuration path for a desktop-owned broker, and your existing service's authorized client/configuration if that computer already has an independently installed broker. Do not copy another session's lease ID or capability.

• Heartbeats use the server-confirmed expiry and leave time for the HTTP request. Authentication rejection is not a transient permission to keep working.
• Capacity/admission failure must remain visible to the project. Reduce the request or wait for legitimate capacity; do not launch unleased work to “test” availability.
• Processes may hold a lease while temporarily idle between model operations. Investigate the declared purpose, process identity and owner before treating idle utilization as abandonment.
• Unknown/stale telemetry blocks new admission. A service running in Windows session 0 still needs usable driver/counter access. Supported GPU detection alone is not proof that all required telemetry works.
• No automatic job migration, cross-machine pooled VRAM, model weights or renderer is supplied by rBroker itself.

11. Understand system RAM and GPU memory

• System RAM is the computer's ordinary physical memory. It is separate from GPU VRAM. Resource reporting is not a system-wide RAM reservation or process memory limiter.
• Physical GPU RAM is the card's actual dedicated memory. Used/free readings describe physical telemetry, not ownership.
• System allowance is counted once to establish the broker-managed pool. Review it for the actual card; do not apply a 5 GiB allowance blindly to a smaller GPU.
• Lease commitments are promises already made to jobs. A grant may exceed what that job has resident at a particular instant.
• Available for a new lease is constrained by both remaining managed budget and physical free memory after accounting for outstanding promises. It is not simply total minus all displayed labels.
• Windows allocation references can overlap. They are not necessarily exclusive VRAM and must not be added as a second system reserve.

Unknown is not zero. Missing GPU telemetry should not be shown as an empty card with all memory available. Fleet reports display last-known observations and their ages; only the local broker can make a current admission decision.

12. Refreshing, stale data and background activity

Refresh now is manual. Active monitor enables a two-second refresh while the desktop is open; it is off by default. Displayed records continue aging so a stopped connection does not look permanently current.

The service and optional reporter have their own ordinary operating loops. Turning off Active monitor does not stop a service, disable jobs or stop an explicitly enabled reporter. Closing a viewer does not cancel someone else's lease. No monitoring loop calls an AI model or schedules a Codex/Claude task.

A fresh fleet report and fresh GPU telemetry are different clocks. The computer can be online while GPU data is unknown. Once reports stop, remote cards become stale/offline; their old workload names are last-known information, not proof those processes still exist.

13. Windows accounts, folders and credentials

Desktop mode protects keys for the current Windows account. Service mode has a separate machine-protected identity and access-controlled storage. Machine DPAPI is combined with restricted filesystem permissions; it is not a reason to put encrypted credentials in a shared folder.

The service runs under LocalService plus its ASL service identity. It does not automatically see your mapped drives, authenticated network shares, private profile files or interactive environment. Approving a folder permits the registered handler to use it; it does not modify Windows ACLs. Start with a small local test folder already readable by the service account. Ask an administrator for narrowly scoped read permission when needed rather than granting broad write access.

The operator selected during initial setup can read service client configuration and protected credentials. Other Windows accounts do not gain access just because they can view public health. Do not run the entire desktop as administrator as a substitute for setting proper client permissions. Changing the designated operator is an explicit administrative recovery task, not an automatic user switch.

For detailed activity from an existing service, select its authorized protected Parallel credential in the desktop. Public worker health is available without it. A fleet viewer key, fleet joining permission, local GPU bearer credential and a private per-lease capability are different permissions.

14. Troubleshooting by symptom

Where the error evidence is

Desktop Diagnostics & help displays occurrence times and guidance. Its private diagnostics preserve child start identity, stdout/stderr and exits. Service supervisor events are in data\supervisor.log beneath the service state directory, with a bounded previous log. Component logs and ownership journals are under the corresponding data subfolders. Service component state is also recorded in data\status.json; it is a last-written record, not a live health promise.

Native setup errors are timestamped in the approving account's Local AppData folder under ASL\rBrokerServiceSetup\setup.log. The setup window displays the path. Windows Service Control Manager events can help identify startup/account failures before a child starts. Do not post whole private directories or raw credentials when seeking help.

15. Recovery, updates and backups

1. Identify which installation owns the work: existing shared service, desktop host or new service companion. Record the version and error time.
2. Check current lease/job ownership before disruptive actions. Public free memory does not justify deleting another process's reservation.
3. For an installed companion, drain/stop before applying settings or changing its registered code. Let accepted work finish; do not bypass the drain with a forced kill.
4. Keep configuration, identity, encryption material and replay/sequence state together. Do not restore an old replay database during a routine code rollback.
5. A failed first setup retains evidence. Re-run the exact matching bundle with the same intended selections to resume an incomplete provisioning step. If package integrity differs, stop and get the matching intact bundle; do not overwrite it with unrelated files.
6. A completed, removed service can be re-registered from its verified preserved installation. Different-version upgrades require an explicitly tested maintenance procedure; the desktop does not silently update an independent running service.
7. Repairing a desktop installation does not migrate or delete the service's state. Removing the service registration does not erase the retained state or program files.

Do not use a backup of encrypted files without its matching key or assume a DPAPI identity is portable to another machine. Backups and screenshots containing private fleet information need the same access restrictions as the live state.

16. What is shared, and what is not?

Before explicitly starting a reporter, no fleet telemetry is published. Joining sends the public computer/key identifiers, public signing key, selected display name and proof of possession to the selected coordinator. Private signing keys remain local. The coordinator stores membership in an encrypted ledger.

Opted-in reports contain computer identity, health, lease grants/owners/session IDs, worker activity and selected resource/work descriptions. They do not include prompts, model files, job input/results, environment variables, process command lines, local filesystem paths or local GPU bearer credentials. Labels are supplied by projects: do not place secrets or customer records in them.

The coordinator operator controls access, retention and backups. Removing an identity/report does not erase every operator backup. Exported desktop diagnostic summaries intentionally omit private paths and credentials; the private logs contain more detail and need review before sharing.

The desktop/service do not include advertising, AI-model calls, automatic cleanup, pooled cross-computer VRAM, automatic job migration, arbitrary remote command execution, fan control or driver installation. Ordinary machine/service operation consumes local CPU/RAM and network traffic, not AI tokens. Microsoft, Windows and other software apply their own policies.

17. Check that your installation really works

• Confirm the installed version. Do not expect the 1.2 service feature in a 1.1 app.
• Desktop mode: verify manual startup, one small CPU task, displayed status and safe idle stop.
• Service mode: verify Windows reports the intended service/account/start type, check each selected component, close the desktop and confirm the service remains running.
• Confirm only the intended components own the local ports. Do not intentionally start a second GPU broker or scheduler.
• For fleet reporting, check the specific service/desktop identity becomes online with real resource data. Then stop its reporter/service safely and verify the card ages to stale/offline.
• Submit one tiny registered CPU job before a heavy workload. Keep its receipt and owner/session details.
• Only test GPU admission through an owned official-client lease, on supported hardware with fresh telemetry.
• Do not reboot a busy shared machine just to test boot startup. Schedule that physical acceptance when its users/workloads allow it. Unit/package tests do not replace this real-machine check.

Windows 11 OMEN tests, Windows 10 laptop tests, service session-0 tests, package validation and Microsoft Store certification are separate acceptance gates. A successful install or Store upload must not be described as proof all these gates passed.

18. Support and source references

Contact support@autosecurelogin.com. Include app/service version, Windows edition/build, hosting mode, component, exact error time and a safe summary. Describe whether work is still active. Do not include viewer/joining keys, private signing files, bearer tokens or whole private state folders.

Get help without exposing your fleet

Use the subject ASL rBroker — brief description of the problem. Tell us the result you wanted and the result you actually saw. For example: “This laptop joined successfully at 14:10 MDT, but its fleet card still says offline after Start reporting.” That is more useful than “it does not work,” and it helps distinguish enrollment, reporting and local execution.

1. Open Diagnostics & help. Note the displayed app version and, if applicable, the separately installed service version. An updated desktop can coexist with an older companion; report both.
2. Record the exact error wording and occurrence time, including timezone. Say whether it happened once, after every start, or only while other work was running. Describe when it last worked.
3. Use Save safe diagnostic summary before closing the app. This session history is not a permanent system-wide incident log. Review the exported file before attaching it.
4. If sharing a screenshot, crop to the relevant error. Hide names or work labels you consider private, and keep fleet keys, paths and unrelated windows out of the image.
5. Say whether an active job, GPU lease or independent service is still running. Support must know this before suggesting a stop, repair or configuration change.

You can copy this checklist into your email and fill in only the fields that apply:

Product: ASL rBroker
Desktop version / service version:
Windows edition, build and x64 architecture:
Mode: desktop hosting / Windows service / existing service / viewer only
Component: GPU / Parallel Work / reporting / coordinator / desktop
What I expected:
What happened, including exact error text:
First occurrence / most recent occurrence and timezone:
Last known successful action:
Steps that reproduce it:
Active work that must not be interrupted:
Safe diagnostic summary attached: yes / no

Never email a fleet/viewer key, local bearer token, private signing key, encrypted credential file, whole ProgramData/LocalState folder, database backup, full process command line, customer files or AI prompts. Encrypted files are still sensitive. The ordinary support workflow does not require your Windows password, payment-card details or permission to disable antivirus. If more detailed logs are needed, agree on a narrow, reviewed excerpt first.

For problems with a customer-operated fleet's permissions or server availability, contact that fleet's administrator as well. ASL support does not automatically have access to another operator's server or the authority to release their jobs. For a Microsoft Store purchase or payment issue, use Microsoft's purchase support; do not include payment information in technical logs. No response-time or round-the-clock support guarantee is implied by this guide.

Product: rbroker.autosecurelogin.com. This guide is included offline and can be printed. Runtime licenses are included beside it.

• Microsoft: Store capability and elevation/service restrictions
• Microsoft: LocalService account and permissions
• Microsoft: .NET Windows service hosting

19. Your first ten minutes: make one thing work

A new installation is intentionally quiet. The main window is a control panel, not a promise that every optional component is running. Start with the smallest useful setup, confirm its result, then add the next part. You do not need a server on the internet, a GPU or a second computer for the first CPU check.

Path A: this computer will do local CPU work

1. Open rBroker and leave Active monitor off initially. Select Refresh now. System RAM should become a real reading; missing local services should be identified as unavailable, not fabricated as healthy.
2. Open Host & setup. Set Maximum concurrent worker slots to 1 or 2. This is a starting point for a light test, not a claim that your hardware can safely run every task at that concurrency.
3. Choose Start Parallel Work. If rBroker says a scheduler already exists, use that installation's authorized client instead of trying other ports to create another budget.
4. Choose Run small CPU self-test. This uses real local workers on four tiny records. It does not benchmark a model, open your files or allocate GPU memory.
5. Refresh the local view and check the worker health. After the test completes, an idle count is expected. Save the consumer instructions if you will connect a project. Stop the idle app-owned worker host when finished if you do not want it running.

Path B: this computer will only view an existing fleet

Get the HTTPS address and viewer key from your fleet administrator. Open Fleet, enter them and choose Connect / refresh fleet. You can stop here. Viewing does not require creating a computer identity, joining, starting GPU/CPU hosts or sharing this computer's data. Disconnect forgets the viewer key held by this window; it does not unenroll computers.

Path C: this computer should appear in a fleet

Complete Connect, then Join fleet, then choose sharing options and Start reporting. Each step has a different purpose. A successful Join without a running reporter can leave an enrolled computer offline. A reporter without a local GPU broker can still publish independent computer presence and opted-in system RAM/CPU information.

What success looks like

For local CPU work, success means an accepted job reaches a terminal result and the workers are healthy afterward. For fleet reporting, success means the correct named identity has a recent report on the intended server. For GPU work, success requires an owned lease and a correctly supervised workload; a green health card alone is insufficient. Do not add heavyweight training, rendering or file scans until the relevant small check succeeds.

20. Two computers, one fleet: a complete walkthrough

Imagine a home workstation and a laptop at another address. The workstation may have an NVIDIA GPU; the laptop may have no supported GPU. They can belong to the same fleet because both contact the same reachable HTTPS coordinator. They do not need a shared drive, VPN, matching Windows account or inbound connection to each other's GPU/CPU ports.

Step 1 — establish the shared destination

Use an existing authorized fleet or host one using the server instructions. The operator supplies an address such as https://fleet.example.com and a joining-enabled key. The example is a placeholder, not a working service. An ASL product purchase does not automatically create a private hosted fleet or give every buyer access to ASL's internal computers.

If the coordinator is on the workstation, its default 127.0.0.1:28810 address is not reachable from the laptop: loopback always means “this computer.” A trusted HTTPS reverse proxy and reachable name provide the shared address. An administrator must handle server publication separately; rBroker does not open router ports or weaken a firewall automatically.

Step 2 — join the workstation

In Fleet, connect using the supplied address/key. Set a recognizable name such as Home workstation and select Join fleet. Wait for a successful response. Then open Connect this machine, confirm the reporting destination, choose resource/work-label sharing and Start reporting. Return to Fleet and refresh. The named computer should appear with a recent report. No GPU lease should be created merely by joining.

Step 3 — join the laptop

Repeat with a different friendly name such as Travel laptop. Use the same fleet address and a key authorized for that fleet. The laptop creates its own private identity; do not copy the workstation's private files to it. If it has no supported GPU, an unavailable GPU section is normal. Resource sharing can still show system RAM and CPU, and local Parallel Work can still execute supported registered tasks.

Step 4 — prove you are seeing new reports

Refresh the fleet on either computer and inspect the report age for both identities. Stop only the laptop's reporter, leaving its local CPU host alone if needed. Its fleet information should age rather than remain permanently current. Start its reporter again and check that the same identity becomes current. Do not mistake an old workload label on a stale card for evidence that the job still exists.

Step 5 — choose execution separately

Start the local GPU broker only on an eligible, previously unmanaged GPU machine. Start Parallel Work on each machine that should accept local registered CPU jobs. Integrate each project on the computer where it actually runs. Joining a laptop does not cause a workstation's model to move to it or let a GPU-less laptop reserve the workstation's card through the fleet display.

Step 6 — make selected computers unattended, if needed

Service mode is useful on a machine expected to keep reporting or hosting when nobody is signed in. Install the optional companion deliberately and select only the components it should own. Do not install it on top of active desktop hosts. Coordinate a safe idle stop first, and recognize that the service reporter has its own identity. Keep the laptop in desktop mode if you prefer work to be explicitly started during each session. “Same fleet” does not require every member to use the same hosting mode.

21. Read the dashboard: worked examples

System RAM is not GPU RAM

A computer with 64 GiB of system RAM and a 16 GiB graphics card has two different memory resources. Free system RAM cannot simply be added to the card's VRAM lease budget. Windows “shared GPU memory” also must not be presented as extra dedicated card capacity. rBroker reports system memory; it does not impose a system-wide RAM quota on all applications.

MiB and GiB are binary units: 1 GiB is 1,024 MiB. An advertised decimal GB number can differ from Windows or driver readings without memory being missing. Compare like units and the same timestamp before diagnosing a discrepancy.

A single-allowance GPU example

This example uses made-up readings, not your current computer. Suppose physical GPU capacity is 32,768 MiB, the configured system allowance is 5,120 MiB, and active commitments total 8,192 MiB.

1. The managed pool is 32,768 − 5,120 = 27,648 MiB.
2. The remaining policy budget is 27,648 − 8,192 = 19,456 MiB.
3. Physical telemetry supplies a separate safety ceiling. If physical free memory is 18,000 MiB and outstanding promises not yet backed by physical use total 2,048 MiB, that ceiling is 18,000 − 2,048 = 15,952 MiB.
4. The new-lease amount cannot exceed the smaller ceiling: 15,952 MiB in this simplified example, assuming fresh consistent telemetry and all other admission checks pass.

The system allowance was used once, in step 1. It is not subtracted again from the already-free physical reading in step 3. Desktop allocation references are not another automatic reserve. Additional non-budget conditions, such as draining, exclusive access or unreliable telemetry, can still prevent a grant even when this arithmetic is positive.

Why a lease and utilization can disagree

A job may reserve 8 GiB, load a model using 6 GiB, briefly use little GPU compute while reading input, then resume. Its lease is a promise; GPU utilization is an instantaneous measurement. Neither low utilization nor unused portions of a valid grant authorize another project to take the lease. Inspect the owner, attached process creation identity, label, heartbeat and expiry together. PIDs alone can be reused after a process exits.

Worker slots are not CPU percentages

Four worker slots means at most four scheduler-controlled worker slots are budgeted together. It does not mean the entire PC is restricted to 4% or four cores, and unrelated software can still use CPU, RAM and storage. Heavy disk tasks may saturate an external drive with fewer workers. Start small and increase only after observing responsiveness, job completion and storage behavior.

Online, healthy, idle and current are different

Online refers to recent contact. Healthy refers to a component's reported checks. Idle means no reported active work at that observation. Current means the observation has not aged beyond its freshness rules. A computer can report online while its GPU broker is unhealthy, or a healthy worker service can be idle. A previously healthy card can become stale without a new error response ever arriving.

22. Connect a project or AI coding tool correctly

rBroker does not read an AI conversation and automatically discover the purpose of its processes. The integration must declare that information. Use Save GPU and Parallel consumer instructions for an app-owned installation, or the authorized service configuration in the CPU and GPU examples. Confirm which installation owns the local ports before handing configuration to a project.

Give a project these non-secret instructions

• The local hosting mode and authorized configuration location on that same computer. A path on one PC is not proof the same path exists on another.
• A readable project name, a specific purpose such as “Generate product turntable preview,” the appropriate owner category, and a unique session identifier.
• The amount of GPU memory genuinely required, or the number of Parallel workers appropriate for the registered task.
• The requirement to keep receipts, handle rejected admission visibly, supervise heartbeats and release only its own lease.
• The approved local input folder when using registered file handlers, without granting broad drive access.

Do not paste private bearer tokens, per-lease capabilities or fleet keys into prompts, repository documentation or command histories. A correctly authorized local client reads its protected credential itself. The viewer key used to see a fleet is not a substitute for the GPU client's credential.

GPU client parameters are a contract

requested-mib expresses the desired grant; minimum-mib must be an amount the workload can actually run within. Do not copy the example's smaller minimum into a model launcher that cannot adapt to a smaller grant. If the program always needs 4,096 MiB, request a compatible minimum rather than accepting 1,024 MiB and exceeding it. rBroker coordinates participating programs; it is not a driver-level memory sandbox that makes arbitrary over-allocation impossible.

The supervised launch must wrap the real long-lived workload, not only a shell that immediately starts an unrelated detached GPU process and exits. The integration needs a reliable relationship between the lease owner, supervisor and actual workload process. A project that bypasses this relationship can produce misleading ownership or an early release.

CPU task lifecycle

Submit the supported task type and work metadata, retain the returned job ID, and use the documented status/result routes until the job reaches a terminal state. A network or caller timeout does not prove that no job was accepted. Check the existing receipt before blindly resubmitting the same work. Job inputs/results stay local; sharing work descriptions does not upload them to the fleet server.

What another AI task is allowed to infer

A successful status request means that request worked. It is not proof that an authenticated lease request will succeed. A fleet report shows last-known information, not remote execution permission. An idle-looking GPU does not authorize a shared-service restart, database deletion or another project's lease release. Report the exact rejected operation and time to the local operator instead of bypassing the authority.

23. Troubleshoot in the right order

First identify the layer that failed. Checking in this order avoids reinstalling an extension, changing a firewall or restarting a shared service when the actual problem is a missing host, wrong credential or stale view.

1 — is the expected local component running?

Refresh the local page. If this is a new desktop installation, check Host & setup for an explicit start result. If service mode is installed, check Windows service status and the health of each selected component. If only the coordinator was selected, unavailable local GPU/Parallel ports are expected. If an independent service owns those ports, record its identity and use its supported configuration; rBroker's app-owned stop buttons must not take it over.

2 — does the failure affect viewing, joining or reporting?

If Fleet cannot Connect, first check the configured HTTPS address and authorized viewer key. If Connect works but Join fails, inspect joining permission and the server's Join response. If Join works but the computer stays offline, check Start reporting, the reporting address, identity and sharing selections. These are separate operations with separate evidence. Repeatedly creating a new identity is not a connectivity repair.

3 — is the clock and HTTPS path trustworthy?

Signed requests depend on reasonable computer clocks. Check Windows date, time and timezone on both endpoints if reports are rejected around a time change. An HTTPS certificate warning is a server-name, certificate or trust problem to fix with the operator; do not disable validation. A company proxy, captive portal or unstable Wi-Fi can interrupt reporting even while a local worker continues normally. Test the exact configured destination, not an unrelated public homepage.

4 — what did the specific request return?

For 401, stop treating the credential as valid; verify endpoint, account and credential scope. For 403, have the operator check authorization. For 429, respect the stated rate, capacity or drain restriction. For 503, record the service's storage/mutation evidence and time. A successful read-only health call does not cancel a failed write-path result. Preserve the error before performing a maintenance action.

5 — is this a reporting problem or a workload problem?

If local job receipts and leases are healthy but a fleet card is stale, investigate the reporter/coordinator path without restarting working CPU/GPU hosts. If the local authority is rejecting heartbeats or admission, a green remote card from earlier is not evidence of recovery. Both failures can happen together, but the evidence must identify which request failed and where.

When to stop troubleshooting and contact support

Stop before deleting a database, rotating keys, changing broad folder permissions, killing unknown PIDs or restarting a shared authority with accepted work. Use the support checklist and email support@autosecurelogin.com. Include the earliest useful error and latest recurrence, not just the newest secondary failure. Never deliberately reproduce a system crash or GPU out-of-memory event to collect a screenshot.

24. Daily operation and planned maintenance

At the beginning of work

Confirm the intended computer, installed version and hosting mode. Refresh status, inspect current owners, and check the age of fleet reports. Start only components that are not already managed. Confirm the application you are about to run is using its own integration and identity. If the PC feels slow, compare system RAM, CPU/worker activity and storage activity separately; GPU free memory alone does not explain whole-PC responsiveness.

Before closing or signing out

In desktop mode, keep the owning app open while its work is needed. A refused close is telling you work still depends on it. In service mode, closing the viewer should not stop the independent service; check its actual status rather than assuming an open window is required. Signing out, sleep and a full Windows shutdown are different events. The service survives sign-out by design, but no software can continue executing on a powered-off computer.

Before changing the service configuration

Tell local workload owners that new admissions will stop, then use Drain and stop. Wait for Stopped and preserve relevant job receipts. Change only intended selections and reapply. A failed reporting Join can leave an incomplete-update guard; fix the cause and reapply rather than removing that marker. The setup requires the joining key again because it does not save that shared secret.

Before installing a newer desktop or companion

Save the diagnostic summary first, then close the desktop normally when its owned work permits. A desktop update does not automatically replace a separately installed service. Record both versions and follow the release's service upgrade instructions. Do not copy new executables over the currently running Program Files installation or restore an older replay ledger to make a version change appear successful.

After maintenance

Verify the selected components individually, run a tiny permitted CPU job if appropriate, and confirm signed reporting uses the expected identity. Check that admission has reopened before asking projects to resume. Keep the prior release and protected evidence until the new version's relevant acceptance checks pass. A Store certification result, a unit test and a real boot-cycle check prove different things; none should be silently substituted for another.

25. Frequently asked questions

Is this just a monitor?

No. The Windows package includes local GPU admission, real CPU workers and optional coordinator/reporting components. They run when explicitly started in desktop mode or when explicitly selected in an installed service. A viewer-only setup is also supported.

Do I need to leave a terminal or a separate server window open?

Not for app-owned hosting: rBroker owns those background processes, and its desktop window remains the session owner. For the optional installed Windows service, neither the rBroker window nor a terminal needs to stay open. An independently installed older broker still has its own lifecycle until deliberately migrated.

Must I run the whole app as administrator?

No. Normal monitoring, viewing and desktop hosting use ordinary user permissions. Installing or managing the optional machine service requires explicit administrator approval. Running the entire app elevated does not repair wrong credentials or missing folder permissions.

Does joining start GPU or CPU jobs?

No. Join registers a signed public computer identity. Reporting is a separate opt-in action. Jobs are submitted separately by integrated local projects. Joining does not give the fleet server a remote shell or permission to steal another lease.

Can every computer use my 32 GiB card at once?

Membership does not pool or remotely export VRAM. Work using that card must run on its computer and obtain its own local grant. Concurrent local workloads may be admitted when the broker's current constraints permit; the fleet screen itself never grants capacity.

Why does an inactive project still have a lease?

A valid supervised workload can be temporarily idle, and a failed cleanup may also leave evidence that needs investigation. Check the exact process identity, last heartbeat, expiry and owner before deciding. Do not release it solely because utilization is low. The owning integration is responsible for correct release on completion.

Does turning off Active monitor save AI tokens?

There are no AI-model calls in that timer. Turning it off reduces dashboard refresh activity; it does not stop selected service components, reporter loops or jobs. rBroker itself does not create recurring Codex or Claude tasks.

Where is the fleet key, and can support give me one?

The fleet operator controls its keys. For a coordinator you created in the desktop, use the explicitly labeled private key control. The service coordinator's protected key location is documented above. There is no universal public key for all customers, and ASL support cannot issue access to a private third-party fleet.

Will it work with AMD, Intel or no GPU?

The core fleet and CPU features do not require NVIDIA hardware. The bundled GPU admission path supports one dedicated NVIDIA or AMD card with usable driver telemetry. NVIDIA uses NVML plus Windows counters; AMD uses hardware-bound DXGI identity and Windows memory counters. AMD engine utilization uses fresh Windows counter samples; missing rates and memory-bandwidth utilization are shown as unavailable. An explicitly selected existing GPU Session Broker 1.3.2 can supervise media work without installing a second GPU authority.

Will uninstalling erase all my information?

Service removal deliberately retains protected state and files, and uninstalling the desktop does not remove its independent service. Server backups and reports are controlled by the coordinator operator. Consult the privacy/recovery sections before deciding what to retain or delete; removal is not advertised as a secure erasure tool.

Can someone use my graphics card to make pictures without asking me?

No. Picture jobs reach your computer only after you set up your own image program, enable pictures on your worker, tick pictures in your computer's permission and the fleet's manager gives a named sender permission. You can withdraw your permission at any moment with Block new fleet work locally.

How do I send a picture job without writing code?

In Master Suite 0.4.16 or later, use Fleet workflows and choose the work type Make pictures from a prompt (section 37, Sending picture jobs). The receiving computer's owner must have set up their own image program and allowed pictures.

Does rBroker come with an image generator or AI model?

No. rBroker carries picture jobs, checks them, reserves graphics memory and delivers the results. The image program and its model are yours to choose, install and license (sections 37 and 38).

What happens to fleet work if my internet drops for a minute?

Nothing is lost. Since 1.4.7 rBroker keeps all saved work, shows when it will try again and carries on by itself once the fleet server can be reached. It only pauses for your review when a job's outcome is genuinely uncertain.

Can I use it without internet access?

Offline help and authorized local GPU/CPU work do not require a cloud AI service. Fleet viewing/reporting requires access to the selected coordinator, which can be on a properly configured local network. Internet loss can make a remote fleet stale without proving local jobs stopped. Microsoft Store installation/licensing and external support follow their own connectivity requirements.

26. Plain-language glossary

Broker / admission authority

The local service that decides whether a new GPU memory promise can safely be made. It does not perform the rendering itself.

Lease

A time-limited, owned reservation. Its owner must maintain the required heartbeat and release it when the workload ends.

Heartbeat

A periodic request confirming that a lease owner is still present. Fleet reports also occur periodically, but a fleet report is not a GPU lease heartbeat.

Coordinator / fleet server

The shared destination that authenticates membership and collects signed computer summaries. It can be customer-hosted and need not run on every fleet member.

Reporter / publisher

The selected local component that sends this computer's signed summary to its configured server.

Node / identity

A registered reporting identity with its own key. Friendly names are labels; copying a name does not copy ownership. Desktop and service reporters have distinct identities.

Viewer key / joining permission

A secret that authorizes fleet viewing; the operator must separately enable its ability to enroll computers. It is not a local GPU token.

Loopback / localhost

An address that reaches only the computer making the request. Another computer's localhost is not your workstation.

Worker slot

A unit in Parallel Work's shared concurrency budget, not a whole-machine CPU or RAM limit.

Drain

Stop accepting new work while waiting for previously accepted jobs or leases to finish. This can take time without the program being frozen.

LocalService / session 0

The restricted Windows account and non-interactive session used by the companion. Your signed-in desktop and mapped drives are not automatically available there.

Fail closed

Refuse a new grant or unauthorized operation when safety or ownership cannot be verified, instead of guessing that it is safe.

Replay state

The record that prevents an old signed report from being accepted as new. Rolling it back independently of keys and other state can compromise that protection.

MSIX / service companion

The Windows desktop app package / a separately installed native Windows service. Updating one does not automatically update the other.

Prompt

The short written description a picture job carries, for example a lighthouse on a rocky point at dusk. Up to 1,000 characters.

Image program / picture generator

The program that turns a prompt into pictures on the computer that makes them. It belongs to that computer's owner; rBroker does not include one (sections 37 and 38).

Withheld picture

A picture the image program's own safety check held back. It is never delivered.

Try-again wait

After the fleet server or the worker could not be reached, the pause before automatic fleet work tries again: one minute at first, doubling up to fifteen minutes while the outage lasts. Saved work is kept the whole time.

Still unsure which term or step applies? Email support@autosecurelogin.com with the exact screen and the result you want. You do not need to know the internal component names to ask for help.

27. Computer consent and named dispatcher permissions

Three different choices, not one blanket approval

Join fleet enrolls this computer's public identity. Start reporting shares the resource/work summaries you selected. Allow with these limits saves this app user's separate local consent policy and asks the connected coordinator to record it. None of these choices gives a viewer the right to run arbitrary commands. For task execution, the computer's consent and the fleet owner's grant to a named dispatcher must both permit the work, and the local GPU/CPU authorities must still accept that individual job.

A dispatcher is a specifically identified application or orchestrator, such as studio-ai-hub. It is not a random session number and it is not whoever happens to know the viewer key. Give it a name you recognize. Each task must also carry its real title, project, purpose, stage and expected result; a dispatcher name is not a substitute for a useful work description.

Approve a computer with explicit limits

1. Connect to the intended HTTPS fleet on the Fleet page and join this computer if it is not enrolled. Check the server address and friendly computer name. The private signing identity remains protected on this computer; do not export or copy it.
2. In What may this fleet ask this computer to do?, select the registered work types you intend to permit. The current controls offer JSON echo, JSON hashing, separately enabled program bundles, separately configured NVIDIA/AMD shape animation, and pictures from a prompt with your own separately configured image program (section 37). General programs require their own explicit opt-in. These controls do not download tools, approve arbitrary folders or start an executor.
3. Set separate per-job ceilings for GPU RAM in MiB, system RAM in MiB and worker slots, plus the maximum simultaneous jobs. These are permission ceilings, not memory reservations or measurements. A CPU-only policy can have GPU RAM set to zero. A high value does not manufacture hardware capacity or bypass the local broker.
4. Choose an expiry from 1 to 720 hours, then press Allow with these limits. The app saves your local choice before sending anything. It records the exact pending request before delivering it. Permission is not locally available while that delivery remains unresolved.
5. Read the result beneath the controls: last local change, server revision, last server confirmation, actual saved limits and expiry. The form fields are new proposed limits; the saved-policy text describes what was recorded. A local policy confirmation is still not a lease, accepted job or permission from a dispatcher.

Consent has a fixed expiry and is not silently renewed by opening the app, enabling the monitor or refreshing status. At most one server origin is locally active for this app identity. Approving a different origin blocks previous origins locally; return to those previous fleets and use refresh/send to withdraw any remaining recorded permission there. A changed fleet ID at the same address or a changed computer key cannot inherit the old approval.

Block immediately, including while offline

Block new fleet work locally needs neither a viewer key, manager key nor network connection. It remains available while a permission request is sending. The app commits the local opt-out before reporting that it succeeded. A delayed acknowledgement from the earlier approval cannot undo that newer local Block. Blocking does not terminate accepted jobs, release another project's lease or stop a running GPU broker or Parallel Work service.

The server may still display its older permission until it hears the withdrawal. Reconnect to the affected fleet and choose Refresh / send pending change. The app reads the signed server state, reconciles the exact request already saved, and sends a revision-bound withdrawal where needed. Do not interpret an old server display as proof that local Block failed. Conversely, if local storage could not be safely saved, the app reports an error and does not claim that a block succeeded. Preserve the error, time and protected state rather than deleting the journal.

Give a named dispatcher narrower permission

1. Obtain the fleet's separate permission-manager key from its owner. The viewer/join key cannot substitute for it. Paste it into the manager field; it is held only in memory and cleared on disconnect or close, never saved in preferences or a pending-action record.
2. If this app hosts the coordinator itself, use View my local fleet, then Use my local server's manager key. This reads only the explicitly provisioned key from this app's protected server folder. It does not search other accounts, services or machines.
3. Select Read manager permissions, then choose the enrolled computer and named dispatcher. Inspect the displayed computer-consent record and the selected dispatcher's existing grant, including revisions and limits. This is a last-fetched server snapshot; an offline local opt-out can be newer.
4. Review the policy fields above. Grant selected limits above uses those exact selections for this explicit manager action. The effective permission is the intersection of the computer's and dispatcher's allowed work types and ceilings; neither can widen the other. Withdraw selected dispatcher grant removes that dispatcher's server grant without modifying other dispatchers.
5. Each manager action is saved before sending. If delivery is interrupted, use Retry saved manager change after reconnecting with the manager key. It reuses the saved request identity; it does not silently approve a fresh set of limits. Read permissions again before making another change.

Set up an owner-managed coordinator

For a new app-owned server, first create its private configuration under Host & setup. While that coordinator is stopped, use Set up separate permission manager and Add this named dispatcher. Existing keys are never replaced by these buttons. They create separate purpose-specific credentials in the protected server folder but do not display secrets, grant computer consent, create a task or reserve resources. Start the coordinator explicitly afterward. The app does not stop it automatically; GPU brokers and CPU workers need not be stopped for this configuration step.

For Linux or another remotely hosted coordinator, its owner performs the equivalent offline setup there using the included fleet/setup.mjs commands enable-execution-manager and add-dispatcher. This is private server administration, not a fleet API that a viewer can invoke. Keep encrypted permission state and its storage key with the other protected server state. Never restore an old permission ledger merely to recover an earlier approval.

The trusted HTTPS reverse proxy must explicitly allow the optional signed POST routes /v1/fleet/nodes/{nodeId}/execution-status and /v1/fleet/nodes/{nodeId}/execution-consent, the separately authenticated manager GET/POST route /v1/fleet/execution-permissions, and the dispatcher POST route /v1/fleet/execution-check where needed. Keep the existing fleet/reporting routes. Preserve method restrictions, body limits, TLS and credentials; never expose local GPU or Parallel Work ports. This app does not change firewall rules, proxy configuration or certificate trust for you.

Recover from the exact state shown

• Not read in this window: choose Read saved local consent. Opening the app does not launch a permission helper or contact a server automatically.
• Pending delivery / timeout / unavailable: the saved action is unresolved, not approved by assumption. Local Block is available. Reconnect and explicitly refresh/send, or retry the saved manager action. Do not create a second conflicting grant.
• HTTP 401 or 403: authentication was rejected. There is no automatic retry with another key. Confirm the enrolled computer identity or separate manager credential with the owner. Do not copy another computer's protected identity or use a lease token as a fleet key.
• HTTP 404 / unsupported permissions: the server may be older than 0.6.0, not configured for permissions, or missing the optional proxy route. Joining/reporting can still work. Ask the owner to check the actual deployed version and route; local Block remains usable.
• HTTP 409 / changed revision: another action changed the record or the pending request became too old. Local consent remains blocked and the conflicted action is not automatically widened or renewed. Read current records and make a new explicit approval only if the displayed limits are still what you intend.
• Clock disagreement or expiry: verify the computer/server clocks. Expired permission is denied. A refresh does not extend the expiry; renewed permission requires a new explicit approval.
• Local save/identity error: no successful permission change or Block is claimed. Preserve the existing private files. Do not delete the journal, rotate keys, restore old state or stop shared workloads to make an error disappear.
• Another permission update is sending: one app instance owns the sender lock. Its request has a bounded timeout. Wait for it to finish or use local Block. A leftover lock filename after a process exits does not itself retain ownership.

These controls apply only to this app's current-user identity. They do not silently alter the optional LocalService reporter identity, import another product's private state or grant service-account access. Current local workloads and separately installed services keep their own authority and lifecycle. For help, email support@autosecurelogin.com with the app/coordinator versions, action, displayed state, exact time and whether another permission window was open. Never send the manager key, seed, DPAPI files, database or full state folder.

28. Receive described work and recover it safely

What must already be connected?

The computer must be enrolled under its own protected identity, reporting a current snapshot, and connected to the intended fleet. Its local consent must be confirmed, and the fleet owner must grant the named dispatcher compatible limits. The owner must explicitly enable the optional job ledger using enable-job-delivery on a stopped, supported coordinator; see the source job-delivery guide. The proxy must allow the authenticated dispatcher offer/read/cancel routes and signed node poll/read/check/claim/settle routes under /v1/fleet/. Never expose the local worker or GPU ports to the internet.

Start this app's own Parallel Work host explicitly or use its reviewed binding to an existing compatible worker. Current execution refuses older workers that cannot retain work descriptions and required resource commitments. It does not borrow another account's credentials or take over an existing machine service. If another authority is already running, preserve its current work; do not start a competing scheduler just to test this preview. The dispatcher must use the typed API and separate dispatcher credential. This screen receives offers; use AI Hub or Master Suite to compose the workflow and choose final destinations.

Read the task before you start it

1. On the Fleet page, select Read fleet offers. This is a one-time read, not an automatic execution loop. Choose the task and inspect its title, project, purpose, stage and expected result. A session number is only a secondary reference; it cannot replace the description.
2. Select Claim selected offer. The app saves the exact pending claim before sending its signed request. A claim reserves ownership of this attempt, not GPU memory or CPU threads. If the reply is lost, use Read saved local work and Retry saved claim. The original attempt is reused; a new competing owner is not created.
3. Select Start selected work. The app checks current ownership, consent, dispatcher permission, installed handler support and currently available system RAM. It then commits its local submission record before the single request to Parallel Work. The canonical worker admits shared CPU-worker and declared system-RAM commitments. GPU media also requires its own GPU lease. RAM admission is scheduling accounting, not a physical-page pin or a quota on unrelated applications. Program jobs have additional process limits.
4. Select Read progress / save result. The app reads only the saved local job ID. Once the worker is terminal and its allocation is released, the app validates the expected result for that handler and retains the recovery record. A program ZIP or media file still needs verified transfer and final delivery.
5. Select Send stopped receipt. Only stopped evidence allows the fleet ownership record to settle. A lost receipt response can be reconciled without running the job again. Its time is the coordinator's observation after the local result was saved; local worker timestamps remain in the private result record. A receipt digest is not a transferred file or assembled final deliverable.

Understand the saved state and the next safe action

Block, disconnect, close and failure

Block new fleet work locally does not wait for the fleet network request. It changes the same local generation checked by submission. A submission already committed locally may finish; Block never kills another process or releases its lease. Disconnecting the viewer also does not prove that work stopped. Read the protected local records after reopening. Normal close waits for the bounded helper action; accepted worker jobs remain subject to the existing safe-close rules.

HTTP 401/403 means authentication was rejected, not permission to try another person's key. HTTP 409 requires ownership, policy or revision reconciliation. A timeout or service outage never triggers an automatic submission retry. Whole-response deadlines also cover a stalled body. A corrupt, inaccessible or full journal fails closed and preserves the existing data. Use Archive selected verified finished work only for eligible settled work with confirmed result availability. It retains protected receipts and output files; it does not erase replay evidence or uncertain attempts. Current Windows direct-transfer acceptance is separate from unqualified platforms and arbitrary creative applications.

For help, email support@autosecurelogin.com. Include the app, coordinator and worker versions; readable task title; displayed state and last-recorded time; and the action you took. Never attach private input/result contents, keys, DPAPI files or the whole journal. Existing GPU jobs, fleet members and unrelated services should not be restarted as a troubleshooting shortcut.

29. Independent products, one described workflow

Use the current direct-transfer versions in the opening checklist and the compatible bundled Parallel Work engine. An older deployed server can still supply a fleet view while refusing newer permissions, jobs or transfer routes. Check each actual version; do not assume the web guide installed an upgrade.

rBroker works by itself: start selected local hosts, run supported CPU work, admit integrated GPU clients, and operate or join a fleet. AI Hub adds readable multi-step planning, approval, dependencies and verified delivery. Steward adds diagnostics and explanations without granting resources. Master Suite embeds their native workspaces and engines in one separate product; it does not require the three standalone programs or launch their desktop windows.

Each product keeps its own protected profile. Installing Suite does not copy a standalone key or authorize a second broker. If the GPU or worker port already has an owner, connect to that authority and leave its jobs running. A viewer connection, fleet membership and execution permission are three different states.

1. Enroll each node with Join fleet; review its name and the information being shared. JSON export/import remains an optional administration path. Private signing keys stay local.
2. Configure the node's allowed dispatcher, supported handlers, resource ceilings and expiry. Approve compatible dispatcher permissions at the coordinator. Neither permission alone is sufficient.
3. In AI Hub or Suite, save and review a plan with a title, project, purpose, stage and expected result for every step. Select actual capable nodes and required input/output destinations. IDs are secondary correlation details, never the task description.
4. Approve that exact saved plan and advance it. The node executor checks current ownership and obtains local resources before doing work. A queued or claimed step is not an active GPU grant.
5. Read the stopped receipt and final delivery state. A renderer exiting successfully is not proof the file reached the chosen laptop folder.

The current registered handlers support bounded JSON work, hashing, general CPU program bundles and the reviewed shape-animation/media path. They are not an unrestricted remote command facility or an automatic installation of arbitrary creative tools. A local media encoder is explicitly selected and checked; third-party tools, models and provider usage have separate availability and licensing requirements.

30. CPU slots, system RAM and GPU RAM

The canonical worker admits CPU slots and declared system RAM under one shared budget before accepting a managed job. It retains that commitment until the owned worker allocation stops. This is scheduling admission, not a claim to pin physical pages or constrain unrelated applications. New managed work refuses an older worker that cannot enforce the declared reservation. Older callers remain visibly unreserved rather than receiving a fabricated RAM guarantee.

GPU RAM is a separate graphics-card resource. Supported media work also obtains an owned, time-limited GPU lease and attaches the exact process identity. A task cannot borrow another session's lease. Reserved MiB, actually observed dedicated usage, Windows allocation references and system RAM must not be added together.

For example, the OMEN development card reports 32,607 MiB physical memory. One 5,120 MiB Windows allowance leaves a 27,487 MiB managed ceiling. That same allowance is not deducted again as a second physical-free buffer. Active commitments and any separately justified admission constraint are shown with their reasons. This is the OMEN policy, not a promise of a 28 GB grant on a smaller card or every customer installation.

Heartbeat retries must fit within the server-confirmed expiry, including the HTTP timeout. A 401/403 authentication rejection is not a temporary stall: stop the owned workload safely. Missing or inconsistent telemetry is unknown, not zero usage. Inspect ownership, process creation time and the latest measurement rather than releasing a seemingly idle PID's grant from another app.

31. Inputs, results and interrupted transfers

Approved workflow input and result data uses separate fleet/job/artifact-scoped authorization. Files travel through an encrypted direct connection between the two authorized computers. The coordinator keeps bounded manifests and connection messages, never new file payloads. The receiver checks the complete digest before publishing the final file without silently replacing an existing destination. Resource admission does not authorize arbitrary file access.

When a connection breaks, reopen the original workflow and resume its original transfer. Confirmed chunks are reused. If a sender loses the acknowledgement, it asks for the original transfer's state rather than assuming the upload failed and rendering again. A partial output is not shown as a delivered final product.

A dependency becomes eligible only after its required predecessor output is verified. A laptop may receive the finished work from a GPU workstation even when they are on different networks: both computers contact the configured HTTPS coordinator and establish a direct UDP connection. Keep both apps open until delivery is verified. Restricted networks may prevent the direct connection; the saved transfer remains resumable and never falls back to a server upload. Keep local GPU/worker ports private.

Allow sufficient disk space on the sending and receiving computers. File chunks are 256 KiB and data-channel frames are at most 16 KiB. Connection messages are limited to 16 KiB. The ASL discovery endpoint exchanges network addresses only; no TURN relay is used. Previously accepted server files remain available for read-only recovery. Older apps must update before publishing new files.

Unknown submission, damaged storage, identity drift and an unconfirmed stop remain visible recovery states. Preserve the original attempt and journal. Do not delete private state to turn an uncertain operation into an apparently empty queue. Terminal node history can be archived through the reviewed administration path; protected replay evidence remains. AI Hub's explicit workflow archive requires verified destinations and preserves output files.

32. Service upgrades and portable nodes

The optional Windows service runs selected components as LocalService, independently of an open desktop. It has its own identity, configuration and explicit CPU-only execution consent. It does not import the user's provider keys, enable a GPU-media executor automatically, or move interactive fan control into Windows Session 0.

1. Review the new package and preserve the existing service's private identity/configuration securely. A public enrollment JSON file alone is not a private-key backup.
2. Use Drain and stop on the service you own. Wait for accepted jobs and exact child processes to stop. Do not terminate other projects to make an upgrade test pass.
3. Run the newer service management companion and approve Windows when requested. The reviewed upgrade transaction checks the stopped registration, process identity, protected paths and complete payload before switching versions.
4. The replacement remains stopped until its upgrade is verified. Existing selections and identities are retained; new components and executor permissions are not silently enabled.
5. If interrupted, retain the pending record and resume the intended transaction. Do not delete its marker, rotate identities or point an older writer at newer data. Refresh actual component health after the deliberate start.

Linux headless nodes use the same signed outbound protocol with protected owner-only profiles and Linux resource observations. They are not a Windows desktop running remotely. Earlier Linux/Windows acceptance used the older transfer protocol. The current direct-transfer release requires the matching peer runtime on each computer; it does not claim new Linux or macOS acceptance. A Windows-targeted build does not prove an offline Windows 10 laptop passed, and Apple scaffolding is not tested macOS support. Customer installation, permissions and hardware remain explicit checks.

33. Troubleshoot the failing layer

• Viewer works, execution does not: verify the deployed coordinator supports jobs, the correct routes are enabled, the node reports freshly, and both local consent and named-dispatcher permission are current. Never replace a viewer key with someone else's private node key.
• Task queued with free GPU memory: inspect requested CPU slots, system RAM, handler availability, telemetry age and ownership state. Free GPU bytes do not satisfy every requirement.
• 409 conflict: preserve the original request and reconcile its attempt/revision. Do not create duplicate work to bypass the conflict.
• Lease heartbeat or authentication failure: inspect the exact rejection time and stopped outcome. Do not prolong the lease locally or restart shared infrastructure simply to clear the screen.
• Result exists but is not delivered: check scoped transfer status, destination space and verification. Resume missing chunks; do not rerun a completed workload merely because delivery was interrupted.
• Old green status: compare sample time and expiry. Stale, unknown and snapshot-only do not mean idle or healthy now.

For a new installation, first run the small local CPU self-test, then a small described fleet job with verified output. Observe the readable title on both nodes, verify the returned digest, and confirm CPU/RAM commitments and any test GPU lease are released. Test a deliberately interrupted transfer using non-sensitive sample data before a valuable production job. Service installation/start-after-sign-out is a separate Windows approval and acceptance step.

Email support@autosecurelogin.com with product/node/coordinator versions, readable task title, first and most recent occurrence with timezone, exact visible error, and last successful stage. Review any export before sending it. Never email tokens, private signing keys, full journals or customer inputs/results merely to explain a status number.

34. Program bundles and larger payloads

In AI Hub Companion or Master Suite, choose Run a program with its data in Fleet workflows. Select a ZIP of up to 16 GiB, the relative .py or .exe entry point, one argument per line, the relative files to return, and time/RAM limits. Review the bundle size and SHA-256 before approving the plan. One bundle uses one worker; independent steps may target different computers. A single fleet job can contain up to eight independent bundles within the same 16 GiB total.

The receiving computer must explicitly select Allow program bundles and its fleet manager must separately grant that named dispatcher task.program. Membership, an upgrade, or old JSON consent does not enable programs. Python is bundled; executable dependencies must be included in the ZIP. Programs have the worker Windows account's access, so approve only trusted programs. Windows process limits constrain CPU, RAM, logs and runtime; they are not a security sandbox.

Input and output travel in 256 KiB resumable chunks. The former inline JSON limit does not apply to bundle bytes. Expanded input is limited to 32 GiB; declared output files total at most 16 GiB plus two 1 MiB logs. Available storage on the two computers can impose a lower limit. The coordinator has no new bulk-data upload path in direct-transfer mode. Keep sufficient local disk space for retained input chunks, the verified bundle snapshot, expanded files and returned ZIP. Interrupted transfer resumes the original job; never create a replacement to clear an uncertain execution. Completion requires the program tree stopped and the complete output digest verified. Retained files are not automatically deleted.

35. NVIDIA, AMD and CPU work

Choose Encode NVIDIA shape animation or Encode AMD shape animation in the dispatcher and separately allow that handler on the receiving computer. In Local GPU media setup, select the matching GPU backend, trusted local FFmpeg and existing broker configuration. NVIDIA uses NVENC; AMD uses AMF. A backend mismatch or missing encoder fails without falling back to CPU. Both use the same encrypted direct transfer and verified output delivery.

Parallel CPU programs keep their own worker and system-RAM reservations. General program ZIPs remain CPU-only. These fixed GPU animation handlers do not turn an arbitrary Blender scene into a distributed render. New GPU broker setup is for an unmanaged computer only; existing broker configuration and leases remain authoritative.

36. Quick CPU join and first delivered result

1. On the worker, open Connect this machine, enter the fleet address and join key, review the computer name, and choose Join as a CPU worker. It reuses the protected identity and starts the bundled worker with all logical processors but one, or connects to a compatible owned worker. It does not authorize folders, programs or GPU media.
2. On Fleet, review the desired handler, worker/RAM ceilings and expiry. Save Allow with these limits. The fleet manager must separately grant the named dispatcher the compatible limits. Enable automatic fleet execution only after those records are confirmed.
3. In AI Hub or Suite's Fleet workflows, connect using the separate dispatcher key. Start with one harmless JSON step, one worker, modest RAM, a readable purpose and a new final output folder. Add the step, save the private draft, read the plan, then approve it.
4. Choose Run / reconcile one pass in the dispatcher. Watch the same task title and original attempt on the node. Confirm the verified final output and released worker/RAM commitment. Both applications must stay online through direct delivery.

If fleet status works but files wait, check that both endpoints use compatible versions and can establish a direct connection. Restrictive NAT/firewalls can prevent it. Restore permitted connectivity and resume the original transfer; there is no coordinator bulk-data fallback. A .blend file may be data inside a trusted CPU program ZIP, but the built-in GPU handlers do not render arbitrary Blender projects or split them across GPUs.

Review free space for chunks, input snapshots, expanded data and results. Set the dispatcher's Maximum returned data in MiB (1–16384) to match the expected result; its 2048 MiB default is lower than the maximum. Choose a new output filename because unrelated existing files are never silently overwritten.

37. Pictures from a prompt: a plain-language guide

New in 1.4.7

A picture job is a short written description, called a prompt, that someone in your fleet sends to a computer. For example: a red bicycle leaning against a white brick wall, morning light. The computer turns the description into one to four pictures and sends them back. rBroker can now carry these jobs between the computers you have connected.

Who does what

Think of a print shop where you own the printer.

• You, the computer's owner, decide whether your computer makes pictures at all, which image program it uses, how much of your graphics card it may use and which senders may ask. Nothing happens until you switch it on.
• The sender (rBroker calls this a dispatcher) writes the prompt, chooses the shape and how many pictures, and receives the finished files. A sender only reaches your computer after you allow picture jobs and the fleet's manager gives that named sender permission.
• rBroker carries the request, checks it, reserves graphics memory for exactly that job, starts your image program, checks every file it produces and delivers the pictures straight to the sender over an encrypted connection.

What rBroker does not include

rBroker does not contain an image program or an AI model, and it never uses anyone else's computer or image program. You bring your own: for example a Stable Diffusion XL setup that you, or the person who looks after your computers, installed under its own licence terms. Section 38 tells that person exactly what the program has to read and write so rBroker can run it. If you do not have such a program, leave picture jobs switched off; everything else in rBroker works without it.

What you need

• A Windows computer with an NVIDIA or AMD graphics card that can give this job 14,336 MiB (about 14 GB) of graphics memory, and about 18 GB of the computer's main memory (system RAM) while a picture is made. These amounts are fixed for picture jobs so that a job never starts on a computer that would run out of memory part-way through.
• rBroker's GPU broker on this computer (section 10). It is what reserves the graphics memory; without it there is no picture work.
• Your image program, installed with its own copy of Python, and its script (a file whose name ends in .py) that follows section 38.
• A connection to a fleet (section 7), and the fleet manager's agreement to let a named sender use your computer for pictures.

Switch it on, step by step

1. Open Host and setup and scroll to Pictures from a prompt · your own generator.
2. Choose Choose and validate my picture generator. Three file windows open one after another. Pick the python.exe that belongs to your image program, then the image program's script (.py), then this computer's GPU broker configuration file (the same one GPU media uses). rBroker checks that the files exist and that the broker configuration is for this computer. It does not run your program yet and does not reserve any memory.
3. When the message says Local paths validated and saved, tick Enable pictures when I next start this app's private Parallel worker.
4. Start the worker with Start Parallel Work. If it was already running, stop it while it is idle and start it again so it picks up the new setting.
5. Open Fleet. In What may this fleet ask this computer to do?, tick Pictures from a prompt with my own generator. Enter at least 14336 for GPU memory and 18432 for system RAM, one job at a time, and an expiry, then choose Allow. This is your computer's own permission; you can withdraw it at any moment with Block new fleet work locally.
6. Ask the fleet's manager to give the named sender permission for pictures on this computer (section 27). Until they do, no sender can reach it.
7. Turn on automatic fleet execution when you want jobs picked up without pressing a button for each one.

What happens when a picture job arrives

1. Your computer checks the job against your permission: the right sender, the right kind of work, within your memory limits and before the expiry.
2. rBroker reads the prompt. Prompts that ask for sexual or nude pictures, or for children in revealing situations, are refused before anything starts.
3. If the graphics card is busy with other work, the job waits for room instead of failing. It holds nothing while it waits. After an hour without room it gives up without having used the card.
4. When there is room, rBroker reserves exactly the job's graphics memory and starts your image program.
5. Your program draws the pictures. rBroker then checks every file: the right size, the right number, unaltered, and belonging to this request.
6. The pictures travel directly from your computer to the sender, encrypted. The fleet server never receives them.
7. rBroker releases the graphics memory as soon as your program finishes. Nothing stays reserved between jobs.

On a fast graphics card a job usually takes from a few seconds to a minute or two. Loading the image program and its model often takes longer than drawing the pictures.

Safety, and what stays your responsibility

rBroker refuses the prompts described above before your program starts. Your image program should also run its own safety check on every picture it makes. When it holds a picture back, rBroker delivers only the others; when it holds back every picture, the job ends with nothing delivered. You remain responsible for what your computer produces, for your image program's licence and for the law where you are. Only allow senders you trust.

Privacy: who sees what

• The fleet server sees the job's readable title, which begins with the first part of the prompt (up to about 160 characters), the sender's name, your computer's name and the job's progress. It never sees the pictures.
• Your computer sees the whole prompt, because it has to make the pictures.
• A copy of each finished result stays in rBroker's private storage on your computer: choose Open my private configuration folder, then open image and outputs. Delete old results there when you no longer need them.

Switch it off

To stop accepting picture jobs straight away, choose Block new fleet work locally, or allow your permission again without the picture box ticked. To stop the worker offering pictures at all, untick Enable pictures and restart the worker while it is idle. A job already being made finishes first; nothing is cut off half-way through a picture.

When something does not work

Short outages no longer stop your computer's fleet work

Before 1.4.7, one failed check (for example while your internet connection dropped for a moment) stopped automatic fleet work until you switched it on again. Now, when the only problem is that the fleet server or this computer's worker could not be reached, rBroker keeps all saved work, shows the time it will try again, waits a minute and carries on. If the outage lasts, it waits longer each time (two minutes, four, eight, up to fifteen) so it does not flood the server. Anything else, such as a job whose outcome is uncertain, still pauses and waits for you to review it, exactly as before.

Sending picture jobs

In plain words: from Master Suite 0.4.16 (and AI Hub Companion versions that list it), you send a picture job from Fleet workflows like any other step: pick the computer, choose Make pictures from a prompt (on that computer's own image program), describe the picture, choose the shape and how many, choose the folder, then save, read, approve and run the plan. The pictures arrive in your folder as pictures.zip, which Windows opens like a folder.

1. In Fleet workflows, connect with your dispatcher key and describe the workflow.
2. Choose the computer, then the work type Make pictures from a prompt. The fixed resources (one worker, 18,432 MiB system RAM, 14,336 MiB GPU) are filled in for you.
3. Type the description (3 to 1,000 characters), anything to leave out (up to 300), the shape and 1 to 4 pictures. A prompt that would be refused is explained straight away and never added.
4. Choose the output folder, add the step, save the draft, read the plan (it shows the exact prompt) and approve it.
5. Run one pass or turn on automatic progress, and wait for delivered.

Technical: the step offers media.sdxl-image with inline data of exactly prompt, avoid, shape and count under the item result; the app checks it with the same rules as rBroker's media-image.mjs before saving, and rBroker's offer validation, the coordinator and the receiving computer check it again. The result is received over the encrypted peer connection and verified before it is saved. Programs and websites can also send picture jobs with rBroker's picture tool (fleet/picture-job.mjs in the rBroker source). Whoever sends needs a dispatcher key from the fleet's manager and permission for pictures on the chosen computer.

38. For whoever installs the image program: the picture contract

This section is for the person who installs or writes the image program. The computer's owner does not need it to switch pictures on. rBroker works with any image program that follows these rules; nothing ties it to one model or one company.

How rBroker runs the program

For each job rBroker first reserves the graphics memory, then runs:

python.exe -I your_script.py oneshot --request REQUEST.json --out FOLDER

with two settings in the program's environment: ASL_GPU_LEASE_ID (the reservation) and ASL_GPU_GRANTED_MIB (how much graphics memory was reserved). The program must stay within that amount and finish within 900 seconds; otherwise rBroker stops it and the job fails. -I means the program does not see the worker's own Python settings, so its own environment must hold everything it needs. Keep the model on local disk; a job should not need to download anything.

What the request contains

REQUEST.json holds exactly four values:

{"prompt": "a red bicycle leaning against a white brick wall, morning light",
 "avoid": "text, watermark",
 "shape": "landscape",
 "count": 2}

• prompt: 3 to 1,000 characters.
• avoid: what to leave out, 0 to 300 characters.
• shape: square (1024 x 1024), portrait (832 x 1216) or landscape (1216 x 832). Pictures must be exactly that size.
• count: 1 to 4.

What the program must write into FOLDER

1. result.zip with stored (uncompressed) entries: 1.png, 2.png and so on for each kept picture, numbered from 1 without gaps and in that order, then recipe.json. The recipe may hold anything useful for making the same pictures again (seed, settings, model), but its prompt and shape must equal the request. At most 64 MiB.
2. summary.json, at most 16 KiB:

   {"schemaVersion": 1, "shape": "landscape", "width": 1216, "height": 832,
    "accepted": 2, "withheld": 0,
    "model": "your-model-name", "modelRevision": "a1b2c3",
    "safetyChecker": "your-checker-name", "safetyCheckerRevision": "d4e5f6",
    "generatorSha256": "SHA-256 of your script",
    "pictures": [
      {"file": "1.png", "sha256": "SHA-256 of 1.png", "seed": 1234, "renderSeconds": 4.4},
      {"file": "2.png", "sha256": "SHA-256 of 2.png", "seed": 5678, "renderSeconds": 4.3}]}

   accepted is the number of pictures in the zip and withheld the number your safety check held back. Model and checker names use letters, digits, dots, dashes, slashes and underscores. SHA-256 values are 64 lower-case hexadecimal characters.

How the program should finish

• Exit code 0: at least one picture is in the zip.
• Exit code 3: your safety check held back every picture. Nothing is delivered and the computer's record says so.
• Any other exit code: failure. rBroker never falls back to the processor and never delivers partial output.

Check it by hand before allowing jobs

1. Write a REQUEST.json like the example above into an empty folder.
2. From a command prompt, run the command above with your own python.exe, pointing --out at another empty folder.
3. Open result.zip: it must hold the numbered PNG files and recipe.json, stored rather than compressed.
4. Check each PNG's SHA-256 (for example certutil -hashfile 1.png SHA256) against summary.json, and that width and height match the shape.
5. Watch the graphics memory it uses. Picture jobs reserve 14,336 MiB, so the program must fit inside that amount.

39. Send documents for redaction: a plain-language guide

New in 1.4.8

A document job sends one file, a PDF or a Word .docx, from your computer to another computer in your fleet, has that computer remove the personal identifiers in it, and brings the redacted copies back. Social security, taxpayer and employer numbers, bank routing and account numbers, payment cards, phone numbers, e-mail addresses, dates of birth, street addresses with their city, state and ZIP, people's names next to those identifiers, and any names, addresses or employers you list are replaced by typed markers such as [REDACTED_SSN]. Dollar amounts, line items and totals are kept, so the result is still useful for review.

What you get back

Every document comes back three ways beside a small batch.json: <name>.redacted.txt, <name>.redacted.pdf and <name>.redacted.docx. A Word document's .docx is your document with its formatting kept and the identifiers replaced in place, including headers, footers, comments, tracked changes, text boxes and the file's author and company properties; its .pdf and .txt are plain reconstructions of the same redacted text. A PDF's three copies are all reconstructions of its text and filled form fields, one page per original page, so nothing that was drawn, scanned or hidden on the original pages can travel with them. A scanned page with no text layer is reported as needing OCR and is never guessed. Pictures inside a Word file are kept unread and counted in the report.

Where the document goes, and what stays where

• The document travels directly from your computer to the chosen computer over an encrypted peer connection. The fleet server carries only the job description, hashes and the connection hand-shake; it never holds a byte of the file. The connection is negotiated so that two computers on the same network use that network, and a computer elsewhere is reached over the internet by the same code. batch.json records, for each document, which path the send and the return actually used.
• The document leaves your computer under a neutral name (doc-01, doc-02); its real name stays in batch.json on your computer only.
• The program on the other computer redacts in a private workspace, overwrites and deletes the original there before it finishes, and returns only the redacted files and a counts report. After your computer has verified and received the result it sends that computer a shred job for its remaining copies; a sweeper on each computer shreds anything a sender never purged after two hours.
• Every delivery is verified by hash against the computer's stopped receipt before it is unpacked.

Who does what

• Each computer's owner allows program bundles in Fleet > What may this fleet ask this computer to do? (the Allow program bundles box, with the computer's own RAM, worker and expiry limits). Nothing is accepted without that.
• The fleet's owner issues this computer a dispatcher credential at the coordinator and grants that named dispatcher program work on each target computer (section 27). A viewer or join key is not a dispatcher credential.
• You, sending, paste the credential once into Send documents or files to a fleet computer for processing (it is saved in this app's private storage and never shown again), press Refresh computers, choose the documents, optionally list names, addresses and employers that must always be removed, and press Send and redact on the fleet. Leave Send to on its first entry and the nearest accepting computer is chosen for you: one last reached over your own network before one last reached over the internet.

When no fleet computer is available

Run on this computer instead runs the identical program here with the bundled Python, under the same conditions a node applies. It needs no credential and sends nothing anywhere. Use it to check what the redaction does before trusting a batch to the fleet.

Technically

The card drives the bundled fleet\document-job.mjs with the bundled Node (send, local, nodes, init) using a private config under this app's storage; the program is fleet\programs\redact-documents (pypdf as a pinned wheel fetched at send time and verified by SHA-256, everything else standard-library Python). Each document is one task.program job: a zip of the program, the wheel, the renamed input and the optional terms.json, offered through the coordinator and pulled by the node over the direct transfer of section 31. The node's executor verifies the bundle hash, runs the entry point in a contained process tree with the job's RAM ceiling, packages only the declared outputs, settles the attempt, and serves the result zip for this computer to pull. The headless node from source (windows\headless) and the command line in docs\document-jobs-and-shred.md use the same files; the Shred leftover job files button and the half-hourly sweep call the same sweeper the headless node runs.

40. Host a fleet for your own network: plug and play

New in 1.4.9

Until now a fleet needed a server somewhere with a public name, a trusted certificate and a reverse proxy before two computers in the same room could share work. Version 1.4.9 lets any computer running rBroker be the fleet's hub for the computers around it. One press on the hub, one paste on each other computer, and documents or CPU work can be sent between them. No public name, no router change, no certificate to buy.

On the computer that will be the hub

1. Open Fleet and find Host a fleet for my LAN. The LAN HTTPS port is 28443 unless you change it; it must differ from the loopback port of this app's private server.
2. Press Host a fleet for my LAN. The app creates its private server if there is none, mints this hub's own certificate and credentials, starts the server on the LAN port with that certificate, and shows an invitation: one line that starts with rbroker1:.
3. Press Copy invitation and give the line to the person whose computer should join, the way you would hand over a key. It carries the join key: do not post it anywhere public, and clear clipboard history afterwards.

The hub is also a member of its own fleet. Send documents on the Fleet tab already uses the hub's dispatcher, so the hub can send documents the moment another computer joins. The hub grants its own dispatcher on every computer that joins and allows work, automatically, and renews those grants while the app runs. Hosting stops when this app closes; a hub that must stay up without a signed-in desktop runs the same coordinator from the service companion or the headless node, with setup.mjs host-lan as described in the technical part below.

On each computer that joins

1. Open Fleet > Connect this machine. Paste the invitation into Invitation from the hub's owner.
2. Press Join with this invitation. The app tries the hub's addresses in turn and keeps only the one that presents the certificate the invitation names. It joins, allows CPU jobs and program bundles from this fleet's granted dispatchers for 30 days with this computer's own RAM and worker limits, and starts automatic execution.
3. That is all. The hub notices the new computer within a minute and grants its dispatcher. Block new fleet work locally on the Fleet tab withdraws the permission at any time.

A Linux computer joins the same way

The portable Linux node accepts the invitation on join: pass {"invitation":"rbroker1:..."} on its standard input instead of a key. It pins the hub's certificate, points itself at the hub address that answered, and joins once; allow then records what the computer may do, as before. See portable/README.md.

What makes it safe

• The hub's certificate is its own. No public authority can vouch for a computer called 192.168.1.197, so the hub signs its own certificate, and the invitation carries that certificate's SHA-256 fingerprint beside the join key. A joining computer connects once, compares what the hub presents with the fingerprint, and only then saves the certificate as the single authority for that address. Every later connection from that computer, in the app, in the bundled Python and in the bundled Node, is verified against the saved certificate and nothing else. A hub that presents a different certificate is refused, and a self-signed server nobody pinned is refused as it always was.
• The pin belongs to one address. Trust for https://192.168.1.197:28443 says nothing about any other name or port. Pins live under this app's private storage (%LOCALAPPDATA%\ASL\rBrokerTrust); deleting a pin file withdraws the trust.
• Keys never travel in the open. The hub's private key stays in its private server directory; the manager and dispatcher credentials it minted are owner-only files; the invitation is handed over by you. Every job, document and result still crosses the encrypted peer connection of section 31 directly between the two computers; the hub carries only descriptions, hashes and the hand-shake.
• Consent is still each owner's. Joining with an invitation grants 30 days of CPU and program work with this computer's own limits, visibly, and the owner can block it at once. Nothing gives the hub the other computer's GPU, files or accounts.

When it does not work

Technically

The button runs the bundled fleet\setup.mjs host-lan against the app's private server directory: join permission for the fleet key, an execution manager, a dispatcher named hub-<fleet>, job delivery, the artifact store, the peer catalogue, a STUN server and a tls entry naming a certificate minted by host\fleet_tls.py (ECDSA P-256, ten years, subject alternative names for every non-loopback IPv4 address, the host name, 127.0.0.1 and localhost). Each part is added only when missing, so pressing again changes nothing. The coordinator then listens on loopback as before and on every interface at the LAN port with that certificate; the same routes, limits and signatures apply on both. setup.mjs invitation encodes the origins, fleet, join key and fingerprint as base64url JSON after rbroker1:. The pin is one PEM file per origin, named by the SHA-256 of the normalized origin, under %LOCALAPPDATA%\ASL\rBrokerTrust (or ASL_RBROKER_TRUST_ROOT); the app's HTTP clients, fleet_trust.py and fleet/trust.mjs read the same files, so the C# app, the Python node scripts and the Node dispatcher agree on what is trusted. The hub grants its dispatcher with the manager credential it minted (task.program, core.echo and core.sha256-json, 32 GiB RAM and 16 workers as ceilings the member's own consent limits further, 30 days, renewed every 45 seconds while hosting). The headless node and the Linux node use the same join with an invitation.

41. Use rBroker from an AI assistant: the MCP server

New in 1.4.10

rBroker includes a small MCP server (Model Context Protocol, the way AI assistants such as Claude Code or Claude Desktop are given tools). Once registered, an assistant on this computer can ask which fleet computers accept work, send documents for redaction, run the redaction here, read what was sent, and read this computer's rBroker health. It does nothing on its own; every action is a tool the assistant calls, and sending documents off this computer requires the assistant to pass your agreement.

Register it

1. On the Fleet tab, in Send documents or files to a fleet computer for processing, press Copy MCP command. The clipboard now holds one line that starts with claude mcp add rbroker and names the bundled Node and the server script inside this app's folder, plus this app's dispatcher configuration and private server folder. It carries no credential.
2. Paste it into a terminal where Claude Code is installed. Other MCP hosts take the same program and arguments in their own settings.
3. Ask the assistant something like "which fleet computers accept document work?" It calls rbroker_nodes and reads the same list the card shows.

What the assistant can do

• rbroker_nodes: the fleet's computers, online or not, accepting program work or not, and whether each was last reached over your own network or the internet.
• rbroker_send_documents: send PDF and Word files for redaction exactly as the card does (nearest computer first, encrypted direct transfer, redacted text, PDF and Word copies back, the other computer's copies shredded). The assistant must pass confirmed: true, which it may only do after you agreed; without it the request is refused before anything runs.
• rbroker_redact_locally: the same program on this computer; nothing leaves and no credential is needed.
• rbroker_batches and rbroker_job_status: what was sent, and the state of one job.
• rbroker_local_status: whether Parallel Work, the GPU broker and this app's private server answer on this computer.
• rbroker_hub_status: if this computer hosts a fleet for its network (section 40), the fleet's name, addresses, port and certificate fingerprint. The invitation itself is never given to the assistant, because it carries the join key; copy it from the card.

What stays private

• No key ever reaches the assistant: not the dispatcher credential, not a manager or viewer key, not a join key, not an invitation. The server returns what the command-line tool prints: computer names, job ids, states, which path a transfer took, output file names.
• Consent and grants are unchanged. A computer runs a job only with its owner's consent and the fleet owner's grant to this dispatcher, whether the card or the assistant sent it.
• The server listens on nothing. It talks to the assistant over its own standard input and output, so there is no port to expose and nothing on the network to find.

Beside AI Hub

AI Hub runs its own MCP server (asl-ai-hub: working context, model recommendation and consumer task tools, reached on the hub). rBroker's is a different server (asl-rbroker), every tool begins with rbroker_, and it opens no port, so both can be registered with the same assistant at the same time with no name, tool or port collision. rBroker's test suite checks that no tool name is one of AI Hub's.

When it does not work

Technically

The server is fleet\mcp-stdio.mjs over fleet\mcp-core.mjs: newline-delimited JSON-RPC on standard input and output, MCP 2026-07-28 with per-request version metadata and server/discover, and the handshake revisions 2025-11-25, 2025-06-18 and 2025-03-26 through initialize. Tools are rbroker_nodes, rbroker_send_documents, rbroker_redact_locally, rbroker_batches, rbroker_job_status, rbroker_local_status and rbroker_hub_status; arguments are checked before anything runs (absolute paths, .pdf and .docx only, terms as names, addresses and employers), a refused argument is JSON-RPC -32602, a failed run is a tool result marked as an error. The backend runs fleet\document-job.mjs with --json as a child process and returns its EVENT lines and the per-file summary from batch.json; terms become a private temporary terms.json attachment. --config names the dispatcher configuration and --hub-root the private server folder (the copied command fills both). docs\mcp-server.md has the full table.

42. Send documents from your phone: the Android app

New in 1.4.11

ASL rBroker for Android makes a phone a sender in your fleet. Pick a PDF or Word document on the phone, choose one of your computers, and the document is sent to it, redacted there exactly as section 39 describes, and the redacted text, PDF and Word copies come back to the phone. The computer then shreds its copies. The app is in the rBroker repository under android; the Google Play listing is the owner's step (section 42 of android\play\README.md holds its text), and until then it installs from the build.

Join from the phone

1. On the computer that hosts your fleet (section 40), press Copy invitation and send the line to the phone the way you would hand over a key.
2. In the app, paste it under Join a fleet and press Use this invitation. The phone tries the hub's addresses, keeps only the one that presents the certificate the invitation names, and remembers that fleet. A fleet with a public address needs no invitation: enter the address instead.
3. The fleet's owner gives the phone a dispatcher credential (the hub mints one beside its private server; a public coordinator's owner issues one with setup.mjs add-dispatcher) and grants it program work on each computer (section 27; a hub grants its own dispatcher automatically). Paste the credential once and press Save; it is sealed with a key that lives in the phone's secure keystore and never shown again.
4. Press Refresh computers. Each computer shows online or offline and whether it accepts document work.

Send

1. Press Choose documents and pick PDF and Word (.docx) files. Optionally list names, addresses and employers that must always be removed, one per line, with address: or employer: in front when it is not a person's name.
2. Choose a computer and press Send to the fleet. The log shows each step: uploading, offered, claimed, settled, delivered, shredded.
3. Redacted copies land in the app's private documents folder, named like the desktop's (<name>.redacted.txt, .redacted.pdf, .redacted.docx and <name>.report.json). Share them from there.

How a phone sends without a direct connection

Two computers send documents to each other over a direct encrypted peer connection (section 31). A phone has no such channel, so it uses the fleet's store transport: the document, packed with the program under a neutral name, is uploaded in small verified chunks to your coordinator's encrypted artifact store, the chosen computer pulls it from there, and when the work is done that computer sends the result and its summary back to the store, where the phone reads and verifies them against the job's receipt. Nothing touches any other server. A hub made with Host a fleet for my LAN has store transport on; an existing coordinator turns it on with setup.mjs store-transport <private> on while stopped. The coordinator accepts a stored result only for a job whose input came from its store; everything else stays on the direct channel. A computer can use the same path with document-job.mjs send --transport store when it cannot open a direct connection.

What stays where

• The phone keeps the fleet address, the fleet name, the sealed dispatcher credential and the redacted copies, all in the app's private storage. The invitation's join key is used once to pin the hub and not saved.
• The coordinator's store holds the packed document and the result, encrypted at rest with the coordinator's storage key, until the job's retention ends; the computer that did the work shreds its copies after delivery, as always.
• Consent and grants are unchanged: the phone's jobs run only where the owner consented and the fleet owner granted its dispatcher.

When it does not work

43. Headless mode: run from the tray icon

New in 1.4.12

Headless mode hides this app's window and keeps everything it runs going behind a tray icon: your private server or fleet hub (section 40), Parallel Work, the fleet executor, reporting and the sweeper. It is for a computer that should keep serving the fleet without a window in the way, without installing the Windows service (section 5) or the headless node from source.

Switch it on and off

1. On Host & setup, in Headless mode · tray icon, press Switch to headless mode. The window disappears; the rBroker icon in the notification area shows a short notice. Nothing that was running changes.
2. The icon's menu has Headless mode (hide this window), which is ticked while hidden and switches the mode off and on, Show rBroker window, and Exit rBroker. Double-clicking the icon does the same as the first item.
3. Tick Start in headless mode next time this app opens to have the app open hidden in the tray. That remembers the window state only; no server, worker or reporter starts by itself, exactly as before.

Exiting

• Exit rBroker in the tray menu, or closing the window when it is shown, both take the same safe path: the fleet executor drains its owned work first and a busy worker is never killed. If a stop has to wait, the window comes back and says why; nothing is lost.
• The tray icon is this window's own. It appears when the app starts (not in demonstration mode) and disappears when the app exits; it never survives the process or starts the app.

What headless mode is not

• Not a Windows service: when you sign out or the computer restarts, headless rBroker stops like any other app. An always-on computer uses the service companion (section 5) or the headless node from source (windows\headless), which run without any window at all.
• Not a change of consent, grants or sharing: every switch on the Fleet tab stays exactly as you left it.

Technically

The workspace raises HeadlessRequested; the hosting window hides or shows itself, owns a NotifyIcon with a context menu (Windows Forms, which the app now references beside WPF), and reports the state back through ShowHeadlessState. startHeadless is a boolean in the app's private preferences.json beside the saved addresses and ports. Exit from the tray calls the window's close, which runs the existing TryCloseAsync drain; a refusal re-shows the window. Demonstration mode (--demo, the UI checks) creates no tray icon and treats the switch as inert.

44. Addresses, and the fleet console for your network

New in 1.4.13

Two small things that make hosting easier. The Addresses card on Host & setup tells you where this computer is reached, and a hub can serve its fleet console and this help to the other computers on your network over its own HTTPS port, so a laptop with only a browser can see the fleet.

Addresses

• Refresh addresses lists this computer's addresses on your network (each active network adapter's IPv4 address), the loopback port of this app's private server, the hub's LAN addresses and port when you host (section 40), the fleet console address when it is served, and the fleet server this computer connects to.
• Look up public address asks ASL's public coordinator (https://rbroker.autosecurelogin.com/v1/address) which address this computer comes from, and shows it with the time. Nothing else is sent, and no third party is asked. That address is your router's: computers on the internet reach a hub at home only if the router forwards the hub's HTTPS port to this computer's LAN address, or through the ASL tunnel (section 46).
• No address is looked up on its own. The card is informational; it changes nothing.

The fleet console on your network

1. On Host & setup, leave Also serve the fleet console and help pages to the LAN ticked (it is by default) and press Host a fleet for my LAN. The hub's HTTPS port answers the API as before and, in addition, /console/ and /help/.
2. On another computer on the network open https://<hub address>:28443/console/. The browser warns about the certificate the first time, because the hub signed it itself (section 40 explains why that is safe on your own network); proceed, then enter the fleet's viewer key to see the fleet. The key never leaves that browser except to the hub.
3. Untick the box and press Host again to serve the API only. From the command line: setup.mjs web-console <private> on|off while the coordinator is stopped.

What it is not

Not a general web server: the hub serves exactly the console page, its script and stylesheet, and the help guide, from the app's own folder, with the same security headers the public site uses. No directory listing, no uploads, no other files. The public coordinator at rbroker.autosecurelogin.com still serves its own pages through its reverse proxy.

Technically

fleet/coordinator.mjs answers GET /v1/address with the caller's address as the server sees it (behind a reverse proxy on the same computer, the first X-Forwarded-For entry; a forwarded header from anywhere else is ignored), and when a webRoot is configured it serves an allowlist of pages from it (/, /console/, /console.js, /rbroker.css, /help/, /help/guide.css) on both listeners with Cache-Control: no-store, X-Frame-Options: DENY and a strict content security policy. setup.mjs host-lan sets webRoot to the website folder beside fleet when it exists; setup.mjs web-console on|off [--root DIR] changes it. The app's Host button runs that command with its own website folder according to the box. The Addresses card reads the network adapters with NetworkInterface and asks the public coordinator with the fleet HTTP handler (no proxy, no redirects).

45. Your own job types: programs the fleet runs

New in 1.4.13

Redaction (section 39) is one program. The card that sends it can send any program: a folder with a small program.json and the files it lists. Every fleet computer that allows program bundles runs any such program from a granted sender, inside the limits its owner set, so adding a job type needs no new rBroker and no change on the receiving computers.

Send a program

1. On the Fleet tab, in Send documents or files to a fleet computer for processing, press Refresh programs. The Program (job type) box lists the bundled programs and yours, each with the file kinds it takes and what it attaches.
2. Choose a program. Choose documents now offers that program's file kinds, and the Always remove these box is available only for a program that takes a terms.json attachment.
3. Press Send to the fleet, or Run on this computer instead to run it here with the bundled Python. The outputs land in the batch folder named <file>.<output label> beside batch.json.

Add a program of your own

1. Press Open my programs folder. Each program is a folder named like the program (lowercase letters, digits and dashes).
2. Put a program.json in it naming the entry point (a Python file, or an .exe inside the folder), the files, the input file kinds, the outputs it writes, its time and memory limits, and a plain description of the work. docs\programs.md in the rBroker source explains every key with a complete example (a word counter), and the bundled fleet\programs\redact-documents is a larger one.
3. Press Refresh programs. A program with a mistake is listed with the reason instead of being offered. A program of yours with the same name as a bundled one replaces it for this computer.

What the computer that runs it sees

• Only the bundle: your program files, the pinned wheel if any, the input under a neutral name (doc-01), the attachments. It runs in a private workspace with the node's isolated Python, under the time and memory limits in program.json, and only the declared outputs come back, verified by hash.
• The owner's consent and the fleet owner's grant still decide whether it runs at all (section 27). A program cannot ask for more RAM or workers than the owner allowed.
• shred: true in program.json makes the sender offer the shred job after delivery, so the computer keeps no copy of the input; the sweeper takes care of leftovers either way.

What is not a program

GPU work (pictures, animations, likeness) uses fixed handlers with measured memory floors and needs an rBroker release to add a kind; registered CPU work types (core.echo, core.sha256-json) are Parallel Work's. Everything else is a program.

Technically

fleet\document-job.mjs programs [--programs-dir DIR] lists programs from the person's folder first, then fleet\programs (first match wins), as EVENT lines with name, source, valid, takesInput, extensions, attachments, shred and sendable (the shred program runs only after a delivered job). --programs-dir or RBROKER_PROGRAMS_DIR applies to nodes, send, local and dry-run; the app passes %LOCALAPPDATA%\ASL\rbroker-documents\programs and the MCP server takes it as --programs-dir (the Copy MCP command line includes it) and offers rbroker_programs. The validator (validateProgramSpec) refuses shells as entry points, unknown placeholders, unpinned wheels and oversize limits before anything is sent; the node validates the descriptor again before it runs.

46. Reach your hub from the internet: ASL Tunnel

New in 1.4.13

A hub on your network (section 40) is reachable by the computers around it. To let a computer anywhere join it, the app includes the ASL Tunnel agent: one outbound connection from this computer to tunnel.autosecurelogin.com, through which the hub answers at https://tunnel.autosecurelogin.com/t/<route>. Your router needs no port forwarding, nothing else on this computer is exposed, and every request still needs this fleet's keys.

Set it up

1. Create a public route on the ASL Tunnel control plane (ask ASL, or where the control plane runs: asl-tunnel-control create --name <route> --device <this computer> --public --pair). "Public" means the tunnel itself does not gate visitors with a viewer link; the hub's own keys do. Take the pairing code it prints, or the agent token.
2. Press Host a fleet for my LAN (section 40) if the hub is not running.
3. Under Reach this hub from the internet: ASL Tunnel, paste the pairing code or token and press Save tunnel credential. A pairing code is exchanged once for the token; the token is kept in the private server directory as a file only your account can read and is never shown again.
4. Press Start tunnel. Within a few seconds the status names the public address, the Addresses card lists it as Internet through ASL Tunnel, and the invitation carries it after the LAN addresses. Copy the invitation again for anyone joining from elsewhere.

What a joining computer does

It tries the invitation's addresses in order: the LAN addresses first, pinned to the hub's own certificate (section 40), then the tunnel address, which it verifies the way a browser verifies any public site, because the tunnel's public name carries a certificate from a public authority and the hub's own certificate stays on the LAN. The rule is the same in the Windows app, the headless node, the Linux node, the dispatcher and the phone app: an address with a path such as /t/home is relayed and is never pinned.

What is and is not exposed

• Only the hub's own port is forwarded; the agent names that port and nothing else. The gateway cannot reach any other program, port or file on this computer.
• Every request through the tunnel is the request the LAN port would see: the fleet view needs the viewer key, joining needs the join key, work needs an enrolled identity and the owner's consent, documents need a granted dispatcher. The invitation remains the thing to guard: it carries the join key.
• Jobs from computers outside your network travel through the hub's store (section 42), as from phones; the direct peer connection is for the LAN.
• Stop tunnel ends the public address at once and the invitation drops it. Forget tunnel credential deletes the token; revoke the route on the control plane too if nothing should use it again. The tunnel stops with this app.

From the command line and on Linux

fleet\setup.mjs tunnel <private> on --pair-code CODE (or --credential-stdin, or --token-file FILE) saves the credential; fleet\tunnel.mjs run <private> runs the agent (--no-stdin for a service, --once to check the route and exit); setup.mjs tunnel <private> status and off read and forget it. The agent is the tunnel's own code, carried verbatim under fleet\tunnel-runtime with its one pinned dependency.

Technically

The runner reads config.json (tunnel.enabled, tunnel.gateway) and tunnel-token.txt, starts the agent against http://127.0.0.1:<loopback port>/ (the same handler the LAN HTTPS port serves), and writes tunnel-state.json (publicOrigin, online, access, expiresAt) when the gateway accepts the route; setup.mjs invitation appends that origin and reports it as tunnelOrigin. The coordinator sees each request's path with the route prefix removed, and honours the gateway's X-Forwarded-For because the agent connects from loopback, so /v1/address answers an internet caller with its public address. The origin rule is one rule in four places (fleet/origin.mjs, fleet.py, Contracts.cs, Invitation.kt): https://host[:port] plus at most four plain path segments, a trailing slash tolerated; a prefix needs HTTPS. Routes are appended to the origin as text, so the prefix is kept, and the console page and the help reach their script, stylesheet and API by relative paths so they work behind the prefix too.

47. Linux: install the hub, the tunnel and a node as services

New in 1.4.13

Everything this guide describes for a hub also runs on a Linux computer, installed from one release archive by one script. The same fleet files the Windows app carries become a fleet hub (section 40), reach the internet through ASL Tunnel (section 46) and enroll the computer as a CPU and RAM node, each as a hardened service that starts with the computer.

Install

1. Get the release archive rbroker-linux-<version>-<commit>.tar.gz (ASL builds it with linux/build-release.sh from the source; the .sha256 beside it checks the download).
2. Extract it, enter the folder and run sudo ./linux/install.sh. It checks every file against the archive's hash list, needs Node.js 24 and Python 3.12 or newer, creates a service account rbroker, installs the release under /opt/rbroker with its own Python environment, prepares /var/lib/rbroker for the private state, puts the rbroker command in place and renders three services without enabling them. Nothing is started or exposed.
3. rbroker hub init <fleet-name>, then rbroker hub host-lan: the hub's certificate, join key and dispatcher, the console pages and the store for phones, as section 40 describes for the app. sudo systemctl enable --now rbroker-hub keeps it running.
4. rbroker hub invitation prints the line other computers paste (section 40). With a pairing code from the ASL Tunnel control plane, rbroker tunnel on --pair-code <code> and sudo systemctl enable --now rbroker-tunnel give the hub its internet address, and the invitation ends with it (section 46).
5. To make the same computer a node, give rbroker node init its name and limits, rbroker node join the invitation, rbroker node allow the computer's policy, and enable rbroker-node. The Linux node runs the registered CPU work types; program bundles (section 45) are the Windows nodes' handler.

What is where

• /opt/rbroker/releases/<id> is the release, read-only for the service account; /opt/rbroker/current points at the one in use. Upgrading installs the next release while the services are stopped; rolling back points current at the previous one.
• /var/lib/rbroker belongs to the service account alone: hub (configuration, keys, the tunnel credential, the store), node (identity, consent, journals), documents (the dispatcher's records and your programs folder).
• Run as root, rbroker switches to the service account, so state files never end up owned by root. Credentials never pass on the command line.
• Each service may write only its own state directory, has no capabilities, a private /tmp and no view of home directories. The tunnel service stops with the hub and does not loop when the gateway refuses a credential.

Technically

linux/build-release.sh exports the HEAD commit's fleet, src/asl_gpu_broker, desktop/host, portable, website and linux, adds the pinned canonical ASL Parallel Work package from the asl-shared-modules commit desktop/dependencies/parallel-work.json names, installs the two pinned npm dependencies from their lock files, and writes RELEASE_SOURCE.json and SHA256SUMS. linux/install.sh takes --prefix, --state, --user, --node, --python, --no-services (a user-local install without root), --no-venv and --replace, records its choices in <prefix>/rbroker.env and INSTALL_RECORD.json, and renders linux/systemd/*.service.in. linux/rbroker maps its subcommands onto setup.mjs, serve.mjs, tunnel.mjs, document-job.mjs, mcp-stdio.mjs and asl_gpu_broker.portable_node with the recorded paths. docs/linux-install.md in the source is the full guide; node --test linux/linux.test.mjs builds, installs into a scratch prefix and drives the hub to a served health route.

48. Languages: rBroker in 14 languages

New: 14 languages

rBroker speaks English, Polish and the twelve languages most spoken at home in the United States after English: Spanish, Chinese (Simplified), Tagalog, Vietnamese, Arabic, French, Korean, Russian, Portuguese (Brazil), Haitian Creole, German and Hindi.

Switch the language

1. Open the language list at the top right of the window, beside Refresh now. Each language is written in its own script.
2. Choose one. The window changes at once; a status line that carries figures or names changes at its next update. Arabic is written right to left, and the whole window mirrors.
3. rBroker remembers the choice. Until you make one, it starts in the language chosen in the test installer, else in Windows' display language when rBroker speaks it, else in English.

What changes and what stays English

• Translated: the window and its messages, the tray icon's menu, the optional service's setup window, this help guide (Help opens it in the chosen language), the fleet console page, the Android app (it follows the phone's language) and the test installer with its notes.
• English on purpose: protocol values and identifiers, file and folder names, log files and diagnostic exports, messages that come straight from a helper program or from another computer, and everything rBroker sends to another computer. Computers set to different languages still exchange exactly the same records.
• The online guide at rbroker.autosecurelogin.com/help/ is the English edition until ASL publishes the translated editions beside it.

49. Send Blender, Android and Windows/MSIX projects

New in 1.5

Install rBroker on both computers, then configure the tools once on each computer that will run jobs. On Host & setup, use Project tools on this computer: detect the installed tools, tick Blender, Android or Windows, correct any path, and save. Blender Python, Android emulator, local USB ADB, direct-only ASL Tunnel Android, and Microsoft Store-ready MSIX packaging are explicit checkboxes. Local physical ADB and Tunnel are independent: enabling one never authorizes the other.

What must be installed on the receiving computer

• Blender: Blender for Windows. A GPU broker is needed only for recipes that request GPU memory. Tick Blender Python only if transferred jobs may run a project Python script.
• Android: a JDK and Android SDK with platform tools; for emulator work, install the emulator and create the AVD named by the recipe. For physical work, connect, unlock and authorize exactly one device.
• Windows/MSIX: Visual Studio 2022 or Build Tools with the solution's workloads and Windows packaging tools. Store packaging uses only this computer's optional certificate thumbprint.

A remote Android device through ASL Tunnel

On Windows, install the current ASL Tunnel Store app for the same user. The reviewed helper also recognizes the licensed Linux client's installed asl-tunnel alias for compatible headless integrations, while the Store desktop project runner remains Windows. On the Android device, explicitly start its private 30-minute pairing route once; enter that route and the six-digit Android pairing code in rBroker. The code is cleared immediately and never saved or sent to an AI. Then start the device's separate connection route.

If the exact Android serial is not known, leave that field empty and press Test: rBroker reads and displays it, closes the listener, and asks you to confirm the intended Android device before pressing Test again and saving. Tunnel device work has its own checkbox and typed device: tunnel recipe; it never enables the separate local physical-ADB permission.

Every job accepts only ASL Tunnel's matching direct-only loopback listener, verifies that exact Android device identity through ADB, runs only typed APK installation steps, continuously drains bounded child diagnostics, and closes its owned listener on startup or runtime failure. There is no relay fallback and no arbitrary shell.

Send the job

1. On the Fleet tab choose the project folder and one of the recipes in fleet\project-recipes, edited for the project's files and outputs.
2. Press Find ready computers. A computer is ready only when its local tools, private worker, owner consent and named-dispatcher grant all match.
3. Press Send project. Common cache/build folders are left out. The encrypted transfer runs one typed command—never a shell—and returns only the declared outputs in a verified ZIP.

A Store recipe creates a Store-ready MSIX candidate. It does not sign in to Partner Center, change a listing, submit the package or claim approval. Full recipe fields, command-line use, AI setup tools and troubleshooting are in docs\project-jobs.md.