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