Congratulations on the release of Caddy 2 and thanks for all your hard work! I just wanted to check though how long Caddy 1 will continue to receive security fixes.
We’ve got a lot of IT upgrades coming up, and ideally we’d want to fit the Caddy migration into that. We can decommission the old system with Caddy 1, and set up the new system with Caddy 2 right from the beginning. If this is going to leave us exposed, though, we need to do something straight away on the old system.
First off Caddy is not even released. Second per mholt plugins will not even be given attention until it is. Given that I have yet to get caddy 2 going with route53 (basically all dns plugins at this point are not supported among pretty much all the rest of third party ones). C2 doesn’t even work with plugins that are are supposed to be part of the core (e.g. yaml adpater). Caddy 1 needs to live until Caddy 2 if fully ready for production (most of the old plugins working) and then some to give everyone time to migrate.
I have to say I was a bit irked when this red warning first appeared. I then made sure I had binaries with the needed plugins and architectures squired away.
How about a yellow one instead encouraging people to begin the migration process or at least check caddy2 out. You can make it red (with end date) when C2 is really ready for end user production. Or for that matter just leave it up under a different subdomain for archival purposes.
I don’t see ever using apache/inginx again so irking me did make me run away. You don’t have to support C1 anymore but you don’t have to take down the way to make C1 binaries.
Yes it is!
We never said the yaml adapter would be part of the core.
DNS plugins are still a work-in-progress and a huge undertaking.
Please read the following thread:
Welcome @PeteX - thanks for joining.
I don’t have a hard timeline in mind, but probably not past this year. And it’d be security fixes only. Any such releases would just be posted to GitHub, as our v1 website is expensive (maintenance-wise) to keep up so that’ll be coming down earlier.
So if you watch GitHub releases for v1.x tags you’d probably find what you need there.
Sounds good, I’d recommend upgrading to Caddy 2 soon regardless of the v1 lifetime. Caddy 2 has important bug fixes that are too involved to go back and fix in Caddy 1. (Doing so would mostly involve a rewrite, which is… what v2 is.)
@dkebler Thanks for chiming in, but can we try to be helpful to our guests please? 
That’s not true actually, all 75+ DNS providers are supported today:
Thanks @matt, if we’ve got until the end of the year that should be plenty of time.
To clarify, that’s an upper bound.
Okay I understand. I realise that it will require some thought, but it would be helpful to know a firm date once you’ve decided on one yourself. We don’t want to migrate our old system if we don’t have to, but it’s also very important that we aren’t exposing unmaintained software to the internet.
Of course I’m very much aware that we’re not paying for Caddy. I’m grateful for your work and whatever you decide with regard to end-of-life, we’ll make it work.
Well, then upgrade. v1 is unmaintained. It is no longer being developed. It will get little security patches if they are critical for the near-future, but that’s it.
v2 fixes some important bugs in v1 that can’t be fixed in v1.
So, that is my recommendation. Don’t delay – upgrade.
It depends what you mean by unmaintained. We can accept that it’s not being actively developed, and that it’s not receiving fixes for ordinary bugs. (We haven’t encountered any bugs that cause us problems.) It’s security that’s important.
We’re certainly not going to delay unnecessarily, but we’d like to plan it and fit it in with other projects, rather than doing it as an emergency thing. I expect we will be finished by the end of July, in reality. Do you think we’re safe until then?
Yeah, end of July is a safe bet. After July I’m not sure though.
That’s very helpful, thank you! 
Is this true with the binary I can download from Release v2.0.0 · caddyserver/caddy · GitHub, or do I need to build my own copy from source to do this?
Yes, you need to build Caddy with the plugin of your choice for this. See the guide here:
That’s what I thought. So it is as @dkebler said, Caddy1 is being killed off (on a very accelerated schedule) in favor of a Caddy2 that isn’t feature-complete.
Caddy v1 never included DNS plugins by default either. There’s no difference here.
But there is, and a critical one too–until they shut it down, I can download a binary of Caddy1 with whatever plugins I want using getcaddy.com. I’m not aware of anything comparable (perhaps it’s in the works?) for Caddy2.
Yeah, it’s in the works. What you might not realize is that that service for Caddy v1 is backed by a build server. So every time you’re downloading a binary with those plugins, a server is making a custom build of Caddy for you on the fly (or if there’s already an cached build with the exact set of plugins you need, it gives you that).
Building and maintaining a build server isn’t a trivial thing. There’s a not insignificant cost to running it. Caddy v2 just came out, we haven’t had time to build that out yet. It’ll come. If you rely on that, please consider sponsoring the project so the costs can be offset.
If you don’t want to rent a build server, this would be an ideal case for serverless. You could put all the build logic in a container and deploy it to Cloud Run. You would keep cached builds in cloud storage. When a user request arrives, the container builds the requested configuration if necessary, then directs the user to the appropriate cloud storage location.
Yes, I was aware of that, and at least roughly aware of how it worked.
But yet we’re being told up-topic that there are no promises of even major security updates or build server availability more than two months from now. And Matt’s rolling his eyes when I call that “a very accelerated schedule”.
