Why you should replace NGINX
A common option for a web server and reverse proxy is NGINX. This would have been a good decision ten years ago, but with modern alternatives built in modern programming languages that have many more features that save you time, why use an inferior product? Simply put, modern web servers like Caddy and Traefik are better.
I regularly come across this while browsing the smaller internet; what do they all have in common? NGINX. Most notably, Manjaro appears to struggle with this. Guess which web server they use: NGINX. This would never have happened if they had chosen Caddy (or any other modern web server). Every modern web server supports automatic HTTPS.
NGINX utilizes HTTP/1.1 by default. Due to missing optimizations present in later versions, this leads to poor website performance. Although HTTP/2 is supported by NGINX, you must enable it (and many users don't). NGINX does not currently support HTTP/3, and even when it does, it is unlikely that it will be enabled by default, and most users will not have access to it. This leads into the next section about NGINX's configuration and their update distribution.
NGINX configuration is overly complicated. Many lines of NGINX configuration can be replaced by a few lines of Caddyfile. And because the Caddyfile is a single file, no files need to be moved, and Caddy can reload configuration without restarting.
Linux distributions should not be trusted with updates. Debian and Ubuntu are the most popular server distributions, but they are also the worst at updating (this is a "feature"). This is why packaging formats such as Flatpak exist (in the server world, Docker). Many websites are using NGINX versions that are years old and may contain critical security vulnerabilities (some of this is on the user for not updating even when updates are available). Caddy maintains their own repositories for some Linux distributions, while others, such as Traefik, are designed to run within a container. Developers of these web servers can ship updates quickly and be confident that users will have access to the most recent version.
Every alternative I've mentioned thus far has been written in Go. Go is a modern programming language with memory safety and an excellent HTTP library in its standard library. This makes it the ideal language for creating a web server. Using Go has advantages such as removing dependence on libc and producing a binary that runs on any distro.
NGINX's antiquated design slows you down and holds back innovation on the web. It's time to move on and replace it with something fresh. Sure, more configuration and software can solve all of these issues. But, at that point, why not just switch? The alternatives are endless, but the best is undoubtedly Caddy. It does not have any of the issues I mentioned above and is very easy to use. Traefik (a little difficult to get started with), Sozu, and Envoy (I haven't tried these yet, but they look interesting) are some other options. You could also move to a PaaS provider like Fly.io and stop managing servers altogether, that's what we did here.
I still think that nginx offer the most stable solution.
I don't remember if it was caddy but a famous CDN provider try to implement it because it implement a api first config, and not just file base.
But it went terrible.
At the end openresty could be a drop in replacement for nginx that keep the same stability and performance.
And nginx file config is really flexible it support even JS/Lua script.
@MooCloud_Matt Sorry that's not a useful comment without more relevant information.
When was this? V1/V2? What went terrible? What was the issue? What CDN?
https://caddy.community has plenty of examples of it working with, in front of and behind CDNs.
I've used it since V1 when needing to expose dirs of files with TLS.
With Cloudron 8.0 coming, it might be useful to rethink the stack a bit.
@robi Apache and nginx are still very well maintained and supported - and don't get me wrong, Caddy is really good, probably even better. and really im not even arguing against your point, really, more just putting in my 2 cents.
Apache and nginx are running a majority of the internet right now. And caddy is NOT a drop in replacement. Millions of software will need to be updated to make that change to Caddy. TBH I don't believe caddy should replace nginx in cloudron but maybe there can be an app for (or an option to switch to ) caddy. It certainly would not be difficult to make.
so let me give more context.
Yes, it was Caddy that was used in a beta product by a European CDN provider (I don't know if I can provide the name of it, but I'm sure I can give some results).
Caddy was highly inconsistent due to the garbage collector in Golang, which is amazingly good but don't scale well if you go outside his tagged usage (microservices and server-related task).
This causes spike in resource usage from the garbage collector.
So the positive side of being able to update a config with rest API doesn't compensate for the instability that Caddy has under load.
You can't compare go to C or C++; they are just faster, memory management is up to you as a developer, and Nginx is amazingly good at it.
Go is born as a Java alternative, not C for that we have rust that don't have a mature webserver or proxy for what I know to compete with Nginx (openresty), Apache (that means LS too).
Cloudflare migrates from Nginx to OpenRegisty and now to a proprietary Proxy, but just for some small stuff, main proxy is still OR.
Should cloudron migrate to Caddy, maybe?
- list itemZeroSSL is really good and we extensively use it.
- api config by default is amazing
But then you still need Nginx for much other stuff like:
- Webserver PHP-FPM is still better supported in Nginx with better caching.
- Better support for Nginx from the PHP community. that means more requests in the forum( or our customer care) on how to use plugins for WordPress with Caddy.
With Cloudron 8.0 coming, it might be useful to rethink the stack a bit.
I'm on the same page for that, but I would not change something that is working well and have stable support.
Even the performance advantages caddy and HTTP2/Quick could have are nothing compared to other parts of the stack that are not optimized for performance. So the bottleneck is not there.
@MooCloud_Matt While OpenResty - IS - Nginx at its core, it does a whole lot more. Even Nginx is more than what we use it for, like proxying IMAP/POP3, etc.
Regardless of what solution is looked at (doesn't have to be caddy), something needs to change so Cloudron is more usable within it's own services as well as others. Looking at it systematically should make the choices clear.
Discussion here or elsewhere in the open will make it more transparent and richer in diverse ideas.
for now, the limitation is related to what you can customize inside your cloudronmanifest.
Great, can you expand on that? What is the limitation? What would you like to see? How would we go about making that happen?
Such a big question, I already provided some of our ideas to the cloudron team, and we will see the future limits as soon as Cloudron moves to a more open AppStore.
With the support for 3°party apps, developers will now containerize and maintain their apps by themselves, requiring less maintenance from the cloudron core team.
At that point with an open ecosystem we can expect deep optimization.
Most tech stack decisions (by us, atleast) are not made based solely on technical details. The developer mindshare plays a big role. nginx/apache are known by practically anyone and problems are just easier to solve. Given this, one has to hit some unsurmountable technical problems before considering a switch. We are yet to hit any problems with nginx (for almost a decade now...).
Same applies for things like docker, nodejs, angular etc. I am sure there's things out there which are better these days but everyone knows these tools and any problems one hits are solvable. Unless these things go unmaintained or have severe technical issues, it's hard to justify replacing them.
Of course, such articles are still useful, because if one starts a project from scratch maybe we make different choices.
Speaking as a middle-of-the-road hobbyist, I've managed to figure out most Apache or NGINX problems, related to certs or virtual hosts, but caddy.... the one time I tried it out, because it was touted as a simple, easy to use, web host solution, man, I could not get more than one domain working. The tuts at the time (2 years ago thereabouts), and which ever forum I asked on, we just couldn't get that thing to work. I haven't bothered since, since the two alternatives really do just work.