Caddy Server Is Acquired By Apilayer(ardanlabs.com)
ardanlabs.com
Caddy Server Is Acquired By Apilayer
https://www.ardanlabs.com/news/2020/08/caddy-server-is-acquired/
117 comments
Thanks for your feedback! That's great to know. The startup times were recently improved in collaboration with one of our corporate sponsors, Fathom Analytics.
The remaining duration is likely due to the speed of the storage backend and/or CPU, but I'd need to see a profile to know with more certainty. 8000 certificates is a lot of decoding/encoding and crypto operations. Caddy can handle it, but the hardware has to be up to snuff too. Post in our forum and we can look for ways to optimize it even more once we know where the bottleneck is.
The remaining duration is likely due to the speed of the storage backend and/or CPU, but I'd need to see a profile to know with more certainty. 8000 certificates is a lot of decoding/encoding and crypto operations. Caddy can handle it, but the hardware has to be up to snuff too. Post in our forum and we can look for ways to optimize it even more once we know where the bottleneck is.
Thank you! Will do.
Thank you for Caddy ! It's been my default HTTP server for a few months and so far the user experience is stellar.
The first time I used caddy (came to it from nginx), I was blown away by how simple it was to get up and running (letsencrypt etc...). Thank you for creating something wonderful, and congratulations!
Does it make sense to announce that a company has "acquired" an open source project? Wouldn't it make sense to title and write the article that the company that writes most (or all) of the code was acquired? "Light Code Labs, LLC."
Light Code Labs was not acquired; just the Caddy and CertMagic projects and their assets.
Would it be safe to say then, that Apilayer has simply acquired the trademarks and the domain name of an open-source project?
Edit: If the entire project is licensed under Apache License 2.0, what does acquiring the copyright give? The ability to change the license going forward?
Edit: If the entire project is licensed under Apache License 2.0, what does acquiring the copyright give? The ability to change the license going forward?
And the copyright, dude. And literally what else is there? That's the project itself.
[deleted]
And copyright?
They probably also acquired the copyrights the seller held on the code, allowing them to use them as they see fit ( for example integrate them in products that have incompatible license requirements)
Open source projects still have a copyright holder with special rights.
Don't contributors retain the rights on their contributions in most cases? I see nothing about contributor agreements or copyright assignment in Caddy's repo.
We use a CLA bot and ask contributors to sign it with their github account. For example, from a random open PR from a first-time contributor: https://github.com/caddyserver/caddy/pull/3680#issuecomment-...
That CLA doesn't seem to assign any copyright, just attest that the user has the right to license it under the license.
This. That CLA does not assign copyright, so they can't relicense. I'm sure they know that though and either scrubbed those out at some point or are pursuing other ways of monetizing it.
It is interesting to me that an open source project would be acquired, which is literally the trademark and copyright. However since the copyright is literally governed by copyleft they really can't change anything unless every contributor agrees or they actively re-write the code that scrubs non-agreeing contributors.
In any event someone could fork today, and rename it Cuddly Server as long as the copyleft stays in place. See Jenkins/Hudson.
In any event someone could fork today, and rename it Cuddly Server as long as the copyleft stays in place. See Jenkins/Hudson.
It seems their repo conveniently neglects to mention that there are, in fact, about 60 copyright holders:
https://github.com/caddyserver/caddy/blob/master/AUTHORS
https://github.com/caddyserver/caddy/blob/master/AUTHORS
Yes? Just like Apple bought CUPS.
Every open source project has IP (intellectual property) associated with it, such as its brand name, domain name, etc. This can be acquired or transferred separately from the company which writes the code.
Didn't they already join forces a while back? Am I missing something here?
And what does this do for Caddy as an open source server? Will it fork into a confusing mess of features like nginx did?
Update: According to mholt's post above, the gist:
- happened 6 months ago
- everything is still Apache 2.0
And what does this do for Caddy as an open source server? Will it fork into a confusing mess of features like nginx did?
Update: According to mholt's post above, the gist:
- happened 6 months ago
- everything is still Apache 2.0
I was hired by Ardan Labs last year to develop Caddy 2. Ardan is still the exclusive partner for business/enterprise support (which I recommend for companies using Caddy). I now work on Caddy full-time through support from apilayer (the new owner) and other sponsors. This should be a more stable and long-term arrangement that benefits everyone, especially the user base / community!
The last six months should give you some idea.
And no, I'd rather quit than make a mess of the project.
The last six months should give you some idea.
And no, I'd rather quit than make a mess of the project.
Great, and congrats again on the arrangement. Definitely more sustainable.
What does this means for Caddy? Are we gonna need to fork or are they gonna simply keep developing it in an open way? I wasn't able to grok this info from the post in the link.
Thanks in Advance.
Thanks in Advance.
Looks like the license won't change, and now there's an easy way to get a paycheck[1]
[1]: https://caddy.community/t/caddy-and-certmagic-have-new-owner...
[1]: https://caddy.community/t/caddy-and-certmagic-have-new-owner...
amazing! thank you
Hi HN. Here's my own announcement with some details: https://caddy.community/t/caddy-and-certmagic-have-new-owner...
Please note that there are no changes to licensing, and this transfer actually happened about six months ago.
I'm quite happy about this. We're already seeing some great things. For example, in Caddy 2.2 there will be native ZeroSSL ACME support (with Let's Encrypt still being the default, because ZeroSSL requires EAB) -- which is appealing because ZeroSSL doesn't have tight rate limits like Let's Encrypt does. It's also good to diversify the ACME CA ecosystem a little bit.
I'm also less stressed and outputting better quality work this year. (Compare the code base from Caddy 1 with that of Caddy 2 and you'll see what I mean.)
We have more committed maintainers as well due to its growth and stability, which I'm very grateful to all who contribute!
Please note that there are no changes to licensing, and this transfer actually happened about six months ago.
I'm quite happy about this. We're already seeing some great things. For example, in Caddy 2.2 there will be native ZeroSSL ACME support (with Let's Encrypt still being the default, because ZeroSSL requires EAB) -- which is appealing because ZeroSSL doesn't have tight rate limits like Let's Encrypt does. It's also good to diversify the ACME CA ecosystem a little bit.
I'm also less stressed and outputting better quality work this year. (Compare the code base from Caddy 1 with that of Caddy 2 and you'll see what I mean.)
We have more committed maintainers as well due to its growth and stability, which I'm very grateful to all who contribute!
I didn't know what EAB is, and it was hard to google:
https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.htm...
https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.htm...
Question I have about Caddy. Is it usable as a module? Could I use it as a library and have full access to its API or can I only really use it as a binary?
The possibility of building a web server framework on top of it is very interesting to me if the entire API is also programmatically accessible
The possibility of building a web server framework on top of it is very interesting to me if the entire API is also programmatically accessible
I mean, technically yes, since the only the Caddy's `main()` does is call a function that parses CLI args; all of Caddy's logic is in importable packages. But in order to be useful you'd have to have a config document (usually JSON, or some other supported format through Config Adapters) to pass into either `Load()` or `Run()`: https://pkg.go.dev/github.com/caddyserver/caddy/v2?tab=doc#L...
But most people do it the other way around: write a Go program or library and then make it a Caddy module: https://caddyserver.com/docs/extending-caddy
But most people do it the other way around: write a Go program or library and then make it a Caddy module: https://caddyserver.com/docs/extending-caddy
Nothing wrong with having to pass in a config, though it’s a question of control for me, like being able to use the full power of Go to handle complex scenarios, hot loading modules etc.
Have you given this any serious consideration making it more API friendly for developers in this way?
My issue with modules is you will inherently be limited at a certain point
Have you given this any serious consideration making it more API friendly for developers in this way?
My issue with modules is you will inherently be limited at a certain point
If you need that much or absolute control, I'd recommend don't use a framework or high-level library at all.
As for specific features or functionality, feel free to ask on our forums in more detail, or request it on the issue tracker. I don't really know what "complex scenarios" entails here, or "hot loading modules" can mean a lot of things.
As for specific features or functionality, feel free to ask on our forums in more detail, or request it on the issue tracker. I don't really know what "complex scenarios" entails here, or "hot loading modules" can mean a lot of things.
Thanks for posting this. I had immediate fear and this made much of it go away.
Good to hear and thanks for your (and others) work on Caddy, it’s always been fun to use for my self-hosted setup :)
Glad it's fun! Home projects should be enjoyable like that. Hopefully you can deploy it into production for your next work project too.
I’m afraid all our servers run on Windows and use IIS ;)
Caddy runs great on Windows! But the integration with OS-specific features might not be super tight. What do you use from IIS that only IIS does?
Running 2 sites that use ASP.NET Webforms (in case you don’t know it, an 18-year-old technology that has a lot of problems and only runs on .NET Framework). I don’t think it’s a good fit for Caddy ;)
Caddy can sit in front of it as a proxy, no problems. It can terminate TLS for you, and your existing server can do the rest of the heavy lifting for serving your site.
Congratulations - well deserved result for a really great project
[deleted]
Very cool Matt!
Congratulations Matt! Big fans of Caddy here at Narration Box. The reverse proxy setup and strong defaults are unmatched and are a joy to use. My favourite feature is the Cloudflare Let's Encrypt DNS-01 challenge integration, it makes adding TLS to internal networks a lot easier for devices like the iPhone/iPad where the cert store is heavily locked down.
Excellent, I'm glad it's working well for you! Thanks for the feedback.
I'd love to see a write up on this setup.
It is coming soon. We all post it here and on twitter when it's ready.
https://twitter.com/narrationbox
https://twitter.com/narrationbox
Caddy is awesome. Thanks a lot.
Congrats and thanks for your work on Caddy!
Great news that apilayer wants to keep it open source, and even better news that you can be less stressed and be happier about your work.
Great news that apilayer wants to keep it open source, and even better news that you can be less stressed and be happier about your work.
Thanks for the clarification and thanks for all the great work! Wish you and Caddy all the best for the future :)
Just want to say from afar this project has been an inspiration and reflection of true tech entrepreneurship, with all the struggles, stepbacks, and ultimately hard earned successes, that isn’t seen in the typical Herman-Miller VC model so popularly touted on HN and other tech circles.
Your accessibility, community building, and consistency is one I hope to emulate in my future projects.
Hope the deal announced here gives you the financial security you deserve and that caddy remains in the space for a long time.
Your accessibility, community building, and consistency is one I hope to emulate in my future projects.
Hope the deal announced here gives you the financial security you deserve and that caddy remains in the space for a long time.
Caddy is a really nice server but the documentation for v2 is kind of strange. Every documented config setting is for the new json format, but there is almost no information or examples for a complete json config. And all complete examples are with the old Caddyfile which has now no documentation anymore.
That's not true at all. There's a ton of documentation for the Caddyfile https://caddyserver.com/docs/caddyfile
Examples can be found on the wiki on the community forums (which is linked to right at the top of sidebar in the docs site): https://caddy.community/c/wiki/13
If you still need v1 documentation, you can download an archive of the old website here (linked in the bottom of the docs sidebar) https://caddyserver.com/caddy-v1-docs-archive.tar.gz but please upgrade to Caddy v2, it's better in every way.
Examples can be found on the wiki on the community forums (which is linked to right at the top of sidebar in the docs site): https://caddy.community/c/wiki/13
If you still need v1 documentation, you can download an archive of the old website here (linked in the bottom of the docs sidebar) https://caddyserver.com/caddy-v1-docs-archive.tar.gz but please upgrade to Caddy v2, it's better in every way.
I think there is a more positive interpretation of comments like GP regarding the v2 documentation. There might be content but is not discovered easily. I have experienced this myself, the structure of the docs, currently, is not structured in a way that makes it easy to find what you need.
A lot of the meat is interspersed in random replies to questions both in github issues and community posts. Also, I have the impression that some content is not accessible (linked?) from the side bar in the docs page but only through links from content pages. Most google and github search return content for v1, most tutorials online are for v1.
I don’t think the feedback was meant to detract from the effort put to document things, it just highlights that current documentation could be better organized.
A lot of the meat is interspersed in random replies to questions both in github issues and community posts. Also, I have the impression that some content is not accessible (linked?) from the side bar in the docs page but only through links from content pages. Most google and github search return content for v1, most tutorials online are for v1.
I don’t think the feedback was meant to detract from the effort put to document things, it just highlights that current documentation could be better organized.
> I have the impression that some content is not accessible (linked?) from the side bar in the docs page but only through links from content pages.
That may be true, but we have hundreds of content pages in the new docs. It's a bit unmanageable to have them all in a sidebar.
Not sure what we can do about search results and content on other sites, either, other than encouraging contributions to our wiki so people can find things easier.
That may be true, but we have hundreds of content pages in the new docs. It's a bit unmanageable to have them all in a sidebar.
Not sure what we can do about search results and content on other sites, either, other than encouraging contributions to our wiki so people can find things easier.
A belated congrats!
We love Caddy, especially for the read-friendly nature of Caddyfiles and the built-in LE. But, we do find the docs and plugin situations difficult enough for deeper customization + debugging that we still also use Nginx elsewhere, and are only now getting serious about a V1 -> V2 migration. The below are about our V1 docs experience and looking at V1 -> V2 migration two times and being scared off, and hopefully actually doing it the third time.
1. Docs:
-- Common full working configurations are unclear: Finding them requires Google searches hitting broken examples in support forums, when you are lucky that they exist. This is common stuff like proxying, auth API gates, etc. (There was a small V1 github repo that was helpful, it may exist for V2 as well now?)
-- The doc style seems to prioritize terseness vs. clarity. (Even in math, we know an error-correcting language uses repetition & spacing to provide value beyond what a minimal number of characters can do ;-))
-- Examples... aren't. Ex: They are generally 'out-of-context', so unclear how to put into a full working configuration, even at the syntax level
2. Plugins:
The philosophy of pushing basic capabilities to the community via plugins makes sense for a small-staffed effort, though like the JavaScript nodejs/npm situation, that causes its own problems. The above examples like auth are so basic that even if they're via the community, they're part of a migration of a real implementation, and even if the core is fine, they're central enough that they need to be great too: features, docs, etc. Node kind of got away with it b/c a few people took on big lifts for stuff like the HTTP libraries, and that was a big part of the success. Our earlier analysis of basic V2 plugins showed they were a WIP, and while we're now revisiting, it was disappointing to see V1 stopped.
Hope that helps! We are not paying users, but we do evangelize to federal + F500 IT types.
We love Caddy, especially for the read-friendly nature of Caddyfiles and the built-in LE. But, we do find the docs and plugin situations difficult enough for deeper customization + debugging that we still also use Nginx elsewhere, and are only now getting serious about a V1 -> V2 migration. The below are about our V1 docs experience and looking at V1 -> V2 migration two times and being scared off, and hopefully actually doing it the third time.
1. Docs:
-- Common full working configurations are unclear: Finding them requires Google searches hitting broken examples in support forums, when you are lucky that they exist. This is common stuff like proxying, auth API gates, etc. (There was a small V1 github repo that was helpful, it may exist for V2 as well now?)
-- The doc style seems to prioritize terseness vs. clarity. (Even in math, we know an error-correcting language uses repetition & spacing to provide value beyond what a minimal number of characters can do ;-))
-- Examples... aren't. Ex: They are generally 'out-of-context', so unclear how to put into a full working configuration, even at the syntax level
2. Plugins:
The philosophy of pushing basic capabilities to the community via plugins makes sense for a small-staffed effort, though like the JavaScript nodejs/npm situation, that causes its own problems. The above examples like auth are so basic that even if they're via the community, they're part of a migration of a real implementation, and even if the core is fine, they're central enough that they need to be great too: features, docs, etc. Node kind of got away with it b/c a few people took on big lifts for stuff like the HTTP libraries, and that was a big part of the success. Our earlier analysis of basic V2 plugins showed they were a WIP, and while we're now revisiting, it was disappointing to see V1 stopped.
Hope that helps! We are not paying users, but we do evangelize to federal + F500 IT types.
Great feedback, thanks.
Regarding full configurations, what do you want to have there? It seems infeasible to provide a full configuration that works for everyone, since everyone's sites and deployments and requirements are different, even if a little bit. Aren't there thousands, nay millions, of ways to configure any number of sites and services in any number of environments? I hesitate to get in the territory of "this is exactly how you do this, no need to read and learn how it works" -- because then we have a lot of uninformed, confused users (we learned this from experience in v1). I think our biggest mistake in v1 was making things too easy.
As for plugins, Caddy 2 is nearly infinitely extensible, and I myself can't commit to building everything that is needed... we definitely rely on the community to build what they need, and then share it. It worked in v1, I think it will work in v2, too! It will also happen much more quickly and probably be higher quality in the long run.
Regarding full configurations, what do you want to have there? It seems infeasible to provide a full configuration that works for everyone, since everyone's sites and deployments and requirements are different, even if a little bit. Aren't there thousands, nay millions, of ways to configure any number of sites and services in any number of environments? I hesitate to get in the territory of "this is exactly how you do this, no need to read and learn how it works" -- because then we have a lot of uninformed, confused users (we learned this from experience in v1). I think our biggest mistake in v1 was making things too easy.
As for plugins, Caddy 2 is nearly infinitely extensible, and I myself can't commit to building everything that is needed... we definitely rely on the community to build what they need, and then share it. It worked in v1, I think it will work in v2, too! It will also happen much more quickly and probably be higher quality in the long run.
Maybe as an exercise, try working backwards for some top 5 scenarios (reverse proxy, multi-domain, static server, bastion, ...), or better, record a session of someone trying it out for the ~first time. Ex: "I'd like to host multiple sites on one subdomain: that means reverse proxying several pages and doing an auth header check (ex: JWT)".
As a user, I'd check the tutorials + corresponding docs. It's tantalizingly close, but some quick gotchas already:
-- There is a reverse proxy tutorial... but it's too minimal. No multiple paths, route rewriting, ... . It does get you to the reverse proxy directive docs, which has more examples, and then another jump to matchers.
-- There is no auth tutorial section, which I would have thought would be somewhere in the ~top 5 scenarios. A search for 'jwt' gets me to the JWT plugin, but unclear what a sample config for a route would be, say for a boring Django / Rails / auth0 setup of "Authorization: Bearer ..." -> "/some/check/route": https://caddyserver.com/docs/modules/http.authentication.pro....
One of the toughest parts of writing is reading your own work :)
As a user, I'd check the tutorials + corresponding docs. It's tantalizingly close, but some quick gotchas already:
-- There is a reverse proxy tutorial... but it's too minimal. No multiple paths, route rewriting, ... . It does get you to the reverse proxy directive docs, which has more examples, and then another jump to matchers.
-- There is no auth tutorial section, which I would have thought would be somewhere in the ~top 5 scenarios. A search for 'jwt' gets me to the JWT plugin, but unclear what a sample config for a route would be, say for a boring Django / Rails / auth0 setup of "Authorization: Bearer ..." -> "/some/check/route": https://caddyserver.com/docs/modules/http.authentication.pro....
One of the toughest parts of writing is reading your own work :)
Good ideas, and maybe add some easy starters: This is how you use php‘s framework laravel, this is how you do reverse proxying to nodejs.
The crucial part for me would be that every of these examples will be done with the old Caddyfile and the new json format. With enough samples you would get a good feeling on how to transform these caddyfiles to the json format.
The crucial part for me would be that every of these examples will be done with the old Caddyfile and the new json format. With enough samples you would get a good feeling on how to transform these caddyfiles to the json format.
To be clear, you can still use the Caddyfile in v2, and frankly it's what I would recommend, especially for a Laravel app. It'll just be as simple as this:
example.com {
root * /var/www/public
encode gzip
php_fastcgi unix//var/run/php-fpm.sock
file_server
}
A lot of the "how to" stuff is moved into the wiki, which the community can edit directly: https://caddy.community/c/wiki/13
Including an article for how to write a JSON config from scratch: https://caddy.community/t/writing-a-caddy-json-config-from-s...
And using JSON config to only keep certificates renewed: https://caddy.community/t/using-caddy-to-keep-certificates-r...
If you need v1 docs, there's still a link to them at the bottom of our current docs' sidebar.
I recommend everyone start with the Getting Started guide, no matter how new or experienced you are: https://caddyserver.com/docs/getting-started
If you're coming from v1, we have an upgrade guide: https://caddyserver.com/docs/v2-upgrade
Including an article for how to write a JSON config from scratch: https://caddy.community/t/writing-a-caddy-json-config-from-s...
And using JSON config to only keep certificates renewed: https://caddy.community/t/using-caddy-to-keep-certificates-r...
If you need v1 docs, there's still a link to them at the bottom of our current docs' sidebar.
I recommend everyone start with the Getting Started guide, no matter how new or experienced you are: https://caddyserver.com/docs/getting-started
If you're coming from v1, we have an upgrade guide: https://caddyserver.com/docs/v2-upgrade
I really love your work, but in comparison to how easy v1 was to configure, the new JSON stuff is "here be dragons" level. For me at least.
This is, however, a nitpick in the grand scheme of things. Thanks for making caddy and keep up the great work!
This is, however, a nitpick in the grand scheme of things. Thanks for making caddy and keep up the great work!
Agree, migrating was very painful
It would be helpful to understand why you found that to be the case.
We get off-hand comments like this about the docs on occasion, and without explanation, we can't do anything to improve the docs to resolve the complaints.
We put in a ton of effort on the docs, and we think they're great. What are you missing? Did you spend the time going through and reading the docs?
We get off-hand comments like this about the docs on occasion, and without explanation, we can't do anything to improve the docs to resolve the complaints.
We put in a ton of effort on the docs, and we think they're great. What are you missing? Did you spend the time going through and reading the docs?
First, just gotta say, I love Caddy, and thanks to you, mholt, and the rest of the team for everything you do.
I'm actually a recent Caddy convert, and only picked it up after I saw the v2 GA announcement here on HN. I'm also not using it at large scale: it's just the frontend reverse proxy for my home infra, which is itself frontended by CloudFlare's strict-level DDoS protection/proxy.
I set everything up a few months ago, and my pain with the documentation was that it tended to only address the extremes of dead-simple Cadddyfile examples or very intricate JSON reference. Given that I was working with CloudFlare, thinks were a little more complicated: I had to setup my own Dockerfile to recompile against the externally-maintained CloudFlare module (which, btw, thank you to ever maintains the builder container for making that dead simple with Docker's copy feature). Then some more extra stuff in the Caddyfile to pass in the API key, as well as to work properly with a totally different cert sitting on the web server I was reverse proxying.
That being said, I came back this last weekend to fix up some other stuff, and it seemed like the docs were more complete in general. I found a lot of Caddyfile reference that I needed very easily. So either discoverability or content was improved, or I was just not acquainted enough with Caddy to find it last time (which is totally possible).
And just 2cents from a user who also PMs some OSS software: mad respect for being out here and asking these questions. I completely feel how hard it can be to get anyone to answer this in good faith, and the slow build of anxiety that comes in seeing vague complaints like this littered throughout the internet. Even if I know that they don't mean it personally, it can get me very worked up, especially after many years of reading it.
And yet, doing it repeatedly is the only way to know wtf to improve. I can completely relate with Caddy on the telemetry stuff too, God knows that's an even more difficult sell.
I'm actually a recent Caddy convert, and only picked it up after I saw the v2 GA announcement here on HN. I'm also not using it at large scale: it's just the frontend reverse proxy for my home infra, which is itself frontended by CloudFlare's strict-level DDoS protection/proxy.
I set everything up a few months ago, and my pain with the documentation was that it tended to only address the extremes of dead-simple Cadddyfile examples or very intricate JSON reference. Given that I was working with CloudFlare, thinks were a little more complicated: I had to setup my own Dockerfile to recompile against the externally-maintained CloudFlare module (which, btw, thank you to ever maintains the builder container for making that dead simple with Docker's copy feature). Then some more extra stuff in the Caddyfile to pass in the API key, as well as to work properly with a totally different cert sitting on the web server I was reverse proxying.
That being said, I came back this last weekend to fix up some other stuff, and it seemed like the docs were more complete in general. I found a lot of Caddyfile reference that I needed very easily. So either discoverability or content was improved, or I was just not acquainted enough with Caddy to find it last time (which is totally possible).
And just 2cents from a user who also PMs some OSS software: mad respect for being out here and asking these questions. I completely feel how hard it can be to get anyone to answer this in good faith, and the slow build of anxiety that comes in seeing vague complaints like this littered throughout the internet. Even if I know that they don't mean it personally, it can get me very worked up, especially after many years of reading it.
And yet, doing it repeatedly is the only way to know wtf to improve. I can completely relate with Caddy on the telemetry stuff too, God knows that's an even more difficult sell.
I've also seen the negative sentiment to the v2 docs. I've been hesitant to jump in on the community site because I've seen a lot of - very polite, like yours - RTFM responses, citing the work you've put in etc.
I am probably one of those people who would have flamed someone 20 years ago for posting a critique like this without _any_ time to help directly, but I'm not too proud to give you a "moron in a hurry" perspective, because I think it answers your question.
Firstly - maybe do nothing. This is just what losing your old users looks like. They make a lot of noise that things aren't the same, that they're lost, confused etc. and want you to sink a lot of effort into making them comfortable. It's probably not worth it! You know what your success metrics for Caddy look like - so if v2 is succeeding in terms of adoption etc. - just let users go, or trust that they will work it out eventually.
But as one of these muddled users from 5 years ago who has put v2 into production despite the confusion: the v1 docs were brilliant. They were written hand-in-hand with a piece of software that had a target user in mind, and was so clearly hungry for adoption. The Caddyfile remains excellent, an ambitious design to map out what admins truly wanted to configure in a web server, removing everything else.
I think that explains negative sentiment to the v2 docs - Caddy is not built around the Caddyfile any more. So the docs don't centre it, and so caddy doesn't look like it's designed to do the same things. With v1, I felt that as I understood the Caddyfile, I understood caddy, an important and magical new binary on my system. That was almost certainly a flattering lie, but it never faltered. Every experience I had with v1 backed it up.
The v2 docs make clear that the Caddyfile is _legacy_, and that my old understanding doesn't help. The "Getting started" guide introduce Caddy's config with a JSON config eight brackets deep. Eight! Then it tells you about the API that you might want to use to reconfigure it. Then it tells you about the Caddyfile, but makes clear that it's compiled to the "real" config, and that you'll miss some features in using it.
I briefly look for the JSON reference, and it's nothing like as simple as the Caddyfile. I dig 3 brackets down before to find the configuration for the HTTP server (wait, what, that's just a module now), and there's a lot of boilerplate in that. So there's this mental conflict as I read - the docs say that Caddyfile is _a_ valid way of configuring caddy, but it's clear I'm missing out a true understanding of the program which now has a lot of boilerplate. BOOOOO to boilerplate. Like caddy has spilled its guts into the JSON - the hardwired elegance is a bolt-on. I'm sure this is a lot like how v1 worked, except the v1 docs didn't want me to love its guts.
The v2 docs document Caddy very well, but they sugar-coat the effort of re-understanding a server that old users felt they understood before. It is just not as easy as it was (NB it is still quite easy).
I am happy I can continue using v2 because of the nearly-the-same Caddyfile, but at some point I will have to understand the JSON to really feel in control of my server - maybe that's only 2-3x more work than writing this comment has been :) but that's work the v1 docs never made me do.
I am probably one of those people who would have flamed someone 20 years ago for posting a critique like this without _any_ time to help directly, but I'm not too proud to give you a "moron in a hurry" perspective, because I think it answers your question.
Firstly - maybe do nothing. This is just what losing your old users looks like. They make a lot of noise that things aren't the same, that they're lost, confused etc. and want you to sink a lot of effort into making them comfortable. It's probably not worth it! You know what your success metrics for Caddy look like - so if v2 is succeeding in terms of adoption etc. - just let users go, or trust that they will work it out eventually.
But as one of these muddled users from 5 years ago who has put v2 into production despite the confusion: the v1 docs were brilliant. They were written hand-in-hand with a piece of software that had a target user in mind, and was so clearly hungry for adoption. The Caddyfile remains excellent, an ambitious design to map out what admins truly wanted to configure in a web server, removing everything else.
I think that explains negative sentiment to the v2 docs - Caddy is not built around the Caddyfile any more. So the docs don't centre it, and so caddy doesn't look like it's designed to do the same things. With v1, I felt that as I understood the Caddyfile, I understood caddy, an important and magical new binary on my system. That was almost certainly a flattering lie, but it never faltered. Every experience I had with v1 backed it up.
The v2 docs make clear that the Caddyfile is _legacy_, and that my old understanding doesn't help. The "Getting started" guide introduce Caddy's config with a JSON config eight brackets deep. Eight! Then it tells you about the API that you might want to use to reconfigure it. Then it tells you about the Caddyfile, but makes clear that it's compiled to the "real" config, and that you'll miss some features in using it.
I briefly look for the JSON reference, and it's nothing like as simple as the Caddyfile. I dig 3 brackets down before to find the configuration for the HTTP server (wait, what, that's just a module now), and there's a lot of boilerplate in that. So there's this mental conflict as I read - the docs say that Caddyfile is _a_ valid way of configuring caddy, but it's clear I'm missing out a true understanding of the program which now has a lot of boilerplate. BOOOOO to boilerplate. Like caddy has spilled its guts into the JSON - the hardwired elegance is a bolt-on. I'm sure this is a lot like how v1 worked, except the v1 docs didn't want me to love its guts.
The v2 docs document Caddy very well, but they sugar-coat the effort of re-understanding a server that old users felt they understood before. It is just not as easy as it was (NB it is still quite easy).
I am happy I can continue using v2 because of the nearly-the-same Caddyfile, but at some point I will have to understand the JSON to really feel in control of my server - maybe that's only 2-3x more work than writing this comment has been :) but that's work the v1 docs never made me do.
You're right about old users, we're not losing sleep over it, we just at least want to lend those users a hand to help them get over the hump to transition to v2. Generally, users should forget everything they knew about Caddy v1 and spend the time to learn Caddy v2 with fresh eyes.
I will say I'm probably the biggest champion of the Caddyfile config language right now, and it's definitely _not_ legacy. It's here to stay. It's just that the v1 Caddyfile hindered the underlying design of Caddy and made it too inflexible. In v1, the Caddyfile was the _only_ config language, and its syntax and design did not allow for flexibility.
For example, in Caddy v1, request matching was not a generalized concept, it was implemented per directive. Each directive had to do its own decisions whether it should apply on any given request, and parse the config for that, etc. In v2, request matching is generalized, and can apply to any directive that is an HTTP handler. Much easier to understand, and much more flexible, much more powerful.
It's true that in v2, the Caddyfile isn't the primary configuration language, but that doesn't mean it's not the users' primary configuration language. The Caddyfile is essentially a layer of magic that maps to the underlying JSON to make it easy to write configs easily and quickly.
Matt decided to explain upfront that JSON is the primary internal config language, because it's important to understanding how Caddy works. It's dangerous to have people run servers without understanding at least a few of the fundamental principles that make them run. That's the purpose of the Getting Started guide, to guide the user through the fundamentals of Caddy so they have a basis of understanding.
Too many people want to go fast and aren't willing to spend the time reading, which is frustrating. Running any kind of web server is a time investment.
I will say I'm probably the biggest champion of the Caddyfile config language right now, and it's definitely _not_ legacy. It's here to stay. It's just that the v1 Caddyfile hindered the underlying design of Caddy and made it too inflexible. In v1, the Caddyfile was the _only_ config language, and its syntax and design did not allow for flexibility.
For example, in Caddy v1, request matching was not a generalized concept, it was implemented per directive. Each directive had to do its own decisions whether it should apply on any given request, and parse the config for that, etc. In v2, request matching is generalized, and can apply to any directive that is an HTTP handler. Much easier to understand, and much more flexible, much more powerful.
It's true that in v2, the Caddyfile isn't the primary configuration language, but that doesn't mean it's not the users' primary configuration language. The Caddyfile is essentially a layer of magic that maps to the underlying JSON to make it easy to write configs easily and quickly.
Matt decided to explain upfront that JSON is the primary internal config language, because it's important to understanding how Caddy works. It's dangerous to have people run servers without understanding at least a few of the fundamental principles that make them run. That's the purpose of the Getting Started guide, to guide the user through the fundamentals of Caddy so they have a basis of understanding.
Too many people want to go fast and aren't willing to spend the time reading, which is frustrating. Running any kind of web server is a time investment.
Sorry. Did our best to make it straightforward. https://caddyserver.com/docs/v2-upgrade
At least it's just a one-time thing.
At least it's just a one-time thing.
I changed over months and months ago to v2. It was painful, but docs were being written at the time, and the community was able to help me with most of my problems. The one last problem I've not solved yet is having caddy 2 work with bitwarden whereby bitwarden's ssl does not conflict with caddy 2. I was unable to figure out how to work with it, so my bitwarden ssl expires every month or two and I have to manually update the ssl by bringing down my personal site for a couple of minutes.
Do you have a link? I'll take a look when I get a chance.
https://sethammons.com/posts/bitwarden_with_caddy/
Documented there; would super appreciate any feedback on improvements for sure!
Documented there; would super appreciate any feedback on improvements for sure!
Is there any reason you need to have bitwarden run its own TLS instead of letting Caddy terminate?
I could not find a setting to disable bitwarden running its own tls
Can you share what your setup is like? I have bitwarden_rs self-hosted with Caddy in the front doing TLS termination and proxying the request to Bitwarden_rs and haven't experienced any issues for more than a year and half now. There are many ways in how Caddy can be configured (e.g. maybe even just keeping the certs updated, but not serving any HTTP requests [0]). Feel free to drop a thread on the Caddy forum and we can help you out!
[0] https://caddy.community/t/using-caddy-to-keep-certificates-r...
[0] https://caddy.community/t/using-caddy-to-keep-certificates-r...
My setup if fully outlined here: https://sethammons.com/posts/bitwarden_with_caddy/
If I don't get any traction on help here, I'll be sure to jump over to the community posts. Thanks!
If I don't get any traction on help here, I'll be sure to jump over to the community posts. Thanks!
Bitwarden's docs say it's possible to bring your own certs[0]. The Bitwarden marketplace image on DigitalOcean asks whether you want it to manage its own certs or not. From minor googling, it seems you can change your mind later by modifying a yaml file[1]. HN threading isn't best format for support. If this still doesn't help, let's move the discussion elsewhere.
[0] https://bitwarden.com/help/article/install-on-premise/
[1] https://gist.github.com/kylerchin/00e6990706183ddb0e0e792a1c...
[0] https://bitwarden.com/help/article/install-on-premise/
[1] https://gist.github.com/kylerchin/00e6990706183ddb0e0e792a1c...
>Every documented config setting is for the new json format
I did my v2 migration this past weekend and for few minutes thought this as well.
I think part of the problem is that when you use the site search for some Directives all that comes up is a selection of the corresponding Module docs and not the Directive docs.
For example, if I search "reverse_proxy" I get links to pages like [0] but no link to [1].
If the search could prioritize exact-matches to document titles that may help.
[0] - https://caddyserver.com/docs/modules/http.reverse_proxy.sele...
[1] - https://caddyserver.com/docs/caddyfile/directives/reverse_pr...
I did my v2 migration this past weekend and for few minutes thought this as well.
I think part of the problem is that when you use the site search for some Directives all that comes up is a selection of the corresponding Module docs and not the Directive docs.
For example, if I search "reverse_proxy" I get links to pages like [0] but no link to [1].
If the search could prioritize exact-matches to document titles that may help.
[0] - https://caddyserver.com/docs/modules/http.reverse_proxy.sele...
[1] - https://caddyserver.com/docs/caddyfile/directives/reverse_pr...
Agree with this comment 10x. There is a disconnect on the config settings that needs to be resolved.
Care to elaborate? What issues are you talking about?
so is this an acqui-hire?
johnghanks(2)
Just wanted to say that I love CaddyServer. It is super easy to use with minimal boilerplate. The automatic https support it uses LetsEncrypt to acquire a cert for the domain it is hosting is awesome and one of my favorite features!
Congratulations on the acquisition!
Congratulations on the acquisition!
Thanks! It's great to hear the positive experiences too.
Ok.
1. It is now 404
2. Apliayer ( https://apilayer.com )
3. What has Ardanlabs got to do with Apilayer?
4. What is the relationship between Caddy, Ardanlabs, and Apilayer?
Edit: May be just change the link to
https://caddy.community/t/caddy-and-certmagic-have-new-owner...
1. It is now 404
2. Apliayer ( https://apilayer.com )
3. What has Ardanlabs got to do with Apilayer?
4. What is the relationship between Caddy, Ardanlabs, and Apilayer?
Edit: May be just change the link to
https://caddy.community/t/caddy-and-certmagic-have-new-owner...
1 - Ardan Labs changed the url to https://www.ardanlabs.com/news/2020/08/caddy-server-acquired...
2, 3 - Based on the Cruchbase page for Apilayer, they were acquired by Ardan Labs yestday.(?) https://www.crunchbase.com/organization/apilayer-ltd
Or maybe the two companies bought Caddy together? I'm not really sure. > Ardan Labs announces they have secured the acquisition of Caddy Server with Apilayer.
2, 3 - Based on the Cruchbase page for Apilayer, they were acquired by Ardan Labs yestday.(?) https://www.crunchbase.com/organization/apilayer-ltd
Or maybe the two companies bought Caddy together? I'm not really sure. > Ardan Labs announces they have secured the acquisition of Caddy Server with Apilayer.
The original url was put back
https://www.ardanlabs.com/news/2020/08/caddy-server-is-acqui...
Apilayer acquired Caddy only. This is a mistake by Crunchbase.
As a heavy Nginix user could someone shed some light on why Caddy is a better alternative? Serious replies only, please.
- Built-in ACME client, automated certificate management
- Simpler configuration language, the Caddyfile
- Single static binary, no external dependencies
- Built with Go, so memory safety is essentially solved
- Very pluggable if you need to add additional behaviour (simple Go module plugin system)
- Config API with graceful reloads
- Plenty more, just scroll through the homepage to get an idea: https://caddyserver.com/
- Simpler configuration language, the Caddyfile
- Single static binary, no external dependencies
- Built with Go, so memory safety is essentially solved
- Very pluggable if you need to add additional behaviour (simple Go module plugin system)
- Config API with graceful reloads
- Plenty more, just scroll through the homepage to get an idea: https://caddyserver.com/
First: Thanks for contributing to Caddy! I have not used it in production, but it has been nice for some small projects where I needed something fast and easy.
But, I do feel like in a discussion where you are making a direct comparison between a project you are a part of and a competing project, it is the fair thing to do to disclose that you are a project member.
I know you're not trying to hide it - I see you making comments elsewhere in here that reference it - but not everyone will necessarily see those, and people would probably like to know if they are reading a comparison written by someone who has a vested interest in the things being compared.
But, I do feel like in a discussion where you are making a direct comparison between a project you are a part of and a competing project, it is the fair thing to do to disclose that you are a project member.
I know you're not trying to hide it - I see you making comments elsewhere in here that reference it - but not everyone will necessarily see those, and people would probably like to know if they are reading a comparison written by someone who has a vested interest in the things being compared.
The parent comment asked why Caddy is better than Nginx but I'm not sure some of these are applicable.
> Built with Go, so memory safety is essentially solved
Has there been any memory safety issues with Nginx?
> Very pluggable if you need to add additional behaviour
Nginx is easily extendable and has far, far larger plugin ecosystem than Caddy.
> Config API with graceful reloads
So does nginx, with "nginx -s reload"
> Built with Go, so memory safety is essentially solved
Has there been any memory safety issues with Nginx?
> Very pluggable if you need to add additional behaviour
Nginx is easily extendable and has far, far larger plugin ecosystem than Caddy.
> Config API with graceful reloads
So does nginx, with "nginx -s reload"
> Has there been any memory safety issues with Nginx?
Yes, of course. For example, nginx uses openssl, so it was vulnerable to Heartbleed, something Caddy can never be vulnerable to. Part of the point of Caddy is to stop deploying C code to the edge.
> Nginx is easily extendable and has far, far larger plugin ecosystem than Caddy.
Nginx is also 4x older. I'd say for just a few years we're doing pretty good with our very young plugin ecosystem. A lot of this depends on the community. If you want it, make it so!
> So does nginx, with "nginx -s reload"
I think he was referring to a REST/JSON API that isn't unix-specific.
Yes, of course. For example, nginx uses openssl, so it was vulnerable to Heartbleed, something Caddy can never be vulnerable to. Part of the point of Caddy is to stop deploying C code to the edge.
> Nginx is easily extendable and has far, far larger plugin ecosystem than Caddy.
Nginx is also 4x older. I'd say for just a few years we're doing pretty good with our very young plugin ecosystem. A lot of this depends on the community. If you want it, make it so!
> So does nginx, with "nginx -s reload"
I think he was referring to a REST/JSON API that isn't unix-specific.
Good point about openssl!
> Nginx is also 4x older.
I know, but the GP claimed Caddy's plugin ecosystem was an advantage over Nginx, which just isn't true.
> I think he was referring to a REST/JSON API that isn't unix-specific.
Got it, thanks. Though I wonder how many people actually need a REST API for config reloads given practically everyone runs servers on Linux.
> Nginx is also 4x older.
I know, but the GP claimed Caddy's plugin ecosystem was an advantage over Nginx, which just isn't true.
> I think he was referring to a REST/JSON API that isn't unix-specific.
Got it, thanks. Though I wonder how many people actually need a REST API for config reloads given practically everyone runs servers on Linux.
You'd be surprised how helpful having a REST API for config reloads is when you're serving more than a simple static site.
In addition to OpenSSL's Heartbleed, nginx had its own functionally-identical "Heartbleed" bug in its header parsing. Exact same impact.
(I don't think anyone made a big deal about it at the time; I knew about it because our team at Matasano discovered it independently just an hour or two before someone else filed the bug).
(I don't think anyone made a big deal about it at the time; I knew about it because our team at Matasano discovered it independently just an hour or two before someone else filed the bug).
These 2:
- Built-in ACME client, automated certificate management
- Simpler configuration language, the Caddyfile
Are absolutely applicable and reasons that it's better. UX matters.
- Built-in ACME client, automated certificate management
- Simpler configuration language, the Caddyfile
Are absolutely applicable and reasons that it's better. UX matters.
I'd argue it's much easier to write Go plugins for Caddy than C plugins for nginx, and it's much easier to build. See the plugin docs here: https://caddyserver.com/docs/extending-caddy
I used it once for a little proof-of-concept where I needed quick turnaround. It was really easy to configure and had a bunch of features built-in that were convenient and saved a lot of time compared to alternatives.
I played with Caddy a lot in the v1 days and again recently with v2.1. I ended up not sticking with it since there's things I do with nginx that aren't easy to do with Caddy if you don't have extensive Go knowledge. I am tempted to give it an honest go again, though, and see what I/it can do.
As for Caddy advantages, I think it's really just about having a super easy to manage JSON or Caddyfile. In migrating a few of my nginx configs to Caddyfile, I was able to reduce line counts from dozens to 2-3. That's pretty impressive, tbh.
If you've been using nginx forever and have no issues with it...I don't see any valid reasons to move to Caddy.
As for Caddy advantages, I think it's really just about having a super easy to manage JSON or Caddyfile. In migrating a few of my nginx configs to Caddyfile, I was able to reduce line counts from dozens to 2-3. That's pretty impressive, tbh.
If you've been using nginx forever and have no issues with it...I don't see any valid reasons to move to Caddy.
The only out-of-box thing I sometimes miss, is "try-files-first" -- but I'll also say it probably is a bit of an anti-pattern (just have static files under another path/sub-domain - etc).
But it is something that nginx does have. That, and maybe some kind of "x-send-file" acelleration/support.
Ed: this is odd, I could've sworn it wasn't that long ago I looked for and even discussed try-files-first for v2 - but apparently it exists?
https://caddy.community/t/v2-try-file-server-first/6440/3
https://caddyserver.com/docs/caddyfile/directives/try_files#...
Ed2: I guess I was confusing it with x-send-file acelleration - which still appear to be a bit wip? :
https://caddy.community/t/caddy-2-x-sendfile-x-accel-support...
https://caddy.community/t/sendfile-x-accel-redirect-v1s-inte...
But it is something that nginx does have. That, and maybe some kind of "x-send-file" acelleration/support.
Ed: this is odd, I could've sworn it wasn't that long ago I looked for and even discussed try-files-first for v2 - but apparently it exists?
https://caddy.community/t/v2-try-file-server-first/6440/3
https://caddyserver.com/docs/caddyfile/directives/try_files#...
Ed2: I guess I was confusing it with x-send-file acelleration - which still appear to be a bit wip? :
https://caddy.community/t/caddy-2-x-sendfile-x-accel-support...
https://caddy.community/t/sendfile-x-accel-redirect-v1s-inte...
A production caddy config can be three lines or so.
It's a lot easier for simple things.
Being a single go binary means it "comes with" tls code (for better or worse). Makes it trivial to run a modern proxy on an old distro (say running some old application server that only speaks http, or worse, ancient ssl).
Uprades are quite easy too (drop in a new binary).
It can do many of the things nginx or apache can do, simpler, with less config (less to tune, less to audit).
It's a lot easier for simple things.
Being a single go binary means it "comes with" tls code (for better or worse). Makes it trivial to run a modern proxy on an old distro (say running some old application server that only speaks http, or worse, ancient ssl).
Uprades are quite easy too (drop in a new binary).
It can do many of the things nginx or apache can do, simpler, with less config (less to tune, less to audit).
It seems Ardan Labs changed the url to https://www.ardanlabs.com/news/2020/08/caddy-server-acquired...
The original URL was put back
https://www.ardanlabs.com/news/2020/08/caddy-server-is-acqui...
I talked to matt when Caddy 2 launched and was very helpful. Caddy is a great piece of software!
I must admit I saw this when it was first announced and I didn’t get why it was better but seeing it again and having more time on my hands I intend to experiment a bit further.
Congratulations to the author for their success - it is clear they’ve created a community of happy users and probably worked really hard to get here.
Congratulations to the author for their success - it is clear they’ve created a community of happy users and probably worked really hard to get here.
is there anything for caddy, like nginx nchan ?
Not currently, no. It shouldn't be too hard to implement a plugin that does something similar though! If there's an existing pubsub solution in golang, it could be integrated into Caddy.
Caddy is the best way to get junior devs up to speed. And the reverse proxy is amazing. And it is easy to know what caddy is doing compared to nginx etc
I'm also really happy that you improved startup time with 2.2.0rc1, because we had problems as our setup is massive (over 8000 domains and certificates). It took 17m previously when we redeployed the app for the pods to startup, now it takes ~30s which is quite ok as we also have autoscaling in place.
As of the docs, I also find it a bit confusing, coming from v1. :) I use Caddy for my personal stuff as well and it was quite a learning curve to get the same setup I had before work in v2, but as you said, it is one-time only so it is okay.
Keep up the great work!