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!
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.
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.
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.
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
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...
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
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.
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.
>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.
I'm open to that! Do you know how to do that with Algolia's site search? I'm kind of new to it and a collaborator actually did most of the initial set up.
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.
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.
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 :)
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.
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:
> 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.
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?
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'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.
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 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.
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!
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.
Hi Matt and the team behind Caddy - I would say that we are very happy with it in MailerLite (https://www.mailerlite.com). We have a feature that is called landing domains, which gives the user possibility to use custom domains for their landing pages built through us. We also provide a free SSL certificate for it and previously have used nginx with some custom LetsEncrypt implementation. With Caddy and its ask point we just created a simple microservice which is hit each time there is a request to Caddy to issue the certificate, returns status 200, and we are good to go. It has been marvellous to use in our k8s setup with Redis plugin.
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.
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.
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.
Even if it's not automatically generated, Crunchbase is (or was?) a crowdsourced wiki, and one of the worst ones at that, with next to no quality control and moderation.
> 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.
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'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
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.
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.
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?
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).
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.
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."
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?
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)
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.
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.
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.
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!
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.
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
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!
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.
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.
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.
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!