Can anybody give a compelling reason why one would use Caddy 2 over the far more established NGINX, in a production environment?
When Caddy 1 landed, I was amazed at the clean simplicity of the server - a lovely breath of fresh air. It seems Caddy 2 is trying now to be all things to all people, it’s grown complicated and confusing and I can’t see it’s niche any more. Seems like an NGINX clone now. I’d love to be wrong, but it feels like kitchen sink syndrome has struck.
for a few things, its faster to configure, the configs are mostly simpler. It is way lighter than nginx, auto ssl, has features that would normally require you to install other packages on nginx to even run
Sorry, we can’t give you one. We can only give you many reasons:
Memory safety. Go has memory safety guarantees that C/C++ doesn’t have, thus nginx doesn’t have. Your server is more secure this way. For example, Caddy would never be vulnerable to Heartbleed, etc.
Automatic HTTPS. Still the first and only web server to use HTTPS by default. And our certificate management logic is the best in the world. Hands down. We’ve spent 5+ refining it since before the birth of ACME and it continues to improve to this day. This is super important and can’t be stressed enough when considering other automation solutions, because Caddy’s logic is so good it can keep your sites online when other servers will let you down. We’ve seen it several times already in the past.
An API for configuration, if text files don’t float your boat.
There’s a lot more specific things too, depending on your requirements. What are you deploying?
You can use Caddy 2 basically the same way you used Caddy 1: make a Caddyfile and run caddy run (the run subcommand is new). You don’t even need a Caddyfile. Granted, this hides a lot of complexity for you and you should learn how it works from our docs. But we had about 400+ feature requests and bug reports that we couldn’t satisfy or fix with Caddy 1, so Caddy 2 was written. It is extremely powerful and flexible, but if you still want it to be easy, first take the time to learn how it works, then just use it in its simplest fashion like you did with Caddy 1. No biggie.
Believe me, we’re very aware of feature creep and have made sure to avoid it in its very design. Once you learn Caddy’s architecture you’ll see why there’s no feature creep. At its core, all Caddy does is Start() and Stop() app modules. The HTTP server is one such app module. This is what Caddy 1 was supposed to do too, but it didn’t ever do it very well. Caddy 2 is actually very well-engineered. You just plug in the features you want/need. And once you understand that and it really starts to sink in, you will see why comparing nginx and Caddy is like comparing a Honda Civic to a Tesla Model S.
As an enthusiast, my time is valuable and I want to spend it on areas of technology that interest me. NginX and Apache don’t feature on the radar. I don’t use Caddy 2 JSON. Everything I need Caddy to do I can achieve using just the Caddyfile. In just a few lines of code I have a reverse proxy or a file server or a web server all with TLS encryption. I almost feel clever! When I compare this with the convoluted, lengthy and hard-to-digest code I see for more traditional approaches, I always feel like I’ve made the right decision with Caddy. I often see threads on other forums where experienced users of traditional web server approaches say ‘I can’t seem to get system X working with the proxy/web server capabilities of Y or Z’. I think to myself ‘Really? I’ve got it working with Caddy. Don’t know what all the fuss and bother is about?’.
Plus the Caddy team on this forum are always ready to lend a hand, even with troglodytes like me. It’s one of the friendliest forums I participate in that still treat mere mortals like myself with respect.
For my needs, Caddy marginalises what traditional big players have done and puts otherwise complex subject matter within reach of the masses.