Caddy 2.8
github.com
github.com
I set the same thing up with Caddy in minutes and it’s been running flawlessly for years.
Shoutout to Let’s Encrypt as well for making this so much easier!
For anyone who needs to run their own CA (which I'm now doing for my homelab), I've found that using GUI software like KeyStore explorer is a sufficiently easy and lazy way of doing that, which actually works well, both for securing regular sites, as well as doing mTLS: https://keystore-explorer.org/
For what it's worth, using OpenSSL directly and automating that for more frequently rotated certificates wouldn't be quite as pleasant, yet doable.
> Shoutout to Let’s Encrypt as well for making this so much easier!
For ACME stuff, Caddy will be excellent and honestly is probably the best option out there right now!
Nginx (and certbot) or Apache (and mod_md or certbot) will get you most of the way there as well, though the route will be a bit longer.
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.
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.
But where Envoy shines, it really shines.
That's its value really. It has the defaults you usually want with minimal boilerplate. If you need/want something more complex it's not necessarily the right tool any more.
I say this not as any kind of dig against Caddy but I feel like the entire value proposition is that its default configuration covers the 90% case so well. Sometimes being easy to use with good defaults goes a really long way.
The important thing is to be clear in your docs about your versioning strategy. And from a quick search of the Caddy website, I couldn't find anything that explains this. Their install guide doesn't really mention versions at all, giving people no clues that a minor version change could break their sites.
This is what people are desperately hoping to change. The industry is tired of updating from 4.7.1 to 4.7.2 and having everything break. Please bring sanity to versioning, so people can have a reasonable expectation that x.y to x.z isn’t going to require days of rewriting stuff.
Basically we try to put the bigger changes in the "minor" version bump (because bumping the major version introduces a lot of friction in the Go ecosystem) and encourage people to read release notes. We are open to suggestions though!
The solution is one more number: Marketing.Breaking.Feature.Bugfix
Semver is great for libraries. Caddy is a project which has so many dimensions of "surface area" that it's hard to boil down the implications of changes into a single decimal-separated number. Presumably this is why a lot of larger projects use year-month versioning or just bump the major version every release. I'm actually considering doing the latter, except ... Go modules are very opinionated about major version bumps because it was designed with libraries, not commands (main funcs) in mind... and bumping the major version each release would be also be a major inconvenience to dozens of plugin authors.
Caddy has a Go API, a configuration surface (two built-in: JSON and Caddyfile); a config API; HTTP, TLS, TCP, and UDP behavior; a command-line interface; etc... the list goes on and on in ways that can break a deployment. Which of those does the one and only semver version apply to? Go has opinionated tooling around semver for the Go package stuff, so we kind of have to cater to that, but end users don't really care about that. We could split the project into multiple smaller sub-projects, each with their own versions, but then it gets confusing and tedious to build and maintain. It's also inconvenient for people to contribute to that. And we'd have to ship Caddy with several versions, one for each "surface area dimension."
We've settled on mediocrity with our current version scheming which I admit is not my favorite, but I haven't really found anything better yet. Year-month versions are nice except that it implies either a regular release cadence (which we don't have) or that a larger span between two releases is more significant than more frequent releases (maybe true, but maybe not); it doesn't really tell you anything about the build... just approximately when it was made, but not even exactly when it was made (a month is a big window!) - I guess if you do multiple releases per month you just tack another number on the end? Maybe it should just be a timestamp. Or we could invent an N-dimension decimal number or some sort of string that has to be split and parsed...
Anyway. We do try to be gentle with breaking changes. Most of these have been documented as deprecated for years as well as printing warnings in logs. But we try to minimize the number of these, for sure.
Whilst PHP is considered dated now and the language has many faults, you can't critic how easy is to get started (drag drop files in a directory and you're done)
It takes a lot of discipline to have all tickets & commits titled this way. But it makes reading a change log so much easier to parse as a human.
I recent wrote a forward_auth server to use with Caddy's forward_auth functionality:
https://github.com/crowdwave/checkpoint401
https://caddyserver.com/docs/caddyfile/directives/forward_au...
Would be awesome if they provided a pre-built container for each module, but understand it'd create a very large number of builds for them, and then people would want module+module which would create an exponentional number of possibilities.
Maybe an all modules build and the ability to toggle them via ENV?
I created a project that does this, it automatically builds images on new releases of caddy or any of the plug-ins. It builds images for almost all caddy-dns plug-ins, thanks to unlimited github actions minutes :)
I have been trying to use Caddy locally, haven't been successful with replacing http-server yet but it's a good start
Is it just me, or is this a monumentally bad idea? Which is more likely - LE having to revoke certificates, or hacker figures out how to trigger the revocation mechanism? Or Congress passes a bill outlawing encryption that doesn't use a backdoor key, and LE is ordered to revoke hundreds of millions of keys?
This is a hammer in search of a nail that doesn't really exist.
Now I'm warming up to it. But I still think I would have done it differently... ARI is essentially a "hint" to clients, but at the same time CAs can provide benefits (e.g. rate limit exemptions) if abiding by ARI windows. It feels weird to have scheduling split between the CA and the client. I would have liked a solution that either keeps the scheduling authority with the client, or transfers it to the CA, rather than straddling both. (I think my ideal scenario would be to have a single endpoint that returns a list of all certificates on the account that should be renewed presently. That way clients just have to poll it and renew any certs on that list. It would be much simpler than what I ended up implementing.)
I am not actually concerned too much with ARI with respect to revocation or hackers or government coercion. Mainly complexity.
Anyway... I could probably talk about the pros and cons of ARI for a while. It is a net good, I think, and it does solve a problem (mostly a problem CAs have, and it kind of puts the burden on clients). I just want the ACME/TLS ecosystem to settle down a little now. :)
it actually doesn’t seem like that long of a list if you only consider one version per library
Or just go version -m
> 122 packages
That's still a lot
> many of which are indirect)
That means literally nothing. Indirect still gets built, indirect still in the exe.
A lot of the /x/ packages are repeated, just different versions; and I believe -- if my understanding is right -- a lot of these are only used for checksum verification, not necessarily a manifest of what is compiled into the binary.
But, the point remains, dependencies can bloat quickly, which is why we went with such a modular architecture for Caddy 2.
This tripped me up trying to minimize dependencies for a library by splitting it into a separate repo from the rest of the application, but this is totally unnecessary (and annoying to manage).
Go modules are pretty good.
I was hoping I could use it to forward "pure" UDP ports but I think it's considered out-of-scope by the devs. They do support HTTP/3, however.