Hi HN -- this is what I've been working on for the last 14 months, with the help of many contributors and the backing of several sponsors. (Thank You!)
Caddy 2 is a fresh new server experience. Some things might take getting used to, like having every site served over HTTPS unless you specify http:// explicitly in your config. But in general, it will feel familiar to v1 in a lot of ways. If you've used v1 before, I recommend going into v2 with a clean-slate using our Getting Started guide: https://caddyserver.com/docs/getting-started
I'm excited to finally get this out there. Let me know what questions you have!
I know that HN is usually the first to outrage when a project website is too verbose or does not explain the product, but I just want to take a moment to say WHAT A GREAT WEBSITE Caddy has!
- The first screen tells me everything I need to know about what Caddy is and why it stands out
- Scroll down on how to setup (hattip to whoever did the angled asciinema embed. Looks so cool)
- Every page worth of scroll is exactly the right amount of information with links to dig deeper
- The Upcoming features at the end is such a great touch as well.
- All this in a UI which looks absolutely great!
Excellent work guys and congratulations on the V2 launch! Been playing with Caddy quite a bit for personal projects, and been a very happy user. Will definitely be using v2 more! :)
I was really nervous to post this on HN because HN has also been the source of great misery for me in the past, frankly. But I'm relieved at the overall positivity today. Maybe because it's Star Wars Day we're all in a good mood?
I'm glad you like the landing page. Took me a couple weeks of trying and throwing designs away, then a few days of concerted effort, just standing in front of my text editor cranking out HTML and CSS best I could muster. The visual touches aren't perfect but I'm quite pleased.
... come to think of it, reading the criticism from HN on other projects made me hyper-aware of certain things, like explaining what the product actually does, and how to lay it out, and not mess with scrolling, etc etc. (But not the toxic comments, I skip those.)
I started using caddy v1 thanks to lightning-fast and simple TLS setup and extremely simple configuration in general, thanks to the excellent docs and handy plugins for common stuff like cors, rewrites and fastcgi.
Shortly after upgrading to caddy v2, I switched to nginx, after spending way too much time trying to make sense of the new Caddyfile and docs (the thing I miss the most of the docs is the plugin list, along with the cors plugin, and in general the non-existant entry curve of Caddy v1).
Tbh, I also miss the one-liner install script <3
I'm genuinely sorry for the project; I didn't mind at all any of the previous so-called shady behavior (I personally don't object at all against a developer trying to make a living out of his own open-source project); I've been using caddy for four years now, and I really hope to switch back to it, one day.
As francislavoie said, the website with its nice one-click custom download page and list of registered plugins is a lot of work. It'll come, but it's not ready yet. Much like the v1 release 5 years ago where the interactive download page didn't come until about a year later, it'll take some time. Hopefully not a full year though. :)
I've already got the new build server mostly written -- should be way faster.
If you need any help when coming back to Caddy v2, come ask for help on the community forums: https://caddy.community/
We'll be glad to help you get set up!
The docs are still a work in progress, we'll eventually have a plugin registry like in v1 but that requires a bunch of work behind the scenes to make it happen.
I have been using Caddy for quite some time now, as a replacement for "python -m SimpleHTPServer" and by just flipping a switch as real webserver and this is such great news.
I am so happy you end up going down the route of an open license, this right here is a game changer. I can't even begin to imagine the ins and outs that must have been crossing your mind in the last year. But, as things stands, I am very sure there is a bright future for Caddy. What a fantastic piece of software.
I am one more to be grateful for this product. Thank you. You are helping people.
I recently switched my site from using Amazon Linux 1 + Apache + manual setup to Amazon Linux 2 + Caddy 2 + automated Ansible setup. The documentation for Caddy 2 wasn't quite 100% at the time, but it looks like it's in much better shape now. But Caddy 2 just worked, and gave me SSL seamlessly out of the box, zero config. Love it! My entire Caddyfile looks like this:
giftyweddings.com {
encode gzip
reverse_proxy localhost:8080 # Go web server
}
www.giftyweddings.com {
redir https://giftyweddings.com{uri} permanent
}
Also, mholt's "Caddy saves money" quip on the homepage was true in my case. After the switch I was able to downsize my instance to a very small size and save about 50% on my AWS bill, down to less than $10 per month. Not entirely sure it was due to Caddy, but I "blame" it on that anyway. :-)
The one thing I found tricky was getting the systemd config file correct (I'm not a Linux pro). Looks like he's addressed that too, with this README and demo systemd config -- nice! https://github.com/caddyserver/dist/tree/master/init
Be aware that the [trusted=yes] config disables GPG signature verification for the repository, which does slightly break the security model of Apt (where repositories can be untrusted/HTTP-only as long as all packages are signed by trusted keys).
Unless I'm mistaken, a malicious package with the same name as a critical system package could be added to that untrusted repository by an attacker who had compromised it, and if the version number is higher than that of the 'official' package and your Apt priority config prioritises it, your system would download and install it without any verification.
This is a fairly niche attack vector that may not be considered a significant risk in some environments, but it's one to consider when establishing your threat model and risk appetite.
As a side note, it's worth noting that GPG signing packages is not a silver bullet either, especially if the signing keys and administrative access to the repository fall within the same security boundary (e.g. developer doing both from their PC without any segregation/sandboxing). However, it has proven to be a robust method so far, and definitely beats explicit [trusted=yes].
I liked v1 a whole lot. I'm interested in v2, though I'm extremely skeptical of the additional complexity of the config adapter layer (https://caddyserver.com/docs/config-adapters) - I'm more or less sold on having an internal JSON structure with a DSL on top of it (allowing dynamic/programatic config is really interesting), but the idea of having _multiple_ different DSLs or config syntax bindings for it seems a bit much.
The biggest feature in Caddy 2, from what I can tell, is the new HTTP config API, and I'd love to see a practical example of what could be done with that.
Don't worry about the "additional complexity" -- config adapters are modular, and only the Caddyfile adapter is baked into the standard modules. Just plug in the adapters you need. Caddy functionality can grow rather infinitely without bloat because of this.
True, the Caddyfile adapter is a bit of a beast because it is extensible itself -- but it's a lot cleaner and more flexible than the v1 implementation, where the Caddyfile was its native config syntax.
Believe me, this is a big improvement.
Anyway, you don't have to use the adapters if you don't want to. That's the beauty of it.
More info on the architecture and config adapters:
Caddyfile is the primary supported DSL. The rest are nearly 1:1 mappings to the internal JSON with some sugar, except for the nginx config adapter which is a bit special! For example jsonc provides JSON, but with comments.
A few of those are third party maintained, and are plugins. They're listed on that page to point out what's possible.
Same here! We are huge fans of Caddy at Narration Box (https://narrationbox.com) and we are considering replacing NGINX completely in our Django production stack. (Currently we only use Caddy for development and staging) The author of Caddy, Matt Holt, is a really great person and is extremely responsive on Twitter and GitHub. Highly recommend checking them out.
I love Caddy 1, been using it for years after my annoyances with nginx. I've never looked back. Built-in TLS setup is amazing but the killer is that you can host a website with only a few lines of configuration in a single file. Now I'm managing dozens of websites with a single file with only ~4 lines of config per domain (most of it is the same).
I was nervous about Caddy 2 because I could imagine the core was better but I couldn't fathom how the config process could be any better than v1 (my favorite part). I was wrong - the v2 config introduces some clever ideas which makes it better too. It has a great simplicity to it that is extremely powerful and I found that I could get rid of a couple of the plugins I used with v1 because you can harness the power of the v2 matchers to do so many things.
Thank you mholt and thank you francislavoie, Caddy 2 is awesome!
I am a happy user of Caddy v1, and I want to thank you developers! It's made my life much easier, managing TLS automatically for my home server, and having a less than 10 lines adequate config for 3 web services I use behind it. I even forgot I was using Caddy, which is a proof of how great it is for systems integration.
I'll be looking forward to v2 in a few weeks, when I will upgrade to newer ubuntu and go full ZFS.
I just heared about Caddy v2 four days ago on a reddit post and it is awesome! Thanks a lot for your great work :)
It is by far the easiest solution I could find to install a reverse proxy which can route by the URL /api/* and gets an automatic Let's Encrypt Certificate.
Hi mholt!,
I am building an ecommerce SaaS.Obviously,i will have each domain pointed to my server.Is Caddy a good choice for automatically getting a certificate for each website?Are there any limitations?
Thanks!
Yes, it is! Ask Jack Ellis at Fathom Analytics, they're doing this for their customers: https://usefathom.com/blog/bypass-adblockers -- and I think they have a new blog post and video coming out soon about it.
It really goes to show that you can write good software in any language/framework you're comfortable in. PHP powers Facebook, wikipedia, and Slack for instance and it gets tons of hate on HN.
I'm mostly a C#/Typescript/Python guy .. but good software is good software!
Sooo... you bring up something I could use some "learn me somes" on... golang. Recently, in my personal life when choosing a "next language" to learn I chose Rust over Go because it seemed to offer everything Go does, and then some (like them systems level programmings). However, at my current employer, Go has a solid following and I'm unlikely to sell Rust (or even want to[1]): could you please speak to that real-world efficacy or what things you think it does superbly well to enable software like this?
I tried briefly to find some guides on go over the weekend, but an awful amount of them are targeted to using "X web framework," which seems utterly worthless (or boring) to me. I guess, to your point, I could go read through the Caddy source code and see what I find since this seems like a nice and useful application using Go.
[1]: There's almost no reason to sell a team on any new technology if there isn't a substantial gain from it. For the org I am at, I don't believe, Rust offers much over Go for most of the use cases. Sure, it certainly can be _faster_ but who fucking cares? Most of what we do isn't bound by machine time, it's bound by developer time. Thus, I seek to learn me some golang and what virtues it offers.
I used caddy on and off for many years and finally went back for good.
For one, the community support is fantastic. Matt, Francis, you will not recognize me from my name here but you were first class helpers (and still are).
The fact that caddy has an API is a breakthrough. Automating config provisioning is a godsend
I belive that you child easily take over Traefik in the edge router space if configuration was a bit more modular (today is is Caddyfile, or API and no external sources of data such as the docker daemon (there was some discussion about that with the owner of Lucas Lorentz @lucaslorentz but it is I think dead-ish).
I moved yesterday all my prod from Traefik to caddy and it works just great.
I have been using Caddy v1 for more than a year now as a web server for some of my production sites. I'm really happy with the simplicity of it and especially out of the box SSL support with LetsEncrypt. I believe with v2 I will be moving more of my sites to Caddy. Thank you for all the hard work :)
Thank you for sharing your experience. Glad to hear it. Feel free to join our forums and be a part of the community! https://caddy.community - could always use more people with experience helping out. :)
I just upgraded a server to Caddy 2 this past weekend. It's running a single WordPress site.
There were some gotchas in converting the Caddyfile to the new format, but I eventually sorted it out. Caddy 2's method of updating the config made the iteration process a lot faster.
I'll admit I got bit by a few differences between the v1 Caddyfile and the v2 Caddyfile too. Namely forgetting * at the end of a path _prefix_ matcher. (In Caddy 2, path matches are exact, unless you suffix with a *.)
Thanks for the nice piece of software. I like Caddy a lot. I would like to better integration with docker in terms of automated exposure of docker services based on labels for example. Similar how traefik does. That would be really nice to have.
I've always felt like that was kind of a hack, but with Caddy's API it's doable. I don't really use Docker myself, so... want to contribute the feature? I'll show you how to integrate it.
Excellent. I'm really excited about Caddy 2. We've been using Caddy 1 to server all our main sites over https and simply for the last 4 years. I moved away from Apache and have never ever looked back.
I really like Caddy and use it for general side projects. Super simple setup, handles all the LetsEncrypt certificates for me, can be running different apps on different paths.
[+] [-] mholt|5 years ago|reply
Caddy 2 is a fresh new server experience. Some things might take getting used to, like having every site served over HTTPS unless you specify http:// explicitly in your config. But in general, it will feel familiar to v1 in a lot of ways. If you've used v1 before, I recommend going into v2 with a clean-slate using our Getting Started guide: https://caddyserver.com/docs/getting-started
I'm excited to finally get this out there. Let me know what questions you have!
[+] [-] madmax108|5 years ago|reply
- The first screen tells me everything I need to know about what Caddy is and why it stands out
- Scroll down on how to setup (hattip to whoever did the angled asciinema embed. Looks so cool)
- Every page worth of scroll is exactly the right amount of information with links to dig deeper
- The Upcoming features at the end is such a great touch as well.
- All this in a UI which looks absolutely great!
Excellent work guys and congratulations on the V2 launch! Been playing with Caddy quite a bit for personal projects, and been a very happy user. Will definitely be using v2 more! :)
[+] [-] mholt|5 years ago|reply
I was really nervous to post this on HN because HN has also been the source of great misery for me in the past, frankly. But I'm relieved at the overall positivity today. Maybe because it's Star Wars Day we're all in a good mood?
I'm glad you like the landing page. Took me a couple weeks of trying and throwing designs away, then a few days of concerted effort, just standing in front of my text editor cranking out HTML and CSS best I could muster. The visual touches aren't perfect but I'm quite pleased.
... come to think of it, reading the criticism from HN on other projects made me hyper-aware of certain things, like explaining what the product actually does, and how to lay it out, and not mess with scrolling, etc etc. (But not the toxic comments, I skip those.)
[+] [-] Scarbutt|5 years ago|reply
How can you infer what Caddy is about from that?
[+] [-] danogentili|5 years ago|reply
Shortly after upgrading to caddy v2, I switched to nginx, after spending way too much time trying to make sense of the new Caddyfile and docs (the thing I miss the most of the docs is the plugin list, along with the cors plugin, and in general the non-existant entry curve of Caddy v1). Tbh, I also miss the one-liner install script <3
I'm genuinely sorry for the project; I didn't mind at all any of the previous so-called shady behavior (I personally don't object at all against a developer trying to make a living out of his own open-source project); I've been using caddy for four years now, and I really hope to switch back to it, one day.
Thank you for your work, mholt! <3
[+] [-] mholt|5 years ago|reply
I've already got the new build server mostly written -- should be way faster.
[+] [-] francislavoie|5 years ago|reply
We'll be glad to help you get set up!
The docs are still a work in progress, we'll eventually have a plugin registry like in v1 but that requires a bunch of work behind the scenes to make it happen.
[+] [-] nhatcher|5 years ago|reply
[+] [-] benhoyt|5 years ago|reply
[+] [-] benhoyt|5 years ago|reply
[+] [-] nikisweeting|5 years ago|reply
[+] [-] jamieweb|5 years ago|reply
Unless I'm mistaken, a malicious package with the same name as a critical system package could be added to that untrusted repository by an attacker who had compromised it, and if the version number is higher than that of the 'official' package and your Apt priority config prioritises it, your system would download and install it without any verification.
This is a fairly niche attack vector that may not be considered a significant risk in some environments, but it's one to consider when establishing your threat model and risk appetite.
As a side note, it's worth noting that GPG signing packages is not a silver bullet either, especially if the signing keys and administrative access to the repository fall within the same security boundary (e.g. developer doing both from their PC without any segregation/sandboxing). However, it has proven to be a robust method so far, and definitely beats explicit [trusted=yes].
[+] [-] francislavoie|5 years ago|reply
That was my pet project for the past couple weeks, I'm so glad to see people appreciate it!
[+] [-] jbverschoor|5 years ago|reply
[+] [-] avolcano|5 years ago|reply
The biggest feature in Caddy 2, from what I can tell, is the new HTTP config API, and I'd love to see a practical example of what could be done with that.
[+] [-] mholt|5 years ago|reply
Some adapters are 1:1 translations so they are just a few lines of code: https://github.com/caddyserver/json5-adapter/blob/master/jso...
True, the Caddyfile adapter is a bit of a beast because it is extensible itself -- but it's a lot cleaner and more flexible than the v1 implementation, where the Caddyfile was its native config syntax.
Believe me, this is a big improvement.
Anyway, you don't have to use the adapters if you don't want to. That's the beauty of it.
More info on the architecture and config adapters:
- https://caddyserver.com/docs/architecture
- https://caddyserver.com/docs/config-adapters
[+] [-] francislavoie|5 years ago|reply
A few of those are third party maintained, and are plugins. They're listed on that page to point out what's possible.
There's a tutorial for the API in the docs that should give you a good idea of what you can do: https://caddyserver.com/docs/api-tutorial
[+] [-] sqs|5 years ago|reply
[+] [-] narrationbox|5 years ago|reply
[+] [-] qrv3w|5 years ago|reply
I was nervous about Caddy 2 because I could imagine the core was better but I couldn't fathom how the config process could be any better than v1 (my favorite part). I was wrong - the v2 config introduces some clever ideas which makes it better too. It has a great simplicity to it that is extremely powerful and I found that I could get rid of a couple of the plugins I used with v1 because you can harness the power of the v2 matchers to do so many things.
Thank you mholt and thank you francislavoie, Caddy 2 is awesome!
[+] [-] sizeofchar|5 years ago|reply
I'll be looking forward to v2 in a few weeks, when I will upgrade to newer ubuntu and go full ZFS.
Thank you!
[+] [-] mholt|5 years ago|reply
[+] [-] erikswn|5 years ago|reply
It is by far the easiest solution I could find to install a reverse proxy which can route by the URL /api/* and gets an automatic Let's Encrypt Certificate.
[+] [-] celicaraptor|5 years ago|reply
[+] [-] mholt|5 years ago|reply
Feel free to post in our forums with questions! https://caddy.community
[+] [-] Mojah|5 years ago|reply
We’ve done this exact same thing and have a technical writeup here: https://ohdear.app/blog/how-we-used-caddy-and-laravels-subdo...
Tl:dr: very easy to do, Caddy takes care of 90% of the complexity.
[+] [-] lenkite|5 years ago|reply
[+] [-] seabrookmx|5 years ago|reply
It really goes to show that you can write good software in any language/framework you're comfortable in. PHP powers Facebook, wikipedia, and Slack for instance and it gets tons of hate on HN.
I'm mostly a C#/Typescript/Python guy .. but good software is good software!
[+] [-] rubyn00bie|5 years ago|reply
I tried briefly to find some guides on go over the weekend, but an awful amount of them are targeted to using "X web framework," which seems utterly worthless (or boring) to me. I guess, to your point, I could go read through the Caddy source code and see what I find since this seems like a nice and useful application using Go.
[1]: There's almost no reason to sell a team on any new technology if there isn't a substantial gain from it. For the org I am at, I don't believe, Rust offers much over Go for most of the use cases. Sure, it certainly can be _faster_ but who fucking cares? Most of what we do isn't bound by machine time, it's bound by developer time. Thus, I seek to learn me some golang and what virtues it offers.
[+] [-] BrandoElFollito|5 years ago|reply
For one, the community support is fantastic. Matt, Francis, you will not recognize me from my name here but you were first class helpers (and still are).
The fact that caddy has an API is a breakthrough. Automating config provisioning is a godsend
I belive that you child easily take over Traefik in the edge router space if configuration was a bit more modular (today is is Caddyfile, or API and no external sources of data such as the docker daemon (there was some discussion about that with the owner of Lucas Lorentz @lucaslorentz but it is I think dead-ish).
I moved yesterday all my prod from Traefik to caddy and it works just great.
Thanks a lot for caddy!
[+] [-] francislavoie|5 years ago|reply
[+] [-] avip|5 years ago|reply
Have been running Caddy in production for a year with no issues and much rejoice over my 3 loc config which I can literally memorize.
All praise to Caddy's devs gj
[+] [-] BilalBudhani|5 years ago|reply
[+] [-] mholt|5 years ago|reply
[+] [-] bovermyer|5 years ago|reply
There were some gotchas in converting the Caddyfile to the new format, but I eventually sorted it out. Caddy 2's method of updating the config made the iteration process a lot faster.
[+] [-] mholt|5 years ago|reply
I'll admit I got bit by a few differences between the v1 Caddyfile and the v2 Caddyfile too. Namely forgetting * at the end of a path _prefix_ matcher. (In Caddy 2, path matches are exact, unless you suffix with a *.)
[+] [-] seaghost|5 years ago|reply
Thanks for the nice piece of software. I like Caddy a lot. I would like to better integration with docker in terms of automated exposure of docker services based on labels for example. Similar how traefik does. That would be really nice to have.
[+] [-] mholt|5 years ago|reply
You might be interested in this discussion: https://github.com/lucaslorentz/caddy-docker-proxy/issues/13...
[+] [-] tobya|5 years ago|reply
Well done Matt and Francis
[+] [-] mholt|5 years ago|reply
[+] [-] gfosco|5 years ago|reply