Short answer: if you already run ERPNext, HRMS, CRM, or another Frappe-based application and you want a repeatable, self-hosted, containerized deployment, frappe_docker is the official setup worth evaluating. As of the 9 August 2026 snapshot, the repository is actively maintained, MIT-licensed, and publishes production-oriented Compose files and images. The latest release, v3.2.2, is dated 5 August 2026. That does not make it turnkey: this article is a source and documentation review of repository metadata, the README, release notes, and open issues, with no local installation or runtime testing. Several open issues, including database host grants, Socket.IO behind external reverse proxies, and scheduler health reporting, should be checked against your own environment before production.

Key facts at a glance

What frappe_docker is and who it fits

frappe_docker is the official container setup for Frappe applications. The repository README says it provides Docker images, Compose configurations, and documentation for running Frappe applications in containers, including ERPNext, CRM, Helpdesk, and other Frappe apps. The repository description covers both production and development use, including custom apps.

Consider it if your team already builds on Frappe or plans to, and at least one person is comfortable with Docker Compose:

• You want ERPNext or another Frappe app running on a single server with images and Compose files maintained by the framework team.
• You need a reproducible development environment or a disposable demo for evaluation.
• You build custom Frappe apps and want a defined path to custom image builds.
• You prefer self-hosting and can own upgrades, backups, and incident response.

It fits less well when you have no Docker experience on the team, you need a managed service, or your platform standard is something other than Compose-based containers. The quick demo file (pwd.yml) is explicitly disposable: per the README, you cannot install custom apps in that setup, and it is intended for short-lived evaluation only.

What changed in v3.2.1 and v3.2.2

v3.2.1 (2026-07-03): scaling controls, image size, and startup fixes

According to the maintainers’ release notes, v3.2.1 adds operational controls rather than new application features:

• An INSTALL_CHROMIUM option in the bench, custom, and production builds, letting you skip Chromium when it is not needed and shrink the image by about 180 MB for v15 setups.
• Environment-based settings for server worker count, thread count, and request timeout, so the backend can be scaled without editing Docker files.
• An automatic restart rule for the proxy service, so it starts again after a crash or reboot unless manually stopped.
• A fix for container startup failures by granting read and execute rights to /usr/local/bin/entrypoint.sh inside the images.
• An update to the ARM64 guide so it references ERPNext v16.19.1 images and the correct linux/arm64 platform tag instead of linux/amd64.
• A keep-open label so the stale-bot no longer auto-closes issues that need to stay open.

One caveat: these release notes disclose that they were written with LLM assistance to summarise code changes, PRs, and issues. For anything you rely on in production, check the linked pull requests rather than trusting the summary.

v3.2.2 (2026-08-05): startup sequencing fixes

v3.2.2 is a smaller hardening release. Per the release notes, backend startup is now delayed until the configurator finishes, so the app list is available before services start, and creating the frontend site is skipped when it already exists, which avoids the startup error on repeated runs. The same release updates the pre-commit hook refresh workflow to a supported Python-based step instead of a deprecated action. If you run repeated docker compose up cycles, this is the release to verify against your own stack.

Maintenance signals

The repo shows steady activity. Five releases appear between 20 April and 5 August 2026 (v3.0.1, v3.1.0, v3.2.0, v3.2.1, v3.2.2), the repository was pushed on 6 August 2026, and the snapshot recorded 9 open issues. The README references separate stable and develop image build workflows, and v3.2.0 added an optional migrator service that runs site migrations during startup for automated deployments.

There are also maintenance signals to read carefully:

• Issue #1884 tracks migrating downstream repositories to new reusable CI/CD workflows; at the snapshot, many Frappe repositories (helpdesk, lms, builder, bench, insights, drive, and others) had not started. If you fork or depend on downstream builds, this transition is still in progress.
• Issue #1843 is an open RFC proposing to restructure and rewrite the documentation, with the reporter noting it is currently difficult for new users to get started.
• Issue #1806 raises a question about Python version management: bench now uses uv while the images use pyenv, and the reporter suggests this may conflict. It is an open question, not a confirmed defect.

Deployment concerns: check these before production

If you move forward with a frappe_docker production deployment, use the following as a pre-production checklist grounded in the releases and open issues above:

