Hey Matt - thanks for creating and maintaining Caddy all these years! Like others have said in this thread, it is so easy to set up and maintain that it really does feel like "magic".

In terms of speeding up adoption of Caddy 2, it may be useful to have a list somewhere of the concrete improvements between the two (as I'm sure there are many). A (very) brief look and search around only yielded this article[1] which referenced another link of improvements that now 404s[2].

Cheers,

[1] https://caddyserver.com/v1/blog/caddy-2-ready-for-developers

[2] https://github.com/caddyserver/caddy/tree/v2#list-of-improve...

Thanks for the feedback! Glad you have had a good experience with it.

That blog post is pretty old. We do have a current upgrade guide here in our docs: https://caddyserver.com/docs/v2-upgrade

We also have a (sort of deprecated) wiki with some (slightly outdated) high-level improvements listed: https://github.com/caddyserver/caddy/wiki/v2:-Improvements

Another piece of feedback: It’s scary to consider using such a crucial piece of software in production when documentation is referred to as “sort of deprecated” and “slightly outdated.”

Because that's the old documentation, from early betas of Caddy v2.

The official documentation at https://caddyserver.com/docs/ is up to date, and not deprecated.

Oh! That’s good news. I’m excited to give it a try either way.

Adoption for me would be to have an official apt repo :)

I mean, we want one too, but it's ridiculously hard: https://news.ycombinator.com/item?id=23072385

Help? :D

I think the parent poster would already be happy with an APT repo provided by Caddy. It wouldn’t need to be included in Debian itself.

When you can make dpkg files, making an apt repo is trivial (using reprepro shipped with Debian)

And when it’s your repo, you make the rules about packaging what dependencies into which file(s)

But by having an apt repo (that users would subscribe to), you make it much easier for users to keep up to date

We do have one!

https://caddyserver.com/docs/install#debian-ubuntu-raspbian

Oooh this is great news, I can finally quit updating Caddy by hand!

Talk about a bummer... Golang makes it easy to make static binaries. Way too easy for the distro apparently.

Deb files will be just fine.

Pretty close to official. https://caddyserver.com/docs/install

Thank you for making this. Here's what I've been doing with it for the past month-and-change: https://geoff.tuxpup.com/posts/caddy_and_wireguard/

Very cool! I'll save this link.

I started using caddy (v2) a couple of months ago. I'm no dev/admin type and it has been a godsend because it made so easy for me to secure my sites

Congrats on the launch Matt. Great to see other independent software projects thriving like this. Keep up the hard work.

Just tried it by replacing NGinX on my personal servers... I don't have anything complex (python backends, some static files...) but so far the user experience is stellar :)

Thank you for your work on Caddy! After a false start during the beta (mainly because of the missing documentation) I upgraded my personal websites from v1 to v2 RC1, and since then I have been a fan of the new version. Caddy 2 makes somewhat complex configuration more consistent and easier to express in the Caddyfile. The only thing I miss from v1 is the default handling of when static files are not found.

I am very interested in the prospects of Starlark in Caddy 2. With an integrated scripting language Caddy could on its own be a replacement for OpenResty or Apache with mod_mruby. The preliminary implementation was removed in the beta phase with a note saying it would have to wait for when the project was financially stable [1]. Do you still plan to integrate Starlark if the project is a financial success?

[1] https://github.com/caddyserver/caddy/commit/8b28c36d480070c8...

Yeah, Starlark is still on my list. It'd be a killer feature, but it's a huge project.

Thanks for the great work - caddy is a much needed breath of fresh air in the server space.

One thing I stumbled upon the other day was that I (and google apparently, too) have trouble navigating the new website.

I find it much simpler to find relevant information on the old site.

Anyway, keep up the good work and stay healthy!

Thanks, we'll work on it! The nav/flow of content could probably be improved.

Not gonna lie though, there's more to learn. V2 is a powerful machine -- so do expect that there will be some reading. Once you know how it works, it's easy to use. Very simple configs are possible, etc.

What are some of the primary use cases you envision(ed) as well as any that have arisen?

It's often used as a reverse proxy and static file server, but oh, so much more is possible. Today, if you're using HTTPS, you should almost certainly be using Caddy. Maybe tomorrow if you need to set up a memory-safe SSH server, you could be using Caddy. (Just an example.)

Sorry for the stupid question, but what is a "memory-safe SSH server"? Thanks!

Not a stupid question, it's not a phrase you hear very often because there isn't... really... one... at all. (Not in mainstream use AFAIK?)

Memory safety is a class of guarantees certain software offers you against certain vulnerabilities. Software written in C is generally considered "memory unsafe" since it's hard to write correct C code when managing with memory, so it's easier to find exploits in them that cause them to reveal secrets.

Go software has stronger memory safety guarantees than C programs like OpenSSH and Nginx. So that's one big benefit of using Caddy.

As it happens, someone in the audience here is writing a SSH app for Caddy, so you have a pure Go SSH server that is less vulnerable to those class of attacks.

But what is the value add for Caddy here? Like how the out of box and auto SSL defaults with HTTP.

Apart from memory safety, can the SSH version of caddy impose better defaults that OpenSSH doesn’t right now? Maybe TLS certs, security key support, etc?

Absolutely. And Caddy adds its on-line config API and simpler configuration experience for an all-around more secure, easier-to-maintain, harder-to-get-wrong system.

Right, I suppose I'm asking what an elegant SSH config would look like, having almost only ever touched my sshd config less than 10 times in the 15+ years I've managed servers.

I know I'd ideally like easier SSO integration, for example. Or provisioning of users.

To add onto what Matt said, here's a teaser: https://twitter.com/mholt6/status/1257073951525572608

The docs list "process supervisor" as a use case. What does that mean exactly? Can it function like upstart/systemd?

Yeah, my hope is that someone will write a sort of scheduler / supervisor app for it so that I don't have to keep re-learning systemd every time I stand up a new service...

Thanks Matt! TLS endpoint, web server, load balancer, reverse proxy all in one. Rock solid uptime measured in years. I run it on every machine ;)

Am curious what tools you use for testing Caddy: generating traffic for load testing, web fuzzing, net simulation, etc?

Thank you for Caddy, it has saved me a lot of time and it's a joy to work with. Running it on about 8 boxes.

Is there an admin UI for v2? Seeing the configuration changes, it was the first idea that popped, would be great for the selfhosted community - maybe someone picks it up as a side project if it's not in scope.

An admin UI is planned, but it hasn't been started yet. It's not really a top priority, there's plenty of features that are more useful to have first.

Thanks for your work on Caddy. I've been using it since 2016 and it's served me well over the years.

Is there a list of those sponsors somewhere?

See the big "Thank you" note on the landing page; also GitHub sponsors: https://github.com/sponsors/mholt

Somehow I missed that "Thank you" section despite scrolling up and down the page a few times. Thanks!