Open Agents: a Vercel reference app for background coding agents
An open source template for building cloud agents.
At a glance
- What is it?
- Open Agents is a three-layer TypeScript template from vercel-labs for running coding agents outside the sandbox they operate on. The architecture is the interesting part, and the deployment checklist is the price of admission.
- Who is it for?
- Adopt Open Agents if you want a Vercel-native starting point for a background coding agent and you are willing to run the GitHub App and Vercel OAuth setup yourself. Do not adopt it if you need a supported product, a non-Vercel runtime, or a fully self-contained local environment.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 18 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Open Agents addresses: agents that outlive a request
A coding agent that clones a repository, installs dependencies, edits files and runs tests does not fit inside a single HTTP request. The README positions Open Agents as "an open-source reference app for building and running background coding agents on Vercel," which is a narrower claim than it first appears. It is not a hosted agent product. It is a template meant to be forked and adapted, and the README says so directly: the repo is "meant to be forked and adapted, not treated as a black box." That framing tells you the intended audience. This is for engineers who already know they want an agent that works on code in the background, and who want a working skeleton of the web UI, the runtime, the sandbox orchestration and the GitHub integration rather than a blank repository. Teams that want to evaluate an agent's output quality will find nothing here to evaluate. The value on offer is structural: a decision about where the agent process lives relative to the machine it controls.
The agent is not the sandbox, and that is the whole design
The README describes a three-layer system as "Web -> Agent workflow -> Sandbox VM." The web app handles auth, sessions, chat and the streaming UI. The agent runs as a durable workflow on Vercel. The sandbox is the execution environment with a filesystem, shell, git, dev servers and preview ports. The architectural claim is stated as a heading in the README: the agent is not the sandbox. The agent process runs outside the VM and reaches into it through tools for file reads, edits, search and shell commands. Four consequences are listed. Agent execution is not tied to a single request lifecycle. Sandbox lifecycle can hibernate and resume independently. Model and provider choices can evolve separately from the sandbox implementation. And the VM stays a plain execution environment instead of becoming the control plane. That last point is the one worth arguing about. Keeping the control plane out of the VM means the sandbox can be destroyed and rebuilt without losing agent state, but it also means every file read and every shell command crosses a boundary. For an agent that spends most of its time reading large files, that boundary is where latency accumulates. The README does not quantify it, and I have not measured it.
Durable runs, snapshots, and the ports a sandbox exposes
Chat requests do not execute the agent inline. According to the runtime notes, a chat request starts a workflow run, and each agent turn can continue across many persisted workflow steps. Runs are backed by the Workflow SDK, with streaming and cancellation. An active run can be resumed by reconnecting to the stream for the existing workflow, which is the mechanism that makes a browser refresh survivable. Sandboxes are isolated Vercel sandboxes with snapshot-based resume. They expose ports 3000, 5173, 4321 and 8000, which covers the default ports for Next.js, Vite, Astro and a generic Python or Node server. They hibernate after inactivity. Fresh sandboxes can optionally start from a configured base snapshot via VERCEL_SANDBOX_BASE_SNAPSHOT_ID; without it, they start from Vercel's standard Sandbox runtime. Repo cloning and branch work happen inside the sandbox. Auto-commit, push and PR creation exist but are described as preference-driven rather than always-on, which is the right default: an agent that pushes to a branch without an explicit preference is a liability. Session sharing via read-only links and optional voice input through ElevenLabs transcription round out the stated capabilities.
Getting a copy running: the deploy path and the local path
The deploy path is a fork, an import into Vercel, and a sequence of redeploys as you add credentials. Minimum runtime needs POSTGRES_URL and BETTER_AUTH_SECRET. The README gives the command for the secret: openssl rand -base64 32. Neon Postgres is auto-provisioned if you use the deploy button. Sign-in requires a Vercel OAuth app with the callback https://YOUR_DOMAIN/api/auth/callback/vercel, plus NEXT_PUBLIC_VERCEL_APP_CLIENT_ID and VERCEL_APP_CLIENT_SECRET. The full GitHub flow requires a GitHub App with homepage https://YOUR_DOMAIN, callback https://YOUR_DOMAIN/api/auth/callback/github and setup URL https://YOUR_DOMAIN/api/github/app/callback, and the README notes the app should be made public if you want org installs to work cleanly. That is six GitHub-related variables: NEXT_PUBLIC_GITHUB_CLIENT_ID, GITHUB_CLIENT_SECRET, GITHUB_APP_ID, GITHUB_APP_PRIVATE_KEY, NEXT_PUBLIC_GITHUB_APP_SLUG and GITHUB_WEBHOOK_SECRET. Locally, the sequence is corepack enable, pnpm install, cp apps/web/.env.example apps/web/.env, fill in the values, then pnpm web. If the project is already linked to Vercel, vc env pull can fetch the variables. Auth itself runs through Better Auth with Vercel and GitHub as social providers, served from the /api/auth/[...all] catchall.
Where the template stops helping
The environment list is the honest map of the dependencies. Postgres is not optional. A Vercel account is not optional, because sandboxes are Vercel sandboxes and the agent runs as a Vercel workflow. The GitHub App is not optional if you want the coding-agent loop, which is the reason most people would look at this repository in the first place. Redis and KV are genuinely optional: REDIS_URL and KV_URL back a skills metadata cache that falls back to in-memory when unset, so a single-instance deployment can skip them. The resource profile flag is the one that catches people. OPEN_AGENTS_RESOURCE_PROFILE set to hobby switches chat and sandbox resources to Hobby-compatible defaults; leaving it unset gives standard behavior. A Hobby plan deployment that omits this flag is running defaults it may not be entitled to, and the README does not say what happens when those defaults exceed the plan. The base snapshot variable carries a similar warning: use a snapshot created in or accessible to your own Vercel scope. There are no releases retrieved for this repository, so there is no changelog to read before upgrading. You are tracking the main branch.
How this differs from running an agent inside a container
The obvious alternative is an agent that executes inside the same container as the code it edits, which is how most self-hosted coding agents are structured. In that model the agent loop and the shell share a filesystem, so a file read is a local call and a test run is a subprocess. The trade is lifecycle. If the agent and the sandbox are the same process tree, killing the sandbox kills the run, and resuming means replaying from whatever state was persisted outside. Open Agents inverts that: the workflow is the durable thing, and the sandbox is disposable. The README lists hibernation and snapshot-based resume as capabilities, and those only make sense under this split. The cost is that you cannot run the whole system on one machine without Vercel in the loop, and every tool call is a network hop. If your agent's work is short and interactive, the split buys you little. If your agent's work is long, parallel, or expected to survive a closed laptop, the split is the point.
Licence, maintenance, and what forking actually commits you to
The licence is MIT, which permits commercial use, modification and redistribution with the copyright notice retained. That is permissive enough that forking into a private product is legally unremarkable, though I am not a lawyer and the repository's LICENSE file is the authority. The maintenance picture is less clean. There are no releases retrieved, so upgrades arrive as commits on main rather than tagged versions. The environment surface is nine required variables for the full flow plus six optional ones, and each one is a place where a fork can drift from upstream. The README explicitly hands you the adaptation burden: this is a reference app, not a library with a stable interface. Practically, that means a fork should treat the upstream repository as a source of ideas and occasional patches rather than a dependency to pull. The Vercel OAuth app, the GitHub App registration, the Postgres instance and the snapshot all live in your accounts, so nothing breaks when upstream changes, and nothing gets fixed either.
Editorial conclusion
Adopt Open Agents if you want a Vercel-native starting point for a background coding agent and you are willing to run the GitHub App and Vercel OAuth setup yourself. Do not adopt it if you need a supported product, a non-Vercel runtime, or a fully self-contained local environment. Before you commit, verify that your Vercel scope can create and access the snapshot ID you intend to use for VERCEL_SANDBOX_BASE_SNAPSHOT_ID, and confirm that the auto-commit and auto-PR paths match the review workflow your team actually uses.
Community notes