ERPNext Docker vs bench installation

The `compose.yaml` file is the base for a production setup, while `pwd.yml` is a single-file demo meant only for short-lived evaluation. The frappe_docker project builds its production path around the first file, so a team planning a long-lived ERPNext environment should start from compose.yaml and treat pwd.yml as a way to try the software, not a foundation to grow. The two files answer different questions, and mixing them up is the most common way an evaluation quietly becomes a production system.

The production stack is split into separate services: MariaDB for the database, Redis for caching and queues, background workers that run long jobs, a scheduler for timed tasks, Socket.io for real-time updates, and Nginx to serve static files and route requests. Each service can be sized, monitored, backed up and restored on its own terms, which is why your platform team should review the service list against its own operating model before committing. Confirm with the frappe_docker documentation which volumes hold database and site data, since those define your backup scope.

Custom apps are the point where the demo and production routes split. The frappe_docker README states that `pwd.yml` cannot install custom apps, and it names building custom app images as the documented route for adding them. Any in-house code, third-party app or industry extension therefore has to be baked into an image your team builds, versions and stores. Plan for that image pipeline early, including who owns the build, how images are tagged for each ERPNext release, and how a failed upgrade rolls back to the previous image.

The software itself costs nothing to self-host. The ERPNext pricing page states that self-hosting ERPNext is free, so the budget for either route is made up of people and infrastructure. Your staff or a partner's team is paid to build and harden the host, run the bench or Compose stack, configure accounting and inventory, and test every upgrade before it reaches production. Infrastructure is paid monthly or yearly: virtual machines or bare metal, storage for MariaDB and backups, and any load balancer or monitoring service you add. Both routes carry these costs, but the Docker route shifts more of the host work into image builds and Compose files, while the bench route puts Supervisor, Nginx and the server operating system on your team's plate.

Custom apps and upgrades are the costs that grow over time. Each custom app adds development, code review and a test cycle for every ERPNext minor release, and on the Docker route it also adds an image build pipeline. The frappe_docker README says the pwd.yml demo cannot install custom apps, so any custom work starts with building your own image. Ask a partner to price custom app work separately from platform setup, and to state who maintains the custom code after go-live. Confirm the upgrade process with the vendor's support versions page before you commit, since version 15 and version 16 have different support windows.

Frappe Cloud is a comparison point, not a default. Frappe Cloud shared site hosting starts at 5 US dollars per month, shared servers start at 20 US dollars per month and dedicated servers start at 125 US dollars per month, according to the ERPNext pricing page. Those figures show what managed hosting costs at the entry level, but they do not include your implementation, custom app work or the staff time you would still need. A quote for self-hosting follows from a written scope that lists hosts, components, custom apps, backup targets, upgrade testing and support hours, so ask every bidder to price those items separately and to name what recurs each month and what is paid once.

Switching from Docker to bench, or back, after go-live is a migration project, not a configuration change. The data lives in a MariaDB database and a site directory, and the two routes arrange those files differently. Moving a site means exporting it from the source environment, restoring it into the target, reattaching files and private storage, and confirming that every site and its backups still line up. Custom apps add a second track. On the Docker route they must be packaged into a custom image, because the demo pwd.yml cannot install them at all, and on the bench route they must be installed into the bench and kept at matching versions. Each app therefore has to be rebuilt and tested on the target before the data moves.

Plan for the network side as well. DNS records, TLS certificates, and the reverse proxy configuration all change when the entry point moves from one stack to the other, and the Nginx layer that serves static files and proxies requests on a bench production setup is not the same as the proxy layer in the Compose stack. Background workers, the scheduler and Socket.io also need to start and point at the right Redis and database services before users return. Ask Frappe through its documentation and support channels which export and restore steps are supported for your ERPNext and Frappe version, and whether a route change is covered by the upgrade path you intend to use.

Rehearse the full move in a non-production environment with a recent copy of production data, custom apps and integrations included, and time each step against the cutover window you actually have. Check that scheduled jobs, email, login integrations such as LDAP or social login, and document permissions behave the same afterward. Treat the rehearsal output as the basis for the cutover runbook and rollback plan, and keep the original environment intact until users have confirmed their work.