Bring your own compute (BYOC)

Run governed work on your own machines. LumenFlow's cloud issues a scoped authorization envelope — permissions, budget, a kill switch, and a confinement posture — to a local runner, then ingests per-action evidence and cost back. Your compute, LumenFlow's governance.

Your compute, governed#

Bring-your-own-compute (BYOC) lets governed work run on infrastructure you own — a developer machine, your own servers — while LumenFlow's control plane still sets the rules and keeps the record.

How it works#

  1. The cloud issues a governed authorization envelope for the run: which capabilities are allowed, the budget, a kill switch, and how the work is confined.
  2. A local runner executes inside that envelope.
  3. Each tool call streams evidence and cost back to the cloud, so the work is as auditable as anything run in the hosted runtime.

Why use it#

  • Keep data and execution on your own hardware for residency or security reasons.
  • Use spare or specialised local compute while keeping central governance.
  • Prove what ran locally with the same evidence chain as everything else.

Nothing to expose#

Your machine connects outward to LumenFlow — it pulls work, then reports back. LumenFlow never connects in to your machine. You don't open a port, forward anything, or change a firewall rule, and that stays true whether you connect one laptop or a whole campus of machines. A runner works behind NAT, a corporate firewall, or an air-gapped switch with only outbound HTTPS.

Your keys stay in the cloud#

When you bring your own model for coding work, LumenFlow's cloud uses it to plan the work and your machine carries the plan out. Your model API keys are held by the cloud and are never sent to your machine — so you can use your own model without spreading credentials onto local hardware.

It runs the whole loop, safely#

For a coding task, your runner does more than run isolated commands — it works the task end to end: it reads the relevant files, makes edits, runs your tests and gates, and tries again — using the failed gate's output to fix the next attempt — until everything passes, then opens a branch and pull request. Every step runs inside an on-machine sandbox: file writes, commands, and network access from governed steps are confined to a declared working directory and enforced by your operating system, not dependent on LumenFlow's cloud to hold the line.

See Connected Compute and Connected-Runtime Enrollment to connect a runner.