Proper way of installing in production?

Frappe Framework
, ,
21

The process should be the same as pointing any domain to any hosted service on your network.
You would point the domain to port 80 (or 443 if using SSL) of your host machine that is running frappe manager.

The key here is that you must access the Frape Manager site using the exact host name that you used when creating the site. You cannot access the site using the host machine’s IP address unless you do additiona configuration inside of the Frape Manager nginx configs.

For example, if I used the following command:

fm create text.test.com

I would have to use the following URL to access the site:

HTTPS://test.test.com

Trying to access the site using an IP address won’t work out of the box.

22

Your inputs are super helpful, Brian. Thanks.

Do you see any particular downsides to using Docker over manual installation?

23

I’ve also followed the LXD path.

For the LXD vs Docker debate, just try to use them in on a laptop from 2011 like I did. Then you will understand why LXD is superior :slight_smile:

1 Like
24

So before I answer that, let me say: “I like Docker.” I’ve used it for a long time, and I’ve done a lot with it. The main upsides for Docker have been:

  1. I can install software on my laptop temporarily, and remove it later, without leaving a bunch of leftover files and artifacts on my disk.
  2. I can use multiple versions, of the same software, at the same time (e.g. Redis 4 and 5, MariaDB 10 and 11). Without worrying about conflicts or shared configurations.
  3. I can use Docker to help me perform things like network isolation or sandboxing/jailing.

The downsides are that Docker adds complexity. When everything runs perfectly, no problem. But when Things Go Wrong, what is the root cause: Frappe/ERPNext, or Docker? :thinking:

Troubleshooting ERPNext is already challenging sometimes. Docker doesn’t really make troubleshooting any easier for me. It adds extra things to think about, like port mapping, volumes/bind mounts, ensuring your container is using the right image, cleaning up your images, etc.

There’s nothing wrong with using Docker + ERPNext. But for me personally, it doesn’t add any advantages or benefits.

For a brand-new person to Frappe/ERPNext, it might make the installation process a lot easier. Then again, it might not (I’ve seen plenty of posts on these forums where people have Docker issues).

TL;DR : If you’re trying out the software for the first time? I’d probably recommend Docker. That will (usually) get you moving much faster, so you can start to see/learn the software. But if you’re experienced, then either way is fine.

25
  1. I can run ERPNext on Windows without needing a slow & resource hungry VM
1 Like
26

That’s a very good point about Windows. VMs can definitely be slow.
I’m not sure if there’s a performance difference between Docker on Windows, versus Windows Subsystem for Linux? :thinking:

27

What i understand is you cant use Windows Docker without WSL2… i did try to install ERPNext on WSL once (Installing ERPNext on WSL Windows | by Alaa Alsalehi | Medium) but it did not work and ChatGPT adviced me against it so i abandoned it

28

One of my co-workers successfully installed on WSL.

  • Version 15
  • Postgres was installed on Windows OS itself.
  • All the other components (Redis, Frappe, Node, wkhtmltopdf2, are installed on WSL)
29

For those still asking, here are some reasons why containers are often preferred:

In a production environment, a few things are essential for any company: consistency, predictability, isolation, scalability, and orchestration.

Containers allow you to encapsulate the exact environment an app needs; OS layer, dependencies, libraries, and more. On bare metal, environmental drift (different libraries, configs, etc.) can silently break your system, and in production, you often cannot afford failures.

Scalability and orchestration: Containers are ephemeral and declarative. You can describe your desired state (e.g., 10 replicas) and let the orchestrator handle auto-scaling, load balancing, rolling updates, self-healing, and more.

Isolation and security: Containers provide near VM level process isolation. This is a strong security feature, especially when your services are exposed to the internet. If one container is compromised, it does not affect others, reducing the overall attack surface.

Portability across infrastructure: Containers are portable. If you need to switch cloud providers or VPS hosts, containers make it extremely easy. From AWS to Azure, the same container runs the same way everywhere; no manual reconfiguration needed. Just copy the volume, use the same Compose file, and you’re good.

I use containers in my homelab, for my company, and for my clients. They save a lot of headaches and make managing infrastructure much more reliable.

If you care about security, consistency, scalability, and reliability, go with containers. Otherwise, a bare-metal installation is fine. I personally don’t recommend bare metal for anything unless the app can hardly function in a containerized environment. Even then, I prefer using Incus for more flexibility.

4 Likes
30

Running frappe/erpnext in docker works quite well on WSL2 :+1:
In fact, that’s how frappe_manager can run in Windows.

31

