Ich bin heute auf Coolify von Coollabs gestoßen, womit ich mir ein anderen Opensource-Script kinderleicht installieren konnte.
Leider entdeckte ich darin noch nicht das ERPNext, weshalb ich gleich mal hier nachfragen wollte, ob Ihr vielleicht mit den Entwicklern euch kurzschließen könntet, damit diese das ERPNext mit integriert wird? (Es ist vielleicht besser, wenn dies zwischen den Entwicklern geschieht, als nur von einem interessierten Nutzer.)
It should be possible to install it on any vps, specially if it’s running coolify. I’m trying to do that, but I’m going thru so many issues that I can’t believe I’m working with docker compose, git or all these tools. It should be easier with coolify and all that, although it is still not the case → I’m going to keep pushing that key until it works!
I installed ErpNext about 3 weeks ago directly on a Hetzner Cloud without any other intermediate platform like coolify and it’s been working so far, but I don’t have time at the moment to delve deeper into ErpNext.
Thanks for replying, I too got erpnext working with manual installation on vps long back, but I was trying to implement docker method. It’s painful to setup atleast for me while frappe cloud does tha all in a jiff. Still I’ll get back if i can get it working.
yeah it’s a pain frappe/erpnext is so hard to get working on a managed hosting platform like plesk, even the docker approach is tricky (and pretty poorly documented, from the perspective of a non-pro) if you need non-standard modules.
Also ran into coolify recently, seems like a very nice platform.
I’d prefer Dokploy over coolify because it uses docker swarm instead of simple docker compose. For coolify, docker swarm support is experimental at the time of this reply.
yeah and thank you for that, I’m just sad this requires so much manual labor still.
That aside, I’m still fairly new to frappe/erpnext, and I only recently ran into frappe press/cloud. Given that this is the native control client for installing and managing frappe installations, is there a reason why people still prefer to mainly provide manuals for installing erpnext rather than this software (other than frappe press recommending a multi-server setup)?
Coolify, Dokploy, Portainer are other open source projects that can run containers. Not just frappe, they run mariadb, wordpress, gitlab, etc. Community finds these projects and recommended them here on forums.
Frappecloud is a source of income for frappe developers, it is recommended so they keep building more foss products and maintain this community. Frappe/press is used in production by frappecloud.com. It is difficult to install frappe/press and it is not required for self hosted erpnext installation.
easy-install script from frappe/bench uses containers. It generates similar (like dokploy templates) compose yaml using cli.
Yeah and if all you need is erpnext (and/or hrms, which isn’t quite stable atm), you’re good. But if you need more modules, especially ones that themselves update frequently (eg for banking or what have you), you incur quite a bit of overhead, while also running the risk of breaking your installation and being unable to revert to a prior build easily. For those reasons, it makes sense to me to use either the native hosting platform, or NixOS recipes to manage the software.
The situation reminds me of how Linux/Unix distributions manage packages.
bench with frappe is in itself a similar system, which draws it’s packages from a public repository.
On top of such a mechanism, said distributions include “glue” which adapts the many disparate software projects to the distributions’ package managers. This glue consists of download instructions, patches needed for various reasons, metadata etc., and also various tests.
In particular, they also have “channels” or “variants” or however you would (and they do) call it, like “stable”, “rolling”, “bleeding edge”, etc.
All this could also exist for frappe apps, if a dedicated team starts to build the glue and metadata needed to ease the integration of the apps into/onto the common frappe platform, e.g. which makes the parts compatible to each other (from a normal user’s point of vue) and reacts to “doesn’t work” user message to rebuild packages with the needed patches or precludes premature/unfit app releases from distribution until corrected/patched.
If the frappe devs see themselves as a agile mvp vanguard builders, then maybe some other people are needed to make some of the useful and/or needed stuff more palatable for external everday implementors and everday users by ensuring a simple, robust, reliable and seamless combination of all the packages needed for normal use in the countries of the users.