Hacker News new | ask | show | jobs
by sbstp 755 days ago
Caddy is amazingly simple to setup. Automatic HTTPS is a killer feature.

I have to use Envoy at work for gRPC services and I want to quit the industry every time I have to edit their YAML/protobuf monstrosity of a config system.

2 comments

Envoy config surely is complex, but it's also the most flexible and robust way of managing config on a large scale I have come across.

The way envoy lets you create clusters of envoys, then just setup their config to come from a centralized config source through a grpc connection is honestly the most sane way of managing thousands of proxies at scale I have found. Trying to push nginx (or any other config as a file proxy) updates at scale is a nightmare of its own.

We manage a large number of envoy clusters, where the state of how proxying should happen is all contained within a SQL database where the rules and records change dozens or hundreds times a minute. There is one service that's responsible for monitoring the DB and translating it to envoy configs, then pushing them out to 1,000s of envoy processes. It has been extremely reliable and consistent. For a given input, always produce the same output. It's very easy to unit test, validate and verify, then push the update.

Nginx, and Caddy I'd imagine, are great at set-it-and-forget-it configs or use cases. But envoy is a programmable proxy where you can have dozens of clusters with different configs that get updated dozens of times a minute. I don't know of any other proxy that offers something like that.

Caddy does (some of) that too actually. It has a live config API and support for clusters and synchronized configs and TLS cert management. It can also get the proxy upstreams dynamically at request-time through various modules. Some of the biggest deployments program/automate Caddy configs using APIs and multi-region infrastructure.

But where Envoy shines, it really shines.

Envoy is definitely a powerful & useful tool, we use external auth to centralize our authentication, I just dislike editing large yaml documents with 10 levels of indentation.
My websites run on https because how easy Caddy makes it. Caddy made it possible for me. Cannot thank Matt Holt enough for creating Caddy and making it available to all of us.
I haven't used Caddy and I'm sure it's great, but you could have used nginx or anything else as well also. Offering https is honestly pretty easy these days.
I've been using nginx for years and switched to Caddy just because I was so fed up with configuring nginx to automatically renew TLS certs issued by Let's Encrypt. This is so much easier and reliable with Caddy.
I recently found certbot and it makes TLS with nginx a breeze. I like Caddy as well, but if you're forced to use nginx, try certbot!
I know about certbot and have considered it, but our customers can use their own custom domain name, which means we need to be able to select the certificate depending on the SNI hostname, which is a bit tricky in nginx. It's possible to use the $ssl_server_name variable in the ssl_certificate and ssl_certificate_key directives, but then the certificate will be loaded for each TLS handshake. And also need to be careful with race conditions when refreshing the certificate, to ensure that the certificate and they key are matching. Overall, it's doable, and people do it, but it's not as straightforward as just using Caddy.
Thousands of Caddy users beg to differ -- nginx won't scale HTTPS automation as well as Caddy can.
It's the idea that Caddy alone made it possible that I am skeptical of. I'm sure it's hyperbole but still.
We definitely couldn’t have done it without the community rallying around free encryption and let’s encrypt.