Skip to main content
Devin Outposts keep Devin’s planning and model inference in Devin Cloud. Devin runs commands, edits files, and accesses repositories on a machine you operate. This guide makes that machine a CoreWeave sandbox: an isolated environment with the image, CPU, memory, GPU, and lifetime you choose. An outpost is a named queue in Devin Cloud. A worker is the devin worker process that connects to Devin Cloud over outbound HTTPS, claims sessions from the queue, and runs them locally. It doesn’t require inbound ports, a public IP address, or a virtual private network (VPN). Here, one sandbox runs one worker, and that worker serves sessions one after another for as long as the sandbox lives. Each worker serves one active session at a time. Additional sessions wait until a worker becomes available. This guide starts a fixed number of workers. It doesn’t create more sandboxes when sessions queue. Start more workers manually or use an orchestrator to provision them automatically.
CoreWeave Serverless sandboxes are in public preview.

Prerequisites

Before you begin, make sure you have the following:
  • A Devin organization with Outposts enabled. If you don’t see Outposts under Settings > Environment in Devin Cloud, ask your Devin administrator.
  • A W&B API key. These examples use W&B authentication. For other credentials, see Choose a credential.
  • For the direct software development kit (SDK) path, either Python 3.11 or later with uv, or Node.js 22 or later.
Export your W&B API key in the terminal where you run this guide. Unset any CoreWeave token so cws-agent selects W&B authentication:
W&B authentication doesn’t require you to grant the SANDBOX_USER identity and access management (IAM) action separately. If you authenticate with a CoreWeave API access token, grant that action to its principal.

Create an outpost in Devin Cloud

To create an outpost and get its token, follow these steps:
  1. In Devin Cloud, go to Settings > Environment > Outposts.
  2. Click Create Outpost, enter a name, and select Linux.
  3. Copy the outpost token. Devin Cloud shows it once.
With the outpost ready, choose either cws-agent or the Sandbox SDK to start its worker, then run the verification session.

Quick start with cws-agent

Follow the cws-agent installation instructions. The tool configures a snapshot volume to save and restore your workspace with file system snapshots. Replace [OUTPOST-TOKEN] with the token you copied, [OUTPOST-NAME] with your outpost name, and [SANDBOX-NAME] with a cws-agent session name for this sandbox. For the session name, use 1 to 40 lowercase letters, digits, or hyphens, starting with a letter or digit:
The tool passes the token into the sandbox and starts one worker. To pass a platform-managed secret reference, use the Sandbox SDK secret-store option. To view the worker’s terminal, run:
Detach with Ctrl-b, then d, and continue to Run and verify a Devin session. This worker connects to Devin Cloud. It’s separate from the interactive Devin command-line interface (CLI) launched with --agent devin.

Set up with the Sandbox SDK

Use this alternative to launch a worker directly, without cws-agent. It doesn’t configure persistent storage. Run Python snippets in the virtual environment created in Configure credentials and install the client. Save TypeScript snippets as .mts files in the project where you install the client, then run them with npx tsx [FILENAME].mts.

Configure credentials and install the client

Export the token you copied when creating the outpost in the terminal where you run the script:
Choose a client and install it locally:
Use Python 3.11 or later and uv:

Start the worker

To reduce worker startup time, use your own image with the Devin CLI, Git, language runtimes, and project dependencies preinstalled. Set container_image in Python or containerImage in TypeScript to that image. If it already includes Git and certificate authority (CA) certificates, remove the apt-get commands from the example.
The following script creates a sandbox from Cognition’s official worker image and runs devin worker as the sandbox’s main command. The client reads DEVIN_OUTPOSTS_TOKEN from your local environment and passes its value in the sandbox request to set the worker’s environment variable. The worker’s output becomes the sandbox log. If the worker exits with an error, the platform restarts the container up to a retry limit.
start_outpost_worker.py
Run it with the outpost name from Create an outpost in Devin Cloud:
In Python, sandbox.wait() returns when the sandbox is running or has already completed. Installation and worker authentication can still be in progress, so check the worker before submitting a task. The worker starts from /workspace. A session for your-org/app checks out its repository under /workspace/repos/app. The script doesn’t use a with block, so a running sandbox continues after the script exits.
max_lifetime_seconds is a hard cap that can’t be extended later. When it expires, the platform terminates the sandbox, interrupting execution for any session using the worker. This script configures no snapshot or persistent volume. A container restart resets its writable filesystem, including files under /workspace. Keep results outside the sandbox, such as in a repository Devin pushes to.

