DevBox is open source

DevBox runs on your infrastructure, with your model keys. It is built for a whole engineering org: one shared harness that picks up Linear, Jira and ClickUp tickets, answers on GitHub pull requests, works across your repos, and remembers what it learned in them. Join the community on rudderstack.com/devbox.

Hand DevBox a ticket. It plans the change, writes the code, runs the tests, reviews its own work and opens a draft pull request. You review and merge. Comment on the pull request, and it pushes the fix to the same branch.

Why we built it

We are RudderStack, a customer data infrastructure company. Since April our engineers have handed tickets to DevBox. Today it merges about 35% of our internal pull requests, with about an 80% merge rate. Read the story behind it.

Coding tools like Claude Code and Codex make one developer faster. We wanted the other half: a shared teammate the whole org can delegate to, that runs where our code and secrets already live, and that gets better at our repos over time. DevBox works alongside those tools.

Features

• Staged pipeline. Orientation, planning, plan review, implementation, self-review. A reviewer checks the plan. If it finds issues, the planners of the affected repos revise once, and the revision is not reviewed again, before any code is written.
• Closed feedback loop. Review comments, @mentions and failed CI runs route back to the running task (with the GitHub App).
• Versioned memory. Learnings are distilled into your repo and land as a commit on the pull request, reviewed like code.
• Credential isolation. Sandboxes hold placeholder tokens. An egress proxy injects the real ones and scopes writes to your repos.
• Per-stage model routing. OpenAI or Anthropic, with model and reasoning effort set per stage.
• Self-hosted. Docker Compose or Kubernetes, one isolated sandbox per task.

How it works

• The control plane (control-plane/) stores tasks, starts a sandbox for each one through OpenSandbox and relays messages and progress. It makes no LLM calls.
• The harness (harness/) runs in the sandbox, built on DeepAgents, and takes the task from plan to pull request.
• iron-proxy sits between the sandboxes and GitHub and the LLM. It swaps placeholder tokens for real ones and allows writes only to your repos.

docs/architecture.md has the details.

Quickstart

About 15 minutes, most of it the first image build. The steps assume macOS; see the notes below for Linux.

You need: Docker Desktop with 8 GB of memory for Docker (Compose 2.13 or newer), Bun 1.4.4 or newer, make, openssl, a GitHub token or gh logged in, and an OpenAI or Anthropic API key.

[!TIP] Prefer to let an agent do it? Run claude in the cloned repo and ask it to set up DevBox (other coding agents can read skills/devbox/). Run the bun run quickstart command it gives you yourself, so your keys go to its hidden prompts and never through the chat.

1. Get the code.

   git clone https://github.com/rudderlabs/devbox.git && cd devbox
   

2. Pick your repo and model. Copy the example config, then set your repo's URL and your LLM in it.

   cp devbox.config.example.json devbox.config.json
   

   {
     "repos": [{ "url": "https://github.com/your-org/your-repo.git", "branch": "main" }],
     "llm": { "provider": "openai", "baseUrl": "https://api.openai.com/v1", "model": "gpt-5.6-sol" }
   }
   

   DevBox only ever writes to the repos listed here. Anthropic and per-stage models: docs/configuration.md.

   Or skip this step: when there is no devbox.config.json, bun run quickstart asks for your repos and model and writes it.

3. Start DevBox.

   bun run quickstart
   

   It checks your config and the tools you need, and asks whether to run on Docker Compose or a local kind cluster and whether to set up Linear and the GitHub App now (say no for a first try; Next steps adds them later). Then it starts DevBox with bun run up, which asks for your GitHub token (or takes it from gh) and your LLM key, and offers to save them in the macOS Keychain, never in a file. It builds the images (about 10 minutes the first time) and logs the CLI in.

4. Give it a task.

   bun run devbox create "Add a /health endpoint to your-org/your-repo"
   

   It prints the task's key, for example DBX-API-1.

5. Watch it work.

   bun run devbox logs -f DBX-API-1
   

   You see it orient, plan, review its plan, implement, test and review its own diff. At the end, a draft pull request opens on your repo, under your GitHub account.

6. Ask for changes.

   bun run devbox send DBX-API-1 "Also add a test"
   

   It pushes new commits to the same pull request.

7. Stop it.

   bun run down
   

   Your tasks are kept for the next bun run up. deletes them.

Explore the CLI: bun run devbox --help lists every command: ls, show, wait, restart and more.

[!WARNING] Linux: add your user to the docker group (sudo usermod -aG docker $USER, then log out and back in). bun run up uses the Secret Service (libsecret) instead of the Keychain.

[!TIP] On a corporate network or VPN that blocks public DNS, run bun run up --dns-resolver <host:port> with a DNS server that works there. After you change devbox.config.json, run bun run up again. After you change the model, try it on a new task.

This is the beginning of the README. Read the rest at the original. Read the full README ↗