ERPNext - cost-effective ERP solution
-
@nebulon @girish ERPNext is looking good...I'd love to see it added officially as a Cloudron app! (I've decided to move our business to ERPNext.) Maybe they'd support adding an "Install with Cloudron" option on their GitHub page? That could bring more business customers to Cloudron I expect.
Quick notes:
- Their official docker image seems mature enough. https://github.com/frappe/frappe_docker
- They also have a 1-click droplet app on Digital Ocean. (But I'd rather manage it through Cloudron...because Cloudron is beautiful and awesome.)
- There is an ERPNext integration for n8n.
-
@chrishthompson Yes, totally agree. I tried several ERPs and this one really made me almost teary. Such a rich-featured ERP and they decided to make it open source.
It's a high quality made ERP. It has integration with WordPress and n8n.
Really wish it would be in Cloudron soon.
At the moment, I'm paying for a separate server just to deploy ERPnext. But it would lovely to have it in my Cloudron along with other apps I have here.
Cloudron team, please consider bringing it here -
@girish Any chance you will be able to have a look at their official package? I deployed their docker image for production in DO: https://github.com/frappe/frappe_docker
— and it works like a charm.
Why I think ERPnext is a very beautiful project: Open-source at heart, with good developers behind it, highly supportive and very community-driven project. The project has been going on for almost a decade now. -
Are there plans to bring ERPNext to cloudron soon so I can use those resources or do I have to set up and pay for another virtual machine? Because my Time is kind of running out on this one and I would rather not migrate again.
-
@andreasdueren said in ERPNext - cost-effective ERP solution:
Are there plans to bring ERPNext to cloudron soon so I can use those resources or do I have to set up and pay for another virtual machine? Because my Time is kind of running out on this one and I would rather not migrate again.
We're actually in the same boat, since it's a new year looking to move platforms and this would be a massive win on our side.
-
@andreasdueren I've packaged one or two things for myself on Cloudron, and I took a look at Frappe/ERPnext.
First, for the thread: Cloudron does not run Docker images "as-is." Or, if you prefer, simply because a project runs in Docker does not mean that it will immediately be runnable under Cloudron. A Cloudron app needs to be packaged up so that it will "play nicely" with the control architecture that Cloudron provides. Put simply, to get that friendly Cloudron experience, some work is needed when packaging an app.
In the case of ERPnext, it has a compose file that specifies many software services. Traefik is used for routing and load balancing (I assume); Nginx fronts the service; it seems like Frappe (the API backend) is written in Python (another service). There's worker processes of several flavors, a scheduling service, a Redis cache, MariaDB (which, for porting to Cloudron, we'd want to integrate with it's built-in DB add-on), the site creator service... and a large number of storage volumes.
Cloudron does not, to the best of my understanding, support running
docker-compose
files. As a result, to package this, we'd have to pull all of these services into a single container image. That would take some thinking, especially since Docker "likes" to have one process per container. Or, if there is another way/it is possible, I don't personally know how to package up a multi-container Cloudron application.The Cloudron team may have something else to say, but I thought I'd drop a note in the thread that helps explain why this app is a more complex proposition than others (perhaps) when it comes to packaging. Yes, it is open, and yes, it installs easily on a VM when you do a
docker-compose up
. Unfortunately, that is not the same as packaging things up to run under the Cloudron framework. -
@jadudm Fair and not a problem. I'm just a little bit disappointed by the lack of communication. If it won't get packaged for a while then a short note would have been sufficient instead of letting people like me guessing whats planned next.
-
@andreasdueren We are not working on packaging this. We try to leave a note when we start packaging an app. Currently, we are working on 7.1 - https://forum.cloudron.io/topic/5982/what-s-coming-in-cloudron-7-1 and there's also many existing apps that need to be updated.
-
@andreasdueren Hey, sorry for the late reply. I have followed this protocol closely and it works like a charm:
It's fairly straightforward if you apply the same method as the video above, it uses the GitHub method that was posted here.
ERPnext is a solid system, worth the hassle. Good luck
Kind regards. -
From what I've seen looking at the frappe/erpnext system design, it looks like a lot of the service complexity comes from their "bench" system tool that provides multitenancy / "environment duplication" capabilities via their backup and restore system. From my experience being able to branch environments is vital for these kinds of tools, but... that's basically cloudron's core competency. With a bit of work cloudron could probably match any missing features that "bench" has over it.
With bench factored out and its features provided by cloudron directly, I think you'd be left with a single python service that needs redis, mariadb/mysql, and postgresql, which cloudron provides as services already.
Notes:
- "frappe" is the company and also the name of the development/deployment framework for erpnext and other applications developed by the same team
- The frappe/frappe-worker docker image referred to in the frappe_docker/compose.yaml file is built from the source in frappe dir in the frappe/frappe repo
- The
bench worker --queue short
command (and similar) runs scheduler.py:start_worker() - The queue workers are a Python RQ-based job scheduling/background task system. RQ uses redis queues
-
Two major issues that I ran into while testing on cloudron.
-
frappe framework requires the database name and database username to be the same (its hardcoded and all over the place). When testing locally it worked but in cloudron, db name is appended with “db” and username with “user”
-
frappe framework needs root access to the database, eg. password of the user named “postgres” (its hardcoded, even if —dbroot-username exists, it’s for mariadb only)
That’s why I’m running postgres server on the Docker container itself, and not use any db addons. I’ll map the db storage to /app/data so it gets backed up regularly.
See you guys with good news next time. Most apps made in Python seem to write all over the filesystem so I’m testing it on readonly environment; once done ErpNext should be available soon. Thank you for your patience.
-
-
@nj said in ERPNext - cost-effective ERP solution:
frappe framework requires the database name and database username to be the same (its hardcoded and all over the place). When testing locally it worked but in cloudron, db name is appended with “db” and username with “user”
That's a pretty rough requirement but we can fix the platform code I guess to have an option to generate such names.
frappe framework needs root access to the database, eg. password of the user named “postgres” (its hardcoded, even if —dbroot-username exists, it’s for mariadb only)
Keeps getting rougher There's no chance we will allow an app to have root db access.
Is the situation any better with mariadb instead of postgresql?
-
-
@girish for the initial release, I've given up on the idea of using Cloudron addons for now. Postgres is also getting over-complicated so I think I'd stick with MariaDB. Let's see how it goes. The build-run-test cycle is quite tedious when there are all kinds of new errors to resolve. ErpNext turned out to be a lot harder than I expected.
Current status: frappe installed, up and running. ErpNext won't install, and require all its dependencies (apps) to be installed. My target is to publish it by this week.
-
@infogulch said in ERPNext - cost-effective ERP solution:
frappe framework needs root access to the database
Surely this is not actually necessary to run the app, but is just part of their custom dynamic deployment system (ick). I hope it's possible to extricate the actual app from the framework...
I thought so too. Unfortunately, it keeps asking for "postgres super user password".