Ralph Workflow Now Ships with Docker: One Command to an AI Coding Orchestrator

Ralph Workflow just got a new install path — a multi-stage Docker image that drops the friction of Python toolchains and lets you spin up an AI coding orchestrator in one command.

If you have Docker installed, you are now two minutes from running your first unattended coding task:

git clone https://codeberg.org/RalphWorkflow/Ralph-Workflow.git
cd Ralph-Workflow/ralph-workflow
docker build -t ralph-workflow .
docker run --rm -it -v "$(pwd):/workspace" -v "$HOME/.ralph:/root/.ralph" ralph-workflow

No Python, no pip, no venv. The image bundles everything Ralph Workflow needs — the orchestrator CLI, the verification engine, the recovery loop — into a 465MB container that works on any machine with Docker.

Why Docker matters for an AI coding workflow

Running AI coding agents locally has a dependency problem. You need Python, git, the right model CLI (Claude Code, Codex, OpenCode), and often a specific version of each. A missing dependency or version mismatch can turn "run overnight" into "debug the toolchain until 2 AM."

A Docker image solves this by being a reproducible, self-contained environment. It also opens doors that a pip package alone cannot:

1. CI/CD pipelines. GitHub Actions, GitLab CI, or any container-based CI system can now run Ralph Workflow as a step — no Python setup required. Schedule overnight runs from your pipeline, not your laptop.

2. Air-gapped environments. Build the image once, transfer it to a machine without internet access, and run autonomous coding tasks there. The container carries its own runtime.

3. Team standardization. Pin a specific Ralph Workflow version in a Dockerfile and every developer on the team runs the exact same orchestrator. No more "it worked on my machine" for your AI coding workflow.

4. Ephemeral task workers. Spin up a container per task, let it run, collect the result, throw away the container. Clean isolation with zero leftover state.

What is in the image

The Dockerfile uses a three-stage build to keep the final image lean:

• Stage 1 fetches the uv Python package manager binary
• Stage 2 resolves and installs Ralph Workflow and all its dependencies into a virtualenv
• Stage 3 copies only the virtualenv into a clean python:3.13-slim base, adds git (required for repo operations), and exposes ralph, ralph-mcp, and ralph-prompt as entrypoints

The result: a 465MB image that starts in under a second and includes all three Ralph Workflow CLI entry points.

Two volume mounts, one command

The container needs two bind mounts to work:

That is it. The image has no secrets baked in — everything comes from your host.

The install surface portfolio

With Docker, Ralph Workflow now has four install paths:

1. pipx — recommended for most users, clean system-wide install
2. PyPI — standard pip install ralph-workflow
3. Docker — zero-dependency container, CI/CD-friendly
4. From source — git clone + pip install -e .

Each path serves a different workflow. Docker serves the one where you want reproducibility, CI/CD integration, or a clean environment without touching your local Python setup.

Try it

The Dockerfile is in the Ralph-Workflow repo on Codeberg. Clone it, build it, and run your first overnight task in a container.

If something breaks or you have a feature request, open an issue on Codeberg. The project is AGPLv3 — open source, vendor-neutral, and actively maintained.