Devin Outposts connects a Devin session queue to compute supplied by the
operator. One orchestrator process runs for each outpost inside a long-lived
Tensorlake sandbox (the dispatcher). It watches the early-access (opbeta)
queue, claims runnable sessions, and reconciles each session with a Tensorlake
sandbox. Inside that sandbox, a checksum-pinned devin-remote process connects
the session to its Linux environment.
graph LR
O["Orchestrator<br/>one process per outpost<br/>dispatcher sandbox"]
Q["Devin Outposts queue<br/>opbeta API"]
T["Tensorlake API"]
subgraph S["Tensorlake microVM"]
R["Pinned devin-remote binary"]
end
O <-->|"list, watch, claim, release"| Q
O -->|"create, resume, suspend, terminate"| T
T -->|"manages"| S
O -->|"download, launch, supervise"| R
R <-->|"serve session"| Q
The config loader (devin_outposts.config) builds the outpost, sandbox,
repository, and credential settings from the environment. The queue client
(devin_outposts.queue) deliberately exposes a small set of list, watch, get,
claim, and release operations, and devin_outposts.queue_shapes absorbs payload
drift on its behalf. The orchestrator (devin_outposts.orchestrator) turns
queue state into lifecycle actions, while the worker launchers
(devin_outposts.worker, devin_outposts.worker_linux) prepare and supervise
the remote process inside each sandbox.
The orchestrator runs inside a long-lived Tensorlake sandbox — the dispatcher —
launched from the dispatcher image by launch_orchestrator_sandbox. Your
machine runs the build and launcher commands but keeps no orchestrator process
alive.
graph TB
Q["Devin Outposts queue"]
subgraph tl["Tensorlake"]
D["Dispatcher sandbox<br/>runs devin-outposts-orchestrator<br/>launched by launch_orchestrator_sandbox"]
end
W["Per-session worker microVMs"]
Q <--> D
D --> W
Because Outposts is watch-based rather than webhook-driven, the dispatcher runs
continuously — it is not scale-to-zero. A named Tensorlake sandbox stays up to
the plan's maximum idle window and then suspends; re-running the idempotent
launcher (resume + re-ensure the process) on a schedule keeps it watching across
that ceiling. The orchestrator writes a status.json heartbeat inside the
sandbox that --status reads, and the orchestrator log is what --logs tails.
stateDiagram-v2
[*] --> Pending
Pending --> ClaimedServing: claim
ClaimedServing --> Suspended: inactivity suspend
Suspended --> Resumed: session wakes
Resumed --> Suspended: inactivity suspend
Resumed --> Terminated: terminate
ClaimedServing --> Terminated: terminate
Terminated --> [*]
state "Pending" as Pending
state "Claimed / serving" as ClaimedServing
state "Suspended (sandbox suspended, state kept)" as Suspended
state "Resumed (same sandbox, memory + processes intact)" as Resumed
state "Terminated (sandbox terminated)" as Terminated
Suspension is driven by inactivity on Devin's side. A suspended session is visible in the queue only transiently and then vanishes, so an absent queue entry does not mean that the session terminated. The orchestrator releases the claim and suspends the sandbox; when the session wakes and returns as pending, the same sandbox is resumed and reused. An observed terminated state instead terminates the sandbox.
Tensorlake suspend preserves the sandbox filesystem, memory, and running
processes; resume picks up in place. That is stronger than disk-only stop and
start: a resumed session keeps the devin-remote process and its in-memory
state, not just files on disk.
sequenceDiagram
participant Q as Devin Outposts queue
participant O as Orchestrator
participant T as Tensorlake
participant S as Sandbox
participant R as devin-remote
participant C as Remote distribution
O->>Q: Claim pending session
Q-->>O: Claim details and pinned remote SHA
O->>T: Sandbox.get_or_create(name, image, sizing)
Note over T: Attach to the named sandbox, resume it if suspended,<br/>or create it on first use
T-->>O: Running sandbox
opt Repositories are configured
O->>S: Pre-clone missing repositories (GIT_ASKPASS)
end
O->>C: Fetch checksum for pinned remote
S->>C: Download pinned remote
O->>S: Verify checksum in sandbox
O->>S: Launch remote with credentials in process environment
S-->>R: Start serving
loop While serving
O->>S: Poll worker PID (sandbox.run)
O->>Q: Read session status
end
O->>Q: Release claim
alt Session suspended or entry absent
O->>T: Suspend sandbox (keep state)
else Session terminated
O->>T: Terminate sandbox
end
The orchestrator decides when serving sandboxes are created, suspended, resumed,
and terminated. The supervise loop polls the worker through sandbox.run every
few seconds; that proxied traffic keeps a serving sandbox from hitting its idle
SANDBOX_TIMEOUT_SECS and auto-suspending underneath an active session.
Each queue entry selects a remote binary by SHA. The launcher fetches its published checksum, downloads the binary inside the sandbox, and verifies it before execution. Pinning provides supply integrity, and downloading in the sandbox avoids unreliable host uploads of a large binary.
The orchestrator derives a deterministic name, dvo-{outpost8}-{session}-{hash},
and lets Tensorlake bind that name to one sandbox. Sandbox.get_or_create(name)
attaches to the existing sandbox, waits out a concurrent create or suspend,
resumes a suspended sandbox, and creates a new one only when the name is free.
Sandbox.connect(name) resolves a name directly, so a reattach after restart
can check that a claimed session still has its sandbox before it binds the name.
The launcher uses the same call for the per-outpost dispatcher sandbox.
Tensorlake sandboxes carry no labels, so the janitor still scans Sandbox.list
and uses the dvo-{outpost8}- prefix to scope the sweep to one outpost. Because
a name cannot be reversed into its session ID, a sandbox_index.json in the
state directory records sandbox name → session ID, letting the janitor map any
listed sandbox back to its Devin session.
The queue API is early-access and its payload shapes can drift. Fields may be
top-level or nested under status, metadata, or spec objects, and responses may
use mappings or objects. A narrow tolerance layer
(devin_outposts.queue_shapes) normalizes those variations so lifecycle code
reads one stable shape.
A periodic janitor performs a name-prefix-scoped Sandbox.list sweep, excluding
sessions currently served by this process. Using the session index, it suspends
sandboxes whose session is suspended or absent and terminates sandboxes whose
session has ended, without touching unrelated Tensorlake resources.
A lightweight poller lists pending queue entries every few seconds and reconciles them. The watch stream is the primary signal, but it has been observed to withhold events while staying open; without the poller a new session could wait out the full watch cycle before being claimed, longer than Devin waits for an outpost machine.
Worker credentials pass through the process execution environment rather than
being interpolated into command strings, and configured secrets are redacted
from exception logs. Git credentials for repo pre-clone are supplied through a
GIT_ASKPASS helper so tokens never reach argv or git config. The Devin Outposts
machine token and the Tensorlake API key have separate roles and are not
interchangeable.
- Tensorlake sandboxes are Linux microVMs; one orchestrator serves one Linux outpost.
- Devin desktop and browser features depend on the browser and display tooling baked into the image. The default image installs Chromium best-effort; validate computer-use against your tenant before relying on it.