1. Test the upgrade and startup path. v3.2.2 changes when the backend starts and skips creating an existing frontend site; run repeated compose up cycles against a copy of your data before touching production.
2. Verify custom app builds. v3.2.0 changed custom image builds to rebuild the app installation step when apps.json changes, with guidance for APPS_JSON_HASH and CACHE_BUST, and links bundled app files into the mounted sites folder at startup. Confirm your build process passes apps.json as a secret and that fresh files are used.
3. Check database host grants. Issue #1952 reports that bench new-site grants the app user access from a single container IP, which causes access denied errors from other services; the reporter worked around it by granting privileges to all hosts. Test connectivity from every service after site creation.
4. Validate realtime features behind your proxy. Issue #1939 reports a failed Socket.IO heartbeat check when ERPNext runs behind an external HTTPS reverse proxy with SSL termination, even though websocket upgrades succeed. If you use chat, notifications, or other realtime features, test them through your actual proxy, not just the container network.
5. Decide how you will monitor the scheduler. Issue #1937 reports that the ERPNext System Health Report can show ‘Process Not Found’ for the scheduler even when the scheduler container is running. Do not rely on that single health view.
6. Match ARM64 guidance to your hosts. The v3.2.1 release corrected the ARM64 guide to use ERPNext v16.19.1 images and the linux/arm64 platform tag; if you run ARM64, follow the current guide and pin matching image versions.
7. Be deliberate about skipping Chromium. The ~180 MB saving only makes sense if your apps do not need print or PDF rendering; verify document generation after reducing image size.
8. Load-test before raising worker, thread, or timeout settings. These became environment-configurable in v3.2.1; new knobs are not a substitute for measuring your workload.
9. Plan backups and migrations explicitly. The operations documentation covers backups and upgrades, and the v3.2.0 migrator requires SITE_NAME; test restore and migration on staging.

Limitations and open issues

frappe_docker is an actively maintained container toolchain for a specific stack, and it is not a managed product. It assumes Docker, Docker Compose v2, and git, and it expects someone on your side to operate containers. The disposable demo cannot install custom apps. The Compose orientation means teams standardized on Kubernetes or another platform should evaluate fit before committing, since the evidence here is Compose-based.

Open issues also include a WSL2 devcontainer problem where bench start stops after roughly six and a half minutes due to a Redis connection timeout in the worker, with a reported workaround of raising the socket timeout for redis_queue. That is a development-environment issue, but it signals that dev container defaults may need tuning on some hosts. Combined with the doc restructuring RFC and the in-progress CI/CD migration, the practical message is: check the current docs and issues before you build your process around this repo.

Alternatives and evaluation questions

If containers are not the right fit, the maintainers link Frappe Bench from the README as the alternative toolchain for Frappe development and deployment without this container setup; evaluate it if your operations team prefers virtual machines or bare metal. For teams without anyone comfortable running containers, a managed Frappe or ERPNext service is the more honest comparison than self-hosting with this repository.

Ask yourself before committing:

• Who owns upgrades, backups, and incident response in your organization?
• Do you need custom apps, and can your team maintain custom image builds and the apps.json hash/cache workflow?
• Does your network put HTTPS termination outside the Frappe containers, and does that break the realtime features you actually use?
• Do you run ARM64 hosts, and are your pinned images and tags aligned with the current ARM64 guidance?
• Is the value of self-hosting worth the operational cost versus managed hosting or a partner-run deployment?

Verdict

For teams already invested in Frappe and ERPNext with at least modest Docker experience, frappe_docker is a reasonable option worth evaluating for production. The recent releases are incremental hardening: startup sequencing, restart behavior, image size controls, and environment-based scaling. They are not a rewrite or an architecture change. I would not recommend it as a zero-ops path. Before production, reproduce the upgrade path, validate custom app builds, test realtime features through your real proxy, and confirm database grants across services. If any of those checks fail in your environment, fix them or get help before rollout rather than assuming the defaults will hold.

Sources

• frappe/frappe_docker repository
• frappe_docker documentation site
• Release v3.2.1
• Release v3.2.2
• Issue #1952: MariaDB access denied because user has only one container IP granted
• Issue #1939: Socket.IO heartbeat check fails behind external reverse proxy
• Issue #1937: Scheduler enabled but health report shows Process Not Found
• Issue #1934: WSL2 devcontainer Redis connection timeout
• Issue #1884: Migration of downstream repositories to new workflows
• Issue #1843: RFC improving documentation
• Issue #1806: Python manager in Frappe Docker

If you are weighing whether to move an ERPNext or custom Frappe application into containers, I help founders and operations teams work through these checks: scoping the deployment, building custom app images, planning the upgrade path, and validating the parts that break in production. I am Xiang Peng at XP812; if you want an independent look at your Frappe stack before committing, get in touch.