Caddy has a lot of great features, but (at least as of last year) Nginx has the edge on documentation. Caddy’s docs were almost useless. Hopefully they’ve improved since I last used it.
Debian 12 (bookworm) will have it: https://packages.debian.org/bookworm/caddy
In practice, in the case of less popular packages, they do this on demand, when someone requests it in the bug tracker.
I want to emphasize that we have no contact at all with the people maintaining that Debian package, they've never reached out to discuss anything. We're absolutely open to that (and they know where to find us, not hard to contact us either on GitHub, Twitter, our forums, here, etc).
They will contact you if the need arises. It's the same usual process that has been used since the 90s to great success.
It's ok to not want to support older versions or downstream packages (even if imo there is value in doing so) but don't be a drama queen and claim you can't.
Maybe. That is indeed a risk with third party distribution.
But do note that Debian has its own support channels, and infrastructure (like the "reporting" tool: https://packages.debian.org/stable/utils/reportbug ).
Maybe it's pretty good for very popular packages, but how about the more niche ones (and when it comes to Debian I'm not sure how popular Caddy is in their view)?
The versions often feel arbitrary and don't line up. For example... I've been watching this for years:
https://bugs.launchpad.net/ubuntu/+source/firewalld/+bug/183...
This is more on the edge case side of things, too. Not really security patch related -- but a consequence of picking/choosing component levels
With this the firewall can randomly just stop being effective
When things aren't exactly upstream, the knives you're juggling get a little bigger and more unbalanced.
That's exactly why people (including me) tend to like LTS - no critical changes till next release. Upgrades for security with minimal surprises. I go further and often use unattended-upgrades on my Ubuntu fleet. I don't wanna version bumping until I explicitly ask for it as much as possible.
In two patch versions? With minor version unchanged?
Instead, we ship with our own debian repo, hosting graciously provided by CloudSmith https://caddyserver.com/docs/install#debian-ubuntu-raspbian. This is packaged via CD with GitHub Actions, and you can verify the authenticity of the build since it's signed by Matt Holt's GPG key.
For RHEL, it's in COPR, and that's the best you'll ever get for similar reasons https://copr.fedorainfracloud.org/coprs/g/caddy/caddy/
And that goes without saying that Debian in general tends to release much slower than we'd be comfortable with. We don't want users running outdated and potentially insecure versions of Caddy. Best if users keep up to date by using a first-party installation method where we have control over the distribution pipeline.
That creates a bit of a split between Debian packages and language specific packages like rust crates, golang, python eggs or ruby gems.
There's some friction there, but the reasoning makes sense (but it is ok to disagree of course).
This is actually enforced and there is processes in place to ensure that it stays that way.
This means that all new software that Debian packages is audited by a group of volunteers, the ftp-masters team, they check copyright, license and stuff like that.
If all binaries in Debian would vendor all of their dependencies, this would cause a lot extra and duplicated work for the ftp-masters, a team that already have a lot to do.
Same with security, if a popular go library needs to be patched to fix a security problem, then it's easier to do that in one place instead of patching it in N different binary packages.
You can also build it from source using the `buildable` source archive artifact that includes all the deps so it can be built in air-gapped machine. Like its sibling artifacts, the source archive is signed, the signature is published, the signing certificate is available, and the checksum is published and also signed. What's so concerning?
[Disclaimer: Affiliated with Caddy]
Based on the sibling comment that points out a volunteer has packaged caddy for Debian 12 - that work has been done?
Despite v2 supporting a very similar config file, the documentation doesn't emphasise that and tries to steer you towards its API, confusing JSON config syntax etc.
It's still a very good web server for very few lines of config, but I don't relish trying to learn something new from its docs like I used to.
To say it again:
> It's all very confusing for someone looking in the docs for a solution and instead has to learn how everything works, whether they want to or not.
Maybe we should just un-index all docs pages except the intro pages.
1. A simple link like this: https://docs.k3s.io/installation/configuration#:~:text=For%2....
2. An aside at the top that informs the person where to get more information with a link.
3. An example showing the structure of the file.
4. A link to examples/tests in the repo showing how it can be used.
I would think that a simple aside in your template would work wonders. Maybe saying something like:
> See our page on [directives](link) to learn how to best use this in your configuration.
> The Caddyfile seems easier than JSON, but should you always use it? There are pros and cons to each approach. The answer depends on your requirements and use case.
Followed by a table comparing the json and caddyfile approaches. What's the confusion?
I disagree. The docs don't do that. What you're probably talking about is the Getting Started guide https://caddyserver.com/docs/getting-started, which is a tour of how Caddy works, so it first shows you the "bare-metal" look at how it works, then it introduces the Caddyfile which allows you to simplify your user experience.
There's even a comparison table between the two https://caddyserver.com/docs/getting-started#json-vs-caddyfi... which explains when you'd want to use JSON (i.e. if you want programmable, API-based usage) or Caddyfile (i.e. for quick-and-simple hand-written config, 95% of users choose this).
I recommend starting from https://caddyserver.com/docs/caddyfile-tutorial or https://caddyserver.com/docs/caddyfile/concepts to get an idea of how the Caddyfile works.
If it is fixed now then that is great, but it took at least a year (I'm guessing more) after the launch of v2.
Definitely take another look now, there's been a ton of progress since then, 3 years ago. The initial v2 release was in May 2020, soon after the pandemic hit.
What I'm trying to say is that on launch v2 was not a good replacement for v1, especially in the docs area. I've seen quite a few major version bumps in OSS, and it feels docs is an area that is usually neglected, and for quite a while (at least a year, I'd say more) the v2 docs where not useful for someone who had not participated in the caddy v2 community discussions.
I'm just trying to describe what led me to go from a avid caddy proponent back to an nginx user.
I'll take another look next time I have a project that needs a http/s server!
I agree with this, v1 was an excellent user experience, I actually ran it on my servers for way too long. There was also the Wedge fork which might have helped with the EOL but sadly it didn't go anywhere: https://github.com/WedgeServer/wedge
> Despite v2 supporting a very similar config file, the documentation doesn't emphasise that and tries to steer you towards its API, confusing JSON config syntax etc.
Others responded to this a bit more, but while I agree that different config types are a confusing experience, at the same time I appreciate that they support something like that in the first place. I might not use it often, but it's nice that you can.