What you're setting up#
A Connected Compute node is a machine you control that pulls governed work from your workspace, executes it under your workspace's policy, and reports evidence back — your compute, LumenFlow's governance. Linux is the preferred production posture: it gets LumenFlow's strongest sandboxing by default. See Connected Compute for the concept and Which credential is for what for how this fits alongside your other workspace credentials.
Prerequisites#
- A recent Node.js runtime available on the machine (the current setup path
runs a small bootstrap script with
node). - Outbound HTTPS access to your workspace's cloud endpoint. Nothing needs to listen for inbound connections — see Firewall and outbound networking below.
- Workspace owner or admin access, to generate the credential this machine will use.
Step 1 — Get your machine's credential#
Open your workspace's Compute page and use Runner setup. This mints a one-time credential for this workspace and generates the exact commands for your platform — connect, doctor, and a one-iteration run. Copy the generated command directly from the page; don't reconstruct it from an old ticket, chat transcript, or a command a teammate pasted for a different workspace, since the credential and directory are specific to this pairing.
The commands the page shows you run through Node, fetching a signed bootstrap from your workspace's own API — they don't require installing a package globally or reaching the npm registry.
warning The credential is shown once. Don't paste it into a ticket, a chat message, or a shared document — treat it as burned if it ever appears anywhere outside that one command, and re-run Runner setup for a fresh one.
Step 2 — Connect#
Run the generated connect command in a terminal on the Linux machine. It writes a local credential file (not printed to your screen after this step) and registers a runner session with your workspace.
Step 3 — Doctor#
Run the generated doctor command. It reports, in plain terms:
| What doctor checks | What it means |
|---|---|
| Credential file present | The local credential from Step 2 was found and is readable |
| Runtime claim admission | Your workspace accepted this machine's request to claim work |
| Runner session | The session id your workspace is tracking for this machine |
| Capability probe | What this machine advertised it can do |
| Confinement posture | The isolation level LumenFlow detected on this machine |
| Energy sensor | Whether measured energy readings are available on this machine, or only modeled/estimated |
| Work availability | Whether there's eligible work queued for this machine right now |
no eligible work is a healthy idle state, not an error — it means the
machine is connected and polling, and there's simply nothing queued for it.
Firewall and outbound networking#
This machine only ever calls out to your workspace's cloud endpoint over HTTPS — it polls for work, then reports back. LumenFlow never opens a connection into your machine. You don't need to open an inbound port, configure port forwarding, or carve out a firewall exception beyond normal outbound HTTPS, whether you're pairing one laptop or a whole fleet.
Confinement#
Linux gets LumenFlow's production-default sandboxing: work runs isolated from the rest of the machine using your operating system's own isolation primitives, not something LumenFlow has to hold together from the cloud side. A machine that can't offer that isolation is treated as reduced-posture and kept off privileged work — doctor's confinement line tells you which state your machine is in.
Local models on this machine#
If you point this machine at a model you're running locally (for example an
OpenAI-compatible server on localhost), your workspace's model
configuration needs the matching endpoint and model id, and the endpoint
needs to be reachable from this machine specifically. Doctor's report
includes whether that endpoint is reachable. LumenFlow never silently
substitutes a different model when your configured local one is
unreachable — it holds or refuses the assignment instead.
Drain, quarantine, and remove this node#
- Drain — stop the machine from claiming new work while letting anything already in progress finish or fail safely. Use this before planned maintenance.
- Quarantine — stop the machine claiming anything at all, immediately, while you investigate something unexpected.
- Revoke — invalidate this machine's credential outright. A revoked machine fails closed on its next request.
- Remove the local install — stop the running process and delete the local credential file. Your workspace keeps the historical evidence for work this machine already did; removing the local files doesn't erase that record.
These actions are available today through your workspace owner/admin — ask us if you don't see a control for one of them yet on the machine's row in the Compute page, and we'll help.
What's not live yet#
A signed, installable Linux package (.deb/.rpm/tarball) with a
systemd service — start/stop/restart/logs/upgrade built in — is planned
but not yet published. Today's verified path is the diagnostic connect →
doctor → run loop above, kept running in a terminal or an operator-managed
process supervisor you control. We'll update this guide the moment a signed
package ships.