Open source · self-hosted · MIT

Coolify for coding agents

Warren runs coding agents against your GitHub repositories, on your own infrastructure, under your own API keys. Point it at a repository, pick an agent, and write a prompt. Warren clones the repository, runs the agent inside a sandbox, and streams every event back to you while it works. When the agent stops, warren pushes the branch and opens a pull request.

One container, one volume, one HTTP API, one UI.

warren — dispatch a run
$ warren add-project https://github.com/acme/checkout
cloned to /data/projects/acme/checkout
$ warren run claude-code checkout -p "fix the flaky auth test"
{"kind":"state_change","payload":{"state":"running"}}
{"kind":"tool_use","payload":{"name":"Read","path":"auth/session.test.ts"}}
{"kind":"tool_use","payload":{"name":"Edit","path":"auth/session.ts"}}
{"kind":"state_change","payload":{"state":"succeeded"}}
pushed burrow/run_9f31c47a20b6 · pull request opened
Current release
0.11.0
HTTP API paths
36
CLI commands
15

How it works

From a prompt to a pull request

  1. Add a project. Give warren a GitHub URL. Warren clones the repository onto its own volume.
  2. Dispatch a run. Pick an agent and write a prompt. Send it from the web UI, from the warren CLI, or straight to the HTTP API. All three take the same path through warren.
  3. Watch and steer. Events stream as NDJSON while the agent works. Send a message mid-run and the agent reads it on its next turn. Cancel the run and warren stops it cleanly.
  4. Take the branch. Warren pushes the workspace branch and opens a pull request. The sandbox goes away with the run.

What warren gives you

Agents

Bring the harness you like

The claude-code, sapling, and pi agents ship inside the image, so a fresh install can dispatch a run with no extra setup. Point warren at a prompt library and your own agents override the built-ins by name.

Sandbox

Every run is sandboxed

On a single host, each run gets a fresh bwrap workspace and the host stays out of reach. On Kubernetes, each run is its own pod and the kubelet holds the CPU and memory limits. One runtime contract covers both, and warren picks the backend once at boot.

Steer

Change your mind mid-run

Every tool call, every state change, and every line of agent output lands in the event log and tails to your browser. Warren does not make you wait for the end. Send a correction, and the agent picks it up on the next turn.

Schedule

Runs that start themselves

A .warren/triggers.yaml file defines cron triggers per project. The scheduler dispatches them on the same path a manual run takes, so a nightly patrol and a hand-typed prompt behave the same way.

Repair

Warren fixes its own pull requests

When the checks on an agent-authored pull request fail, warren dispatches a repair run against that same branch. A retry cap and a cooldown per pull request hold the loop in check. A monitoring alert can post to /alerts/heal, and warren opens a fresh branch with the fix. Both loops stay quiet until you turn them on per project.

Opt in

Extras that stay quiet until you want them

A project with a .mulch/ directory gets its expertise primed into every run, and new records merge back at the end. A project with a .seeds/ directory hands agents an issue queue to read from and write to. A project with neither behaves exactly the same.

Self-host

One container. Your box.

Clone the repository, fill in a .env file, and run docker compose up -d. Warren serves the API and the UI on one port. Runs, events, and projects live in a SQLite file on one volume. Set WARREN_DB_URL and warren talks to Postgres instead.

A bearer token guards every route except /healthz. TLS stays at your edge, behind Caddy on a home server or behind your ingress on a cluster. When one box is no longer enough, set WARREN_RUNTIME=k8s and each run becomes a Kubernetes pod.

Warren carries the MIT license. Read the code, fork it, run it.

Read the Kubernetes runbook

Point it at a repository and see what comes back

Warren runs on GKE in continuous use against real GitHub repositories. An acceptance harness drives the whole path against a live stack: dispatch, sandbox, steer, reap, pull request.

Start with the quickstart