Skip to main content
Devin Outposts lets you run Devin sessions inside infrastructure you control. The agent loop stays in Cognition’s cloud. The session machine, where commands run, files change, and repos get checked out, moves into a Tensorlake sandbox you own. Use an outpost when the agent needs a custom environment: private CA certificates, preinstalled toolchains, pre-cloned repositories, or services only reachable from your network, all defined in the Tensorlake image and sandbox configuration. And because Tensorlake can run on self-hosted compute, the sandboxes can sit inside your network, where Devin can read your source code, query your databases, and test against the systems it is writing code for. An orchestrator watches Devin’s session queue, claims each session, and runs it in a Tensorlake sandbox. The orchestrator itself runs inside a long-lived Tensorlake sandbox, so no long-running process stays on your laptop. When a session goes idle the sandbox suspends; when it wakes the same sandbox resumes; when it ends the sandbox is terminated. Each Devin session maps to one sandbox.

​
Prerequisites

  • A Devin account with Outposts enabled, and an org admin who can connect the outpost.
  • A Tensorlake account and API key from cloud.tensorlake.ai.
  • Python 3.10+ on the machine that runs the setup and launcher commands. The orchestrator itself runs inside a Tensorlake sandbox.
Tensorlake sandboxes are Linux microVMs, so the outpost is Linux only. Run one orchestrator per outpost.

​
Setup

The reference implementation is tensorlakeai/devin-outposts-tensorlake, a Python package that is mainly the orchestrator. Installing it also provides the CLI commands used in the steps below: outposts-connect, the two image builders, for orchestrator and session sandboxes respectively, and the sandbox launcher.
1

Install

Add your TENSORLAKE_API_KEY to .env.
2

Connect the outpost

Run this on the same machine as your browser:
outposts-connect is the package’s local implementation of Devin’s partner connection flow. It opens Devin’s connection page, where a Devin org admin confirms the outpost and clicks Connect. The browser returns a one-time code to a temporary listener on localhost, which is why the command and browser must share a machine. The command exchanges the code for a machine-serving token and writes DEVIN_OUTPOSTS_TOKEN, DEVIN_API_URL, and OUTPOST_ID to .env. The token never passes through the browser.This one-time authorization creates the outpost and a service user whose token the orchestrator uses for every queue call. The outpost then appears in Devin’s environment picker whenever someone in your org creates a session.For headless hosts or manual outpost creation, see manual setup in the repo README.
3

Build the session image

This builds an image with the remote’s required system packages: git, curl, and CA certificates. It also tries to install the GitHub CLI and Chromium, but those steps are best-effort; if your sessions depend on either tool, verify the built image. Devin also lists ffmpeg as an optional dependency for screen recording; this image skips it, so add it to the build recipe if you want recordings. Copy the printed name into IMAGE_NAME in .env.
4

Build the orchestrator image

This packages the orchestrator itself into its own image, distinct from the session image that serving sandboxes boot from. Build it once; rebuild only when you update the package. (The repo calls this the dispatcher image.)
5

Launch the orchestrator

This starts the orchestrator inside a long-lived Tensorlake sandbox. The command is idempotent: run it again and it resumes the sandbox and re-ensures the orchestrator process. The orchestration work now happens in the sandbox, not on your local; the only local piece left is a small keep-alive cron, covered in Operate the orchestrator.The launcher reads your local .env and injects the credentials the orchestrator needs (TENSORLAKE_API_KEY, the Devin machine token, and GIT_TOKEN if set) into the orchestrator process’s environment at start. They are never baked into the orchestrator image. Treat this sandbox as a trusted control-plane host; session sandboxes never receive the machine token, each remote gets only its own session’s connect token. To rotate a credential, update .env, then --terminate and relaunch.
6

Create a session

Confirm the orchestrator is watching, then create a session in the Devin UI or Slack and select your outpost. The orchestrator claims it and runs it in a sandbox.
Each claim pins devin-remote, Devin’s session binary, by SHA; the orchestrator downloads it into the sandbox and verifies the checksum before executing it. The binary dials out to Devin’s gateway over HTTPS, so the sandbox needs no inbound ports.Session credentials follow the same injected-at-start pattern as the orchestrator’s. The claim response carries that session’s connect token and gateway URL, which the orchestrator sets as environment variables when it launches devin-remote in the sandbox. If REPOS is set, the orchestrator pre-clones those repositories into the sandbox first, passing GIT_USERNAME and GIT_TOKEN to the clone command only. Nothing is baked into the session image, and the session sandbox never receives your Tensorlake API key or the Devin machine token.

​
Operate the orchestrator

Observe and manage the orchestrator sandbox from your machine:
Outposts is watch-based, so the orchestrator runs continuously (not scale-to-zero). Tensorlake suspends a named sandbox after your plan’s maximum idle window, and a suspended orchestrator cannot claim sessions. The launcher is idempotent (it resumes the sandbox and re-ensures the orchestrator process), so schedule it on a cron to keep it watching across that window:
The cron host needs the repo, the venv, and .env, and it needs to be awake when the tick fires, so an always-on machine (a small server or any host that does not sleep) is the better home for it. A laptop works too, with one caveat: while the laptop sleeps the orchestrator can stay suspended, and queued sessions wait until the next tick after it wakes. Keep the interval shorter than your plan’s idle window.

​
Watch session logs

The orchestrator log (--logs) shows lifecycle events only (claim, sandbox created, serving, released). The session’s processing output, every tool call devin-remote executes, is written inside the serving sandbox to /tmp/devin-outposts/<session>.log. The reference implementation includes session_logs.py, a helper script we wrote to monitor session logs from your machine:
The sandbox name is the dvo-... string the orchestrator logs when it claims a session (visible in --logs). Live mode runs tail -F in the sandbox over a PTY websocket (the SDK’s streaming channel) and follows the session lifecycle: it reconnects if the connection idles out, waits while the sandbox is suspended (Devin put the session to sleep) and re-attaches on resume, and exits when the sandbox is terminated because the session ended.

​
Configuration

Set these in .env. outposts-connect writes the Devin values, you add TENSORLAKE_API_KEY during install, and the image build prints IMAGE_NAME; the rest have defaults.

​
Next steps

Reference implementation

The full orchestrator and the CLI commands that drive it.

Sandbox lifecycle

The suspend/resume model that keeps idle sessions cheap.

Sandbox images

Build a custom session image with your toolchain.

Claude Managed Agents

The same orchestrator pattern for Anthropic’s managed agents.