Optional: Use a secret store

To pass a reference instead of the outpost token value, save the token in a secret store available to your organization. Obtain the store and entry names for your environment.
Import Secret from cwsandbox, remove DEVIN_OUTPOSTS_TOKEN from environment_variables, and add secrets=[Secret(store="[SECRET-STORE]", name="[SECRET-NAME]", env_var="DEVIN_OUTPOSTS_TOKEN")] to Sandbox.run().
Replace both placeholders with the verified names. You no longer need to export the token locally. The platform resolves the reference and sets the worker’s environment variable.

Run and verify a Devin session

Use an outpost with only this worker and no other queued or active sessions for the test. Choose a unique, non-secret value for this test and replace [PROOF-VALUE] in the following task. In Devin Cloud, start a new session and select your outpost under Configuration > Virtual environment. Submit the following task, beginning with Write the exact text. Or, in Slack, send the full message:
After Devin reports completion, read the file from your own terminal using the command for your setup. Replace [SANDBOX-NAME] with your cws-agent workspace name or [SANDBOX-ID] with the ID printed by the SDK script:
Confirm that the output matches your unique value. Reading it through that sandbox’s ID ties the session’s file write to the sandbox you created. The absolute path avoids relying on the session’s working directory. If the session stays queued, check the worker’s log as shown in the next section. A worker serving an earlier session can’t claim another until the earlier session ends or is suspended. If you no longer need the earlier session, end it in Devin Cloud. Alternatively, start another worker.

Check the worker and stop it

For cws-agent, attach to the worker terminal as shown in the quick start. For the SDK path, inspect its status and recent logs. Replace [SANDBOX-ID] with the printed ID:
Rerun this check to fetch newer logs. The Python client also reports per-container state, exit codes, and restart counts. The TypeScript client doesn’t expose those details. If the log reports that the Outposts API rejected the worker’s token, confirm that you used the token copied when creating the outpost. Confirm that the token belongs to the account that owns the outpost. If you use a service user’s v3 API token instead, its role must grant Outposts write (account.outposts.write). Correct the credential, then create the sandbox again. A sandbox can report running while its worker repeatedly exits and restarts. Inspect its logs and, with the Python client, the per-container details shown in the preceding example. Stop a worker that keeps failing authentication before creating its replacement. If startup fails without a useful reason, retain the sandbox ID and logs for CoreWeave Support. Stop the sandbox when you no longer need the worker. See serverless sandbox availability and billing for the current terms. Wait for the active Devin session to finish and save its results, then stop compute using the command for your setup:
down snapshots the workspace before stopping. If capture fails, inspect the reported error and cws-agent status [SANDBOX-NAME], then resolve the failure before retrying. If you can discard unsaved changes, use cws-agent down [SANDBOX-NAME] --no-snapshot.
Ending a Devin session doesn’t stop this worker’s sandbox. To restore a cws-agent workspace, see its Devin Outposts guide.

Optional: Customize the environment

You can customize the worker environment in the following ways:
  • Bring your own image. The official image contains the devin CLI and little else. Build an image from it that adds your toolchain, and pass it as container_image in Python or containerImage in TypeScript. Devin requires git. Screen recording requires ffmpeg, and the browser and computer-use tools require a compatible browser binary. For amd64 images based on the official Ubuntu image, install Google Chrome. Ubuntu’s chromium package is a snap stub that doesn’t work in containers. See Devin’s container setup. Computer use also requires a running graphical display, such as Xvfb, with DISPLAY set for the worker. The worker searches standard install locations. If it doesn’t find your binary, set DEVIN_CHROME_PATH to its absolute path. See the Devin Outposts reference.
  • Configure GPUs. See sandbox GPU configuration for the available options. This guide’s worker example uses CPU resources only.
  • Run more workers. A worker serves one session at a time. Run the script again with the same outpost name to start another worker for the queue.
  • Create one sandbox per session. The worker here reuses its sandbox across sessions. For a fresh sandbox per session, see Devin’s orchestration guide.
Last modified on September 18, 2026