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.

Watch it liveapp.warren.run · real runs, no login

Read the quickstart View the source

app.warren.runliverun_9f31c47a20b6claude-codeacme/checkoutrunningstate_changequeued → runningtool_useRead · auth/session.test.tstool_useEdit · auth/session.tsmessagealso cover the expired-token casetool_useEdit · auth/session.test.tsstate_changerunning → succeeded · pull request openedburrow/run_9f31c47a20b6Open the live demo

Current release: 0.13.2
HTTP API paths: 36
CLI commands: 14
License: MIT

How it works

From a prompt to a pull request

Four stages, one path. The web UI, the warren CLI, and the HTTP API all take it, so a nightly trigger and a hand-typed prompt behave the same way.

ProjectAdd a repositoryGive warren a GitHub URL. Warren clones it onto its own volume.
DispatchPick an agent, write a promptThe claude-code, sapling, and pi agents ship inside the image. Point warren at a prompt library and your own agents replace the built-ins by name.
RunWatch and steerThe agent works inside a sandbox. Events stream as NDJSON, and a message you send mid-run reaches the agent on its next turn.
ResultTake the branchWarren pushes the workspace branch and opens a pull request. The sandbox goes away with the run.

Three things you get either way

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.

Autonomy

Runs that start and fix themselves

A .warren/triggers.yaml file defines cron triggers per project, and the scheduler dispatches them on the same path a manual run takes. 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 hold that loop in check. Both loops stay quiet until you turn them on per project.

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 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.

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