|
|
|
|
|
by cplli
1395 days ago
|
|
I also only have Caddy running locally to proxy different dev environments and serve certain files, and it is an exceptional tool, but I would never deploy it in production: 1) Nginx configs are (from my experience) easier to template (in our Nomad & Consul cluster architecture)
2) From what I could gather, Nginx is more stable and performant
3) I don’t trust Caddy’s codebase security. It simply has too many dependencies, and Go makes it very easy to get into dependency hell Honestly if 3) wouldn’t be an issue, and stability from 2) would be proven, I would probably give Caddy a try in production. |
|
Pro tip: Did you know you can use any config format you want to configure Caddy [1]? So if templating the Caddyfile is hard for you, use something else! You can use YAML, TOML, or even NGINX configs.
On 2, that's been pretty well debunked at this point. Caddy is written in Go, and is only a very thin wrapper over the Go standard library, which heartily powers much of Cloudflare's, Netflix's, and Google's infrastructure. Plus you gain memory safety and are exempt from a whole class of vulnerabilities with Caddy. We've seen numerous instances where Caddy has kept sites up while nginx let other sites go down, due to Caddy's resilience in the face of certificate problems, for example.
On 3, sure, I can understand that -- but this is true of any open source project. And it IS open source, so you can "own" your own code base. You're in control. And actually, Go's module proxy protects Go projects more than most C projects. Caddy's extensible architecture means that you can add all the features you need without bloating the code base.
[1]: https://caddyserver.com/docs/config-adapters