HTTP 400 on caddy upgrade

hdf · June 29, 2025, 10:25am

1. The problem I’m having:

I’m trying to download a custom caddy from the server and I’m getting an error 400
custom caddy executable with:

GitHub - hslatman/caddy-crowdsec-bouncer: A Caddy module that blocks malicious traffic based on decisions made by CrowdSec.
GitHub - caddy-dns/cloudflare: Caddy module: dns.providers.cloudflare
GitHub - mholt/caddy-l4: Layer 4 (TCP/UDP) app for Caddy

2. Error messages and/or full log output:

root@caddy:~# caddy upgrade
2025/06/29 10:17:13.829 INFO   this executable will be replaced {"path": "/usr/bin/caddy.custom"}
2025/06/29 10:17:13.829 INFO   requesting build {"os": "linux", "arch": "amd64", "packages": ["github.com/hslatman/caddy-crowdsec-bouncer@v0.8.1", "github.com/caddy-dns/cloudflare@v0.0.0-20250214163716-188b4850c0f2", "github.com/mholt/caddy-l4@v0.0.0-20250124234235-87e3e5e2c7f9"]}
Error: download failed: download failed: HTTP 400: unable to fulfill download request (id=2c93dcf3-715f-49a3-b5eb-fd2bf228b0bb)

3. Caddy version:

v2.9.1 h1:OEYiZ7DbCzAWVb6TNEkjRcSCRGHVoZsJinoDR/n9oaY=

4. How I installed and ran Caddy:

a. System environment:

Debian 12, LXC, x64

5. Links to relevant resources:

It’s probably the same issue as Caddy Upgrade getting http 400
Do then need to build the executable myself, or can I expect this to be fixed?

Mohammed90 · June 29, 2025, 11:12pm

We’re going through growth pain with the build server. We’re considering a few plans, but nothing solid yet. Until we decide on the next action for the build server, build your own binaries using xcaddy or Docker.

Note that there’s an open proposal to remove the upgrade command.

github.com/caddyserver/caddy

proposal: remove `{add,remove}-package` and `upgrade` commands from core

opened 04:01PM - 10 May 25 UTC

mohammed90

discussion

The `{add,remove}-package` and `upgrade` commands were added to experiment with …providing users the ability to modify their executable as needed. Those commands call our build server, which operates the `/download` page, requesting a new binary with the requested modules. We typically see a huge uptick in requests to the build server soon after new releases which is assumed to be by users running `caddy upgrade`, though we cannot provide the data to back this claim. The build server presence is good for one-off requests where you need custom Caddy binary on the go, but it shouldn't be the main go-to source for CI/CD. However, we see references to it being part of CI/CD with periodic calls, which appears to be users' way of getting the latest version. This is an anti-pattern. I propose we remove these commands from core and make them plugins, mostly to discourage their use. For three reasons: 1. They rely on our build server and encourage using it, which comes without SLA. 2. They centralize distribution to us, which is contrary to how optimal package distribution operates. 3. Their presence encourages mutable infrastructure, which is discouraged due to drift, lack of attestation, lack of reproducibility The commands can be split into a plugin. I validated this with a PoC. The deprecation can be done in phases: - v2.11: remove the commands from core Caddy, and make it only available through custom build with the explicit request of the plugin - v2.12: full removal of the commands, plugin removed from site From v2.12 onward, users who desire those functions must develop their own plugin and point them at their own build server. That said, the recommendation has always been to rely on `xcaddy` rather than the build server. Previous conversation on the subject: - [State of add-packages and xcaddy](https://caddy.community/t/state-of-add-packages-and-xcaddy/30846/1)