Caddy version 1 end of life date

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. :slight_smile: 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! :grinning:

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.

2 Likes

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.

1 Like

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”.

@danb35

If we’re counting, Caddy 2 has more features than Caddy 1.

Like Francis said, Caddy 1 never had the DNS plugins included either. You have to build from source. This is an open source project – not paid, plushy, proprietary software – so is that so surprising?

Is it too hard to build an open source project from source? Especially one written in Go? With tools like xcaddy available? You get what you pay for. We’ll get around to a shiny new build server when we have the chance, probably.

Anyway, would you like a refund?

2 Likes

When a great deal of open source software–including the previous stable release of this software–is widely available as binary packages, yeah, it kind of is.

I don’t doubt that I can get it up and running myself, but that isn’t really the point. I’ve written a number of guides (e.g., Reverse Proxy using Caddy (with optional automatic TLS) - How-to - FreeNAS Community, Firefly III Personal Finance Manager in a jail - How-to - FreeNAS Community) and scripts (e.g., GitHub - danb35/freenas-iocage-nextcloud: Script to create an iocage jail on FreeNAS for the latest Nextcloud 25 release, including Caddy, MariaDB or PostgreSQL, and Let's Encrypt, GitHub - danb35/freenas-iocage-heimdall: Script to install Heimdall Dashboard in a FreeNAS iocage jail) to set up jails on FreeNAS to do various things with Caddy, and try to dumb it down as much as possible, to be usable by as wide an audience as possible. All of them rely on getcaddy.com at least for cases requiring DNS validation (the Nextcloud script uses it for everything).

Obviously all the Caddyfiles need to be rewritten from scratch anyway. But it sounds like the scope of the work has expanded to include installing a build environment and building Caddy, documenting that as clearly as possible, and incorporating that in the scripts. None of that’s impossible, of course. Whether it’s worth it is something I’ll have to think about.

You know that we have dozens of binary packages available through our GitHub releases and our download page links to several distributions that are pre-built and ready-to-go, right?

Virtually no other open source projects let you make custom builds of the open source software with a few clicks. We’re really lucky to have had it for v1, and as time and other constraints allow, we might get it for v2 eventually – I’m the only one working full-time on this project currently. It took Caddy 1 several years to get there, Caddy 2 has moved much quicker.

It’d be a good idea to update those, since getcaddy.com only ships v1 and if we keep using it will be upgraded to v2 soon. Our website is not a package manager though, and we don’t recommend it for long-term, unmaintained installations – use a proper package manager that comes with your distro instead. (And if one doesn’t exist, then help us make one for your distro.)

That’s… normal… for pretty much all open source projects that you customize. :man_shrugging:

You could always just build it once and then ship that binary to your users yourself, rather than having all of them build the same thing from source.

1 Like

Just look at all the installation methods we have here:

We didn’t have any of those for v1.

The FUD in this thread is exhausting.

@matt @francislavoie

Caddy is an amazing product. As an enthusiast, I don’t feel it’s wise spending my time learning Apache or NginX when I could better spend my time learning about other aspects of technology that I would rather devote my time to. Caddy has made this possible for me. Caddy V2 is the next step in the evolutionary chain.

@danb35 is a highly respected and influential member of the FreeNAS Community. He has also almost single-handedly been the spokesperson for Caddy to the FreeNAS Community. Several of the most popular resources he has provided to the community are built with Caddy V1 being a key component. The resources are in widespread use, both in depth and spread, from simple to enterprise applications.

Caddy V2 presents some challenges for the FreeNAS and FreeBSD communities, which, while not insurmountable, still need to be carefully considered from those communities’ perspectives. The main concerns with V2 for these communities are:

  1. Compared to V1, the perception, whether true or not, is that V2 still isn’t feature-complete, particularly concerning DNS validation for certs.

  2. V2 is incompatible with V1. There are very good reasons for the change, but the fact remains that Caddyfile backward compatibility is virtually nonexistent.

  3. While a FreeBSD executable is available, there is as yet no FreeBSD pkg or port for it.

  4. Individuals may be willing to readily embrace a .0.0 version of any major software. However, where resources built on Caddy are being used by significant cross-sections of communities, the risks of adopting a .0 release are magnified considerably.

The support that the Caddy team are providing to stakeholders for the transition from V1 to V2 is tremendous. Each side has valid concerns and each side needs to be empathetic to the views of the other side, Individuals can traverse any one or all of the issues above relatively quickly and with limited risk. However, individuals who are here as advocates for a much larger group don’t have the same luxury as the stakes are much higher for the groups they represent.

There’s a lot to be taken away and reflected on by both sides on this transition from V1 to V2. Hopefully, the learnings will be useful for making the transition from Caddy V2 to V3 even smoother when that eventually comes around.

2 Likes