Devin Outposts connect Devin Cloud sessions to compute you choose, but running an outpost otherwise means keeping a worker process awake and connected. With the Devin Outposts for Vercel integration, each Devin session runs on Vercel infrastructure in a dedicated Vercel Sandbox Firecracker microVM, and the orchestration that claims and monitors sessions runs on Vercel as well.
Devin's inference and planning stay with Cognition, while command execution, file edits, and repository access happen inside the session's sandbox. After a one-time browser authorization, no laptop or desktop process needs to remain online, so you can start a Devin session from a phone or any other device.
Copy link to headingOverview
In this guide, you'll learn how to:
- Deploy the Devin Outposts integration to a Vercel team with the Deploy Button
- Authorize the connection in Devin without copying tokens or API keys
- Adjust sandbox defaults such as runtime, vCPUs, and concurrency
- Resolve common setup and session issues
Copy link to headingPrerequisites
Before you begin, you need:
- A Devin account with Outposts enabled and administrator access. Authorizing the connection requires a Devin admin with both enterprise-settings and service-user management rights.
- A Vercel team on the Pro or Enterprise plan. The one-minute cron schedule and sandbox sessions of up to 24 hours require Pro or Enterprise.
Copy link to headingHow the integration works
The deployed control plane runs entirely on Vercel:
- Vercel Cron invokes a bounded Fluid compute function once per minute. That function polls Devin's queue every 3 seconds for 57 seconds and starts one durable workflow per pending session.
- Each session workflow provisions a named, persistent sandbox, starts
devin-remote serve, and sleeps between status checks. - The sandbox runs the session's commands, file edits, and repository access, while the workflow handles monitoring, timeout extension, claim release, teardown, and snapshot persistence.
Devin's Outposts concepts map to Vercel primitives:
| Outposts concept | On Vercel |
|---|---|
| Machine per session | One Vercel Sandbox microVM |
| Session state | Named persistent sandbox restored from its newest snapshot |
| Network restrictions | Devin hostname and IP allowlists map to sandbox firewall rules |
| Session end | A clean devin-remote exit, or Devin marking the session complete; the integration then releases its session claim and stops the sandbox. |
Copy link to headingSet up the integration
Setup runs through a browser authorization flow, so there is no Devin token, API key, or setup secret to copy.
Copy link to heading1. Deploy the repository
Open the devin-outpost-vercel repository, click Deploy with Vercel, and choose the destination Vercel team.
Copy link to heading2. Add the required integration
Add Devin Outposts for Vercel when the Deploy Button asks for the required integration. The integration handles the authorization exchange and writes the runtime configuration to the new project, so you don't configure any environment variables by hand.
Copy link to heading3. Authorize the connection in Devin
Sign in to Devin as an administrator, review the suggested outpost name, and click Connect. The integration exchanges Devin's short-lived, single-use authorization code server-to-server using Proof Key for Code Exchange (PKCE) and adds the encrypted runtime configuration directly to the new Vercel project.
Copy link to heading4. Complete the deployment
Let Vercel finish creating and deploying the project. The first queue poll occurs within one minute of deployment.
Copy link to heading5. Start a session on the new outpost
In Devin, start a session and select the new Vercel outpost as its virtual environment.
Copy link to headingConfigure sandbox defaults
The integration works without additional configuration. These environment variables change its behavior:
| Variable | Default | Description |
|---|---|---|
SANDBOX_RUNTIME | node24 | Sandbox runtime |
SANDBOX_VCPUS | 2 | vCPUs per session sandbox |
SANDBOX_TIMEOUT_MS | 1200000 (20 minutes) | Initial and extension duration in milliseconds |
MAX_CONCURRENT | 5 | Maximum active sandboxes |
POLL_INTERVAL_MS | 3000 | Queue polling cadence in milliseconds |
Sandbox lifetime is extended automatically when less than 10 minutes remain, and each stop keeps only the newest snapshot.
Copy link to headingHow the integration handles credentials
The connection is authorized in the browser, but no credential passes through it. Each value involved in the exchange is scoped and protected:
| Credential | How it's handled |
|---|---|
| Authorization code | Single-use; the only value relayed via browser redirect |
| PKCE verifier | Encrypted, expires after 10 minutes, and consumed atomically |
| Devin access token | Returned only from the server-to-server exchange; encrypted with AES-256-GCM before storage |
| Vercel credentials | Provided automatically to the Sandbox SDK through OpenID Connect (OIDC); nothing to configure |
Because Vercel supplies OIDC credentials automatically, do not add VERCEL_TOKEN, VERCEL_TEAM_ID, or VERCEL_PROJECT_ID to the deployment. The only exception is local mode, covered in the FAQ below.
Copy link to headingTroubleshooting
Copy link to headingThe outpost is not picking up sessions
Cron jobs run only on production deployments, so a preview deployment never polls the queue. Promote the project to production, then expect the first poll within one minute.
Copy link to headingSessions stay queued when the outpost is busy
The integration runs up to 5 session sandboxes at a time by default, so additional sessions wait in Devin's queue until a slot frees up. To run more sessions in parallel, raise MAX_CONCURRENT in the project's environment variables and redeploy.
Copy link to headingFrequently Asked Questions
Copy link to headingDoes my code leave Vercel during a session?
Devin's control plane stays with Cognition, and inference and planning run in Devin's cloud. Command execution, file edits, and repository access happen on Vercel inside the session's sandbox.
Copy link to headingWhat happens to session state between runs?
Each session uses a named, persistent sandbox that restores from its newest snapshot. Only the newest snapshot is kept after each stop.
Copy link to headingCan I run the orchestrator locally instead?
Yes, local mode is useful for development. Copy .env.example to .env, then add the Devin variables and the three Vercel access-token variables documented in the example:
VERCEL_TOKENVERCEL_TEAM_IDVERCEL_PROJECT_ID
These three variables are required only in local mode. In a Vercel deployment, OIDC replaces them, so leave them out.
With the variables in place, install dependencies and start the orchestrator:
The computer running local mode must stay awake and connected for queue polling and session monitoring. Local mode moves only the orchestration process to your machine; the sandboxes themselves still run on Vercel.
Copy link to headingWho can use this integration?
The integration is available to Vercel Pro and Enterprise teams with Devin Outposts enabled. This is because the queue poll runs on a once-per-minute cron (Hobby cron jobs run at most once per day), and sessions can run up to the 24-hour sandbox maximum (Hobby sandboxes stop after 45 minutes).
Copy link to headingNext steps
- Learn how sandboxes work, including snapshots and persistence, in the Vercel Sandbox documentation.
- Review Sandbox pricing and limits to estimate session costs.
- Check Cron Jobs usage and pricing for scheduling limits by plan.
- Explore the devin-outpost-vercel repository for the integration source and
SPEC.mddesign details. - Read the Devin Outposts overview for the Cognition side of the setup.