Repository navigation
Use bench inside docker like VM #2011
Description
@DanielRadlAMR
1 humble request - For the docs can we have a tutorial where we can just change the bindings in the erpnext pwd.yml so that we can run bench commands get-app, install-app, build and update inside docker
I do know that a developer can use dev mode mentioned at https://github.com/frappe/frappe_docker/blob/main/docs/05-development/01-development.md
But 1) this is not for production, 2) does not have erpnext installed and 3) we need to learn the docker way of adding/updating apps - https://github.com/frappe/frappe_docker/blob/main/docs/01-getting-started/02-docker-immutability.md#correct-workflow
What I would like is an easy way to use all bench commands the native VM way with the benefits of docker like we can do at https://github.com/rtCamp/Frappe-Manager
In my understading you just need to make one small change in all the places volumes have been mentioned: -
Replace:
volumes:
- sites:/home/frappe/frappe-bench/sites
- logs:/home/frappe/frappe-bench/logs
with
volumes:
- ./frappe-bench:/home/frappe/frappe-bench
Hope I am right? What would the unintended effects of this be? I have used Frappe Manager for some time and I have not faced any issues so therefore I think it should be possible (the template they use is available at https://github.com/rtCamp/Frappe-Manager/blob/bee39ea541ee1b632cc0dae51780fb3169873c1b/frappe_manager/templates/docker-compose.tmpl#L11)
Refer for current issue and there are others in the discuss forum still using bench in docker: -
https://discuss.frappe.io/t/frappe-installation-and-ui-error/165102/5
Activity
DanielRadlAMR commentedon Oct 9, 2026
I think it's not quite as straightforward as you might think.
I mean, mounting the entire Bench directory as a volume would essentially achieve what you're looking for. But the problem is that you'd be mounting pretty much everything lol. At that point, you're basically undoing one of the core ideas behind using containers in the first place. So why bother with containers at all? To me, the additional overhead and complexity would be hard to justify.
Nevertheless, I'll keep this in mind. I totally get that people want to play around when they're getting started, and playing around obviously includes installing apps and experimenting with things. Even the name of the Compose file suggests that it's meant for exactly that — it's literally called "Play with Docker".
I see the issue and understand the use case. I just don't see a clean solution at the moment. Maybe I'll have a bright idea in the next few weeks :) If I don't follow up, don't hesitate to tag me again! I might have simply forgotten about it.
My current approach would be something closer to the dev setup, without the strict separation of services. Essentially, one container running Frappe and only the peripheral services (like the database) in separate containers. If we're already bending one Docker principle, we might as well bend a few more lol.
My main concern is that this could lead to a lot of questionable Docker setups, with people copying this approach without realizing it's not how you'd typically want to run things in production.
But at some point, we might just have to give people what they've been asking for. After all, this seems to have been a recurring issue for quite some time now.
revant commentedon Oct 17, 2026
Check this https://discuss.frappe.io/t/issue-installing-apps-in-docker-container/118491/4
revant commentedon Oct 17, 2026
Frappe developers assume there is no separation between production or development setup.
File based duckdb is added over network based clickhouse because the assumption is everyone is using a vm and has db file on VM.
asieftejani commentedon Oct 19, 2026
Hi @DanielRadlAMR - thanks for the reply and the explanation. Please can I know which docker principles are being violated. I tried to check with AI and the best it would give me is as per the docker documentation (https://docs.docker.com/engine/storage/volumes/?utm_source=chatgpt.com#mounting-a-volume-over-existing-data): -
If you mount an empty volume into a directory in the container in which files or directories exist, these files or directories are propagated (copied) into the volume by default. Similarly, if you start a container and specify a volume which does not already exist, an empty volume is created for you. This is a good way to pre-populate data that another container needs.
Hi @revant - thanks for the links. However i am looking for how to convert pwd.yml into a container where we can use bench commands to add/update apps and run builds
Right now the sites have volumes. My main question why cant we do at 1 level higher - at the app level.
Then people can install apps easily and change core code if they want to experiment and run bench build/update/get-app/install-app
Is there any reason why its only at the site level and not at the app level?
What if we never rebuild the image for pwd.yml - can part of the image be mounted on a volume?
What are the downsides/risks? According to AI if we do it properly there is no issue
DanielRadlAMR commentedon Oct 19, 2026
Hi @asieftejani,
Sure! :) To clarify, these are more architectural principles and best practices than hard technical restrictions imposed by Docker.
1. Images should be self-contained and immutable
A Docker image should contain everything the application needs to run, including its code, dependencies, and runtime components. Volumes, on the other hand, should primarily be used for persistent data that needs to survive container replacement.
Frappe apps are application code and runtime components, not actual user data.
By mounting the entire Bench directory and installing or updating apps inside the running container, you're effectively moving parts of the application out of the image and into a mutable volume.
This defeats one of the main benefits of containerization: reproducibility. The image no longer fully defines the application you're running. Deployments, updates, and rollbacks become harder to manage and less predictable.
There's also a practical issue with the proposed bind mount: mounting
./frappe-benchover the existing Bench directory hides the files provided by the image at that location.2. One service / responsibility per container
This is another principle we'd potentially compromise with the VM-like approach I mentioned earlier.
The current architecture separates the different Frappe services (web, workers, scheduler, etc.) into individual containers. Each service has its own lifecycle but uses the same application code from the image.
If we want to offer the traditional Bench experience, where you can freely install apps, run builds, perform updates, and manage everything as you would on a VM, an alternative could be a single container handling all the Frappe processes, with only external dependencies like the database and Redis running separately.
That would be more convenient for experimentation, but it would also move us further away from the intended container architecture.
So, can it be done? Absolutely. Docker doesn't prevent any of this.
The question is whether we should encourage this approach, especially when people might later carry the same setup into production.
For a clearly designated playground or experimentation environment, I can see the value. For production, however, I would strongly prefer keeping application code in images and volumes for persistent data.
That's essentially the trade-off I'm struggling with here. :)
asieftejani commentedon Oct 20, 2026
Okay many thanks again - If you think it wise I suggest we implement it - as it is there are lots of warnings around pwd.yml that it is not production grade and only for experimentation - whats the worst that can happen?
asieftejani commentedon Oct 20, 2026
https://discuss.frappe.io/t/internal-server-error-after-install-qrcode-module/165295
DanielRadlAMR commentedon Oct 22, 2026
This might be interesting in this context: frappe/frappe#44826