Add a second machine for heavy jobs

Use this when one Mac is busy and you want another to take some of Barry’s background jobs. You link the second Mac as a worker. The machine that owns the work, called the owner machine, keeps the workflow history. It also decides which worker takes each step. The worker claims steps, runs them, and reports back. The example moves session summaries, the sessions:summarize-session@1 job that Barry ships, onto the second Mac.

The owner machine is the installation that holds the runs. It differs from the user that barry owner shows, which is a person, not a machine.

Before you begin

You set up Barry on both Macs, and barry doctor passes on each.
Both Macs have the same version of every bag whose jobs you plan to move.
The owner machine publishes its workflows.runtime service on a private HTTPS route that needs no interactive sign-in. A tunnel-provider bag and a route in the instance’s hosting.yaml set that up; the two-machine walkthrough shows the shape. Keep the route private: a public route also exposes the workflow console’s sign-in page.
The second Mac runs Ollama with the model your session summaries use. The summarize job asks a local model, and it fails on a machine without one.
You operate both machines. A worker credential is not proof of who runs the machine, so invite only your own.

Know which jobs can move

A bag job runs on a worker only when all of these hold:

It carries a version, so its address looks like bag:name@1.
It runs on Node, with using: node.
It declares no secrets.
It touches no files.

Owner and worker pin the job’s code by digest, which is why both need the same bag version. A job that fails any rule runs where it started. Every installation is also its own worker, so a step the owner machine can run itself never has to leave it. Distributed nodes explains the rules in full.

Invite the worker

On the owner machine, start the services, confirm the route, and invite the second Mac by a name you choose:

barry up
barry hosting status workflows.runtime
barry workers invite second-mac --jobs sessions:summarize-session@1

hosting status shows the route’s private HTTPS address. --jobs scopes the invite, so this worker may claim only the summarize job. Without it, the worker may claim any job the owner advertises. The invite prints a barry workers join command with a token, shown once. Move it to the second Mac privately; anyone with the token joins as this worker.

Join from the second machine

On the second Mac, run the printed join command, then restart its runtime:

barry workers join <token>
barry service restart workflows.runtime

Steer jobs with labels

Every worker advertises its operating system and architecture. A job can require more: the summarize job requires the label model=local, so the worker offers it only once it carries that label. Add the label to the worker’s barry.yaml under the runtime’s environment:

services:
  workflows.runtime:
    env:
      - BARRY_WORKFLOW_LABELS=model=local
      - BARRY_WORKFLOW_CAPACITY=2

BARRY_WORKFLOW_LABELS takes comma-separated KEY=VALUE pairs. BARRY_WORKFLOW_CAPACITY caps how many activities the worker runs at once; it defaults to four. Restart workflows.runtime after editing the file. Claim only labels the machine can satisfy: a label installs no model software, and Barry does not check it.

From then on, each sweep that summarizes quiet sessions sends the model call to a worker that offers the job, and runs it on the owner machine when none does. The owner machine builds the prompt and saves the summary.

Verify

On the second Mac, check what it offers:

barry workers status
barry workers list

workers status lists the jobs this machine can run for the owner, and why it withholds any. workers list shows the owner’s address and this worker’s identity. barry doctor on the worker also probes the owner over the route and reports a failed owner check by name.

On the owner machine, barry workers list shows second-mac with its assigned ID and the jobs it may claim.

If it fails

The invite refuses the route. The route sits behind an interactive sign-in gate, or hosting.yaml publishes none for workflows.runtime. Fix the route, run barry up, and invite again.
A job is not offered. Read the reason barry workers status gives on the worker, such as a missing binary or label, or an invite scope that leaves the job out.
The worker’s owner check fails in barry doctor. The credential, the address, or the route is wrong. See Check installation health.
You need to cut the worker off. On the owner machine, barry workers revoke second-mac refuses its next call and stops what it is running. barry workers rotate second-mac issues a new credential instead, and the old one keeps working for five minutes.