BenchPress and frappe_docker.
frappe_docker builds a bench. BenchPress hands one out. They are not rivals — BenchPress runs on the same ideas, and if you are happy writing a compose file you do not need it.
What frappe_docker is
The official container setup for Frappe, maintained in the framework's own organisation under MIT. It ships production images and a compose.yaml, a pwd.yml for a disposable demo, and a VS Code devcontainer for working on Frappe apps locally. It is the correct starting point, and it is where most teams start.
It is also, by its own description, an environment — a configuration you take and adapt. The repository has around 2,500 stars and around 2,700 forks. More forks than stars is unusual, and it says something plain: teams copy it and edit it rather than run it as it comes. Each of those edited copies is a compose file somebody now maintains by hand.
The two, side by side
Read the first four rows as the case for frappe_docker. It wins them, and it should.
| frappe_docker | BenchPress | |
|---|---|---|
| Maintained by | Frappe Technologies, the framework's own team | One author. Alpha, and the README says so first |
| Production | Yes — that is half of what it is for | No. Development and demo environments only |
| Needs a server | No. A laptop with Docker is enough | Yes. One Linux host, plus an existing Frappe v16 bench |
| Community | Thousands of users, and every search result | New, and small |
| Getting an environment | Edit a compose file, build, create the site, install the apps | Pick a template, press deploy |
| Who can do it | Someone who knows Docker and bench | Anyone with a login. The bench commands stay in the log |
| Four clients, four app stacks | Four configurations, maintained by hand, free to drift | Four lab templates, each pinned to a version and an app list |
| Reaching the site | Publish a port, or set up a proxy yourself | A WireGuard address per environment, one revocable key per device |
| Editing the code | A local devcontainer, on the developer's own machine | Browser VS Code inside the container that serves the site, shareable |
| When a build fails | Terminal scrollback | The failing step named, in a deploy log kept per run |
| Tearing it down | `docker compose down -v`, and remember the volumes | A confirmation that names the container, the site and the databases |
| Who has access | Whoever has the shell | Roles and ownership: users see their own, admins see everything |
Stay with frappe_docker if
- You are one developer, on one project, with one Frappe version.
- You are deploying production. BenchPress is not for that, and says so.
- You have no server to dedicate, and no appetite for alpha software.
- Writing a compose file does not cost you anything you mind spending.
BenchPress earns its place when
- You maintain more than one client's app stack at a time.
- People who do not know Docker need working environments — a joiner, an intern, a designer, a client reviewing a build.
- You are the person environments always land on, and you would rather not be.
- Betas and client instances have to be reachable by the team and by nobody else.
- An environment should cost nothing when nobody is using it.
It is the same machinery underneath
BenchPress is a control plane, not a runtime. It talks to a Docker daemon and runs the bench commands you would have typed — resolve the app list into an apps.json, build or restore the image, create the site, install the apps, migrate, build the assets, join the network, health-check, hand over the credentials. Eleven steps, each one visible in the log.
Nothing about that is secret, and none of it is a replacement for frappe_docker's work. It is the layer above it: who gets an environment, how they reach it, and how it goes away.
Questions people actually ask
Is BenchPress a replacement for frappe_docker?
No. BenchPress is a layer above it. frappe_docker defines how a Frappe bench runs in Docker; BenchPress turns one bench definition into something a whole team can each deploy for themselves, with access control, a private address and a teardown button.
Can I keep using my own frappe_docker setup?
Yes, and many teams should. BenchPress installs into a Frappe bench on one host and manages containers there; it does not ask you to abandon a compose file that already works for production.
Why not just add scripts to frappe_docker?
Because the missing parts are not scripts. Templates, roles, per-device network keys, a deploy log, leases and a teardown flow need somewhere to live and somebody to log in to. That is an application, which is what BenchPress is.
Which one is faster to a working site?
frappe_docker is faster the first time, on one machine, for someone who knows it. BenchPress is faster every time after that, for everyone else: a cached template deploys in about a minute, and the first person to need it is not the one who configured it.
See what running it takes.
The preconditions, the real commands and the six things that break on a first install are on one page. If it looks like more than you want to own, the repo is right there and frappe_docker is not going anywhere.