Let’s say I’m on the $25 plan with private bench, I can install erpnext and other custom apps, all this count as one site right?
If I want a staging area, I would need another site? Or is there a way for me to deploy custom apps on the same bench with different version?
Or how do you guys handle development cycle on a tight budget?
Just like how you can maintain multiple sites on a single bench, you should be able to utilise the private bench given to you to create multiple sites with different domain names.
Unless the cloud UI doesn’t allow you to do so?
(Not well versed in Frappe Cloud)
Definitely could do that in the self-hosted version, not sure how the cloud handles it.
I have to either develop custom app locally or setup something on another VPS, I guess.
Would like to know how everyone deals with staging area especially when using Frappe Cloud. Like what if update break stuff if we didn’t test things out?
You can definitely have multiple sites on the same bench. You can’t have multiple versions of the same app on a single bench, though. That’s pretty much what a bench is: a single environment with a single version of apps.
I’m not using Frappe Cloud at the moment, but I believe you can have multiple benches at your disposal. You could create one for your main deployment, then create another one for your staging area.
In principal, I suppose you could create a third bench for devleopment, but honestly that sounds dreadful. The Frappe tech stack is pretty involved with multiple kinds of caching and runtime optimization. I can’t really imagine doing development on a remote production server.
That’s what I’m confused about, is it that we pay for 1 site and can have multiple benches (which equates into multiple sites lol).
1 Site > Private Benches > Sites (or maybe we call it app?)
You can create multiple sites on a single bench as earlier mentioned by @peterg. On Frappe Cloud, you are charged for per site and not bench. So if you have 3 sites, you will be charged for 3 sites irrespective of them being on same bench or different benches.
The App is the program. The Site is your specific instance’s data.
So, you and I could both install ERPNext v15.20.6, and we’ll be running the exact same app. But, your data and my data will be different because we’re on different sites. When you backup your ERPNext installation, you’re backing up your site’s database. You don’t need to back up the apps because they don’t contain any of your data.
Additionally, Frappe allows you to run multiple sites on a single “bench”. People often do this if they want to run two different companies from the same system. Even though they’re running on the same server, they’ll use separate databases, separate user-logins, separate URLs, etc.
Even though a single bench can run multiple sites, sometimes one bench isn’t enough. The main reason for that might be if you want to run different versions of an app. You might want to have one site using ERPNext v14 and another site using v15. For that, you would need to create two different benches.
Since your staging environment is used to test new software versions, it needs to have a separate bench. Your production bench might run version 1.0 of your app, and you’d use your staging bench to test out version 1.1. Then, if everything looks good, you upgrade your production environment to 1.1.
At that point, you can delete your staging site if you want. You could also delete your staging bench if you don’t need it any more. Next time you need to test a new version upgrade, you could create your staging bench and site again from most recent data.
I tried running 2 sites on the same bench with port 80 and 8001. One with ERPNext installed and one without. By visiting mysite:80 and mysite:8001, they all point towards the same entry point at mysite:port/app/home.
I also tried installing different version of ERPNext on both sites, which is possible. Both of them lives on the same MariaDB with their own schema.
So it is possible to run multiple sites on the same bench on the same server.
But is is not possible to install the same app with different version on the same site.
Frappe Cloud Shared Hosting is charged per site, so another staging site will cost extra fees.
However, I think that Frappe Cloud servers will allow multiple sites on the same bench or different bench. And I think it’s pointless to have multiple benches on one server because you’re just going to split the resources instead of sharing it with multiple sites.
In conclusion, the way to test out new patch is by scheduling maintenance, stop all transaction, update to new version, test everything out, if something fails, patch custom apps or rollback until a solution is found.
No, definitely not. I’m not even sure what that would look like. How would the same site use two different versions of an app simultaneously?
I’m not sure what the difference between “splitting” and “sharing” resources is here.
Frappe benches don’t have much overhead. Having two sites or one bench or one site on each of two benches would be very similar in terms of resource demands, I’d think.
That’s a perfectly fine way to do it, if that’s your preference. That said, the major advantage to my mind of Frappe Cloud is how quickly a new site can be spun up or spun down. If you’d rather have downtime than 2-3 days of server cost, sure…there’s no need to have a separate staging instance if you don’t need it.
If I’m not mistaken bench is just an CLI but running bench start will spawn a bunch of processes that will use to serve the app as configured. So two benches means two instances of these processes (you can’t run it with the same config as processes like Redis will occupy certain ports, so you need another config with different ports/nginx configuration).
It’s like having multiple apps running on the same docker container (sharing resource on the same bench) vs having multiple containers running their own apps (splitting resources between multiple container on a server).
There’s benefits and use cases for both though.
bench start is not used in production environments. In production, supervisor manages processes dynamically, and everything involved tends to be very load-scaled.