I am hoping you are docker expert. If so: -

  1. According to ChatGPT you cannot use bench build and bench get-app/install-app in docker setup and even the frappe docker github shows you the way to add apps to your yaml file
  2. If the above is true then can one sollution be to mount the apps folder as a volume just like the sites folder. Many people are confused why they cannot add apps using the bench way.
    Please advice
    Thanks
32

The bench command is designed for mutable environments. It excepts to install new apps into directories, update python packages, regenerate configuration files etc…. These operations require write access and persistence.

The problem is that containers are an immutable layer created for an image. You typically can’t modify the image’s file system beyond temporary runtime writes. Also, containers are slimmed down for runtime so they may not include the necessary build tools to process some bench commands.

All these limitations make it hard to run some bench commands inside a container. For that reason, you need to rebuild you image anytime you want to update.

The process is actually very simple.

There might be other security consideration but in my opinion, this is the main reason.

1 Like
33

Hello @Thevoice and @brian_pond and @revant_one

Sorry to keep dragging this but hopefully you will appreciate my need to find a long term sollution for this: -

As mentioned above some bench functions (specifically bench get-app) do not work properly since

The bench command is designed for mutable environments

A lot of beginners (including myself and i had to learn the hard way) make this mistake regularly

However bench install-app and bench new-site work (as it is used in the script at https://raw.githubusercontent.com/frappe/bench/develop/easy-install.py

after the baking/compose stage since the sites volume is persistent

My recommendation: -

Would it be possible for the frappe team to bake the image upto the yarn/node level and add a persistent volume for apps directory so that at least bench get-app would work (not sure about bench build though). I know that bench updating python will not work but at least the beginners will not have undergo the tough learning curve i went through (and i can see many on telegram, the forum and github are still hitting the same hurdle)

For those who want the standard vanilla “play with docker” they can download the pre-baked docker images which is fine. For those who want multiple sites/apps they can use easy-install.py upto node/git/python level then the script can use bench get-app at this level rather than baking it into the image and making it immutable just like bench new-site and bench install-app

What do you guys think? Can it work? Is it worth the effort? If i get the go-ahead from the frappe team am willing to put my time and energy into this (will need your guidance as am new to this). However I suspect this is a core change as it will effect all their apps in which easy-install.py is the recommended method and also it could impact how the CI/CD workflows for the developers

Please do let me know

1 Like
34

Use VMs, Do not use containers if you do not want immutability.

Use this if you need VM-like setup: Issue Installing Apps in Docker Container - #3 by fiveoaks , it uses frappe/bench image. It is what VM will also do with dependencies. Initiating a bench and keeping it in volume is good for you to make it work like VM.

For me proper way of Production setup is CI / CD > Gitops > Kubernetes. Check this diagram Frappe Apps Kubernetes Setup · castlecraft/custom_containers Wiki · GitHub

edit: Immutable images are base for horizontal / dynamic scaling.

2 Likes
35

For those of us that are NOT in the business of reselling Erpnext, do you all recommend Docker? Especially if a shared cloud VPS is adequate for our needs? Not an IT guy by background - always wondered why LXD is not recommended out of the box - even for installing a VM… Am I missing something? Doing it wrong? Linux commands are answered easily with Google search queries, all the bench commands work, and you get most (?) of the benefits of containerization? Frappe Apps / Erpnext makes absolute business sense for small companies like ours - we should know our core audience and make adopting the platform easy. With growth will come need for scale….

36

I’m all about self hosting. I only use containers for setup. Because of that I maintain frappe/frappe_docker and frappe/helm. I only recommended containers.

If setup is challenging for you then just go with SaaS offering and frappecloud team will decide what is best for you.

3 Likes
37

So if I am reading your answer carefully - you recommend containerization for production but not necessarily Docker? Learning Docker commands just for a single instance setup - seems unnecessary with a steep learning curve? It probably makes sense for multi-customer / multiple bench setup, managed by IT Pros, with many users / companies / clients? I am still not clear as to why as a community we only recommend Docker for production.

38

What docker commands exactly? down pull up?

While it still uses docker, but if you want some “simpler” setup where these commands are in the form of buttons, you can try Dokploy setup.

39

When you carefully study the way the docker setup works, you’ll learn a lot about how the system works, about network interactivity of the components, about where your data resides and how to access it and backups, about what and how you can change stuff, do updates, etc.

It’s well worth the effort, if you need deep knowledge about the system – and who doesn’t if you self-host or want to do some ops work for others.

1 Like
40

Hi guys, I do have the same concern about the deployment docker container in production. I noticed that the GitHub - frappe/frappe_docker: Docker images for production and development setups of the Frappe framework and ERPNext recommends using the compose.yml over the pwd.yml in production. Would anyone help me understand what the different between the two versions are? Could pwd.yml be used for production if I set it up properly? Thank you