I cannot use software that require me to go to each softwares homepage to check for security updates, or do custom system scripts every time I want to deploy them. Package managers are there for a reason, and I can’t believe people are seriously regarding them as unnecessary. For your own hobby server perhaps, but try automating across a handful…
5 Likes
Do you have a solution for the problems we’ve raised here?
I do not have a solution. But then again, my problem was not with the fact that providing a package has proved hard due to the architecture of the project and/or Go as a language. My problem was with the fact that people actually argued that software packaging is unnecessary in a production environment.
That there is no easy solution does not mean it isn’t needed.
I don’t think anyone here has a problem with distro packages. Someone mentioned that prod users should be on Docker, which is one opinion on the matter. But I think the general attitude of this thread has quite clearly been, “OK, so how do we want to make it happen?”
Anyway, is there any reason we couldn’t look at starting with some kind of caddy-core package with just the HTTP server? Regardless of what we’d put package as caddy, whether or not we package some kind of caddy-full etc., I’d assume having a slim caddy-core package with no plugins makes sense.
4 Likes
Yeah, the more I think about it, the more I figure that any package we ship for distros would be just the http server and the standard directives.
5 Likes
@matt hey, would it be too much to ask to have a branch on github.com/mholt/caddy containing a copy of the latest tag with all the plugins enabled? that would make the process of snapping it (and the ppa to some extent) much easier.
The alternative is for me to write a sizeable amount of code 
so I would really appreciate it, I could very well be the one to maintain it if needed.
1 Like
I’m sorry, but I’m not going to do that. I think those kinds of customizations are best left outside of the core Caddy repo.
well turns out snapcraft allowed me to “lie” to it and I am now using my own repo for it 
so new snap and ppa availables with php and cors plugin support.
My personal opinion is, that, at this point, it’s much, much more important to get a quick solution that will work for 99% of people out than obsess about getting one that works for everyone. “Perfect is the enemy of the State” and all that.
Would it be possible to get a core Caddy executable into a repository (with some basic config and systemd service)? As it stands, all the ops people in the world say “if it can’t be updated along with other packages, it doesn’t go on the servers”, which is greatly hindering Caddy’s expansion.
I think it would be a strict improvement if core Caddy were put in a repository and this thread changed from “how do we package Caddy?” to “how do we package Caddy plugins?”. That would also be a lot less urgent.
4 Likes
I’m down for that. Do we want to wait for Caddy to be 1.0 first?
1 Like
I don’t see any need. It’s quite stable, as far as I can tell, at 0.9.4. Those who really want to wait until the 1.0 release can just not install it until then.
Okay. Sweet. How do we do it? I’ve never done this before.
For Ubuntu/Debian, the easiest way would probably be to create a PPA that users can add to their repository list. Getting into the Ubuntu main repository would probably be a long and painful process. Worse for Debian, naturally.
https://help.launchpad.net/Packaging/PPA
Launchpad is a Canonical service. Alternately you could host your repo at caddyserver.com, but it’s a bit more involved again: DebianRepository/Setup - Debian Wiki
I’m similarly inexperienced with packaging, though, so anyone who has experience - or even better, would be willing to help maintain the Caddy packages - I imagine they’d be very welcome.
1 Like
It might be useful to involve @perrito666 here, as he already started doing this a while ago:
https://github.com/mholt/caddy/issues/832
https://code.launchpad.net/~hduran-8/+archive/ubuntu/caddy
The necessary init system files (such as systemd) are already in the caddy repo:
2 Likes
Whats the current state of this issue? For now I can’t use Caddy in production due to the issues mentioned above. I’m not able to periodically check for new versions or security fixes and update caddy by myself for every new version. Thats the job of a packaging tool. For the plugin problem I suggest to create e.g. three versions:
- caddy (with basic plugins)
- caddy-minmal (without-plugins)
- caddy-full (with (allmost?) all plugins)
I think this could be a good starting point. Its not always necessary to custom build your Caddy if you only what a simple webserver. This should include a systemd unit and a default configuration file at e.g. /etc/caddy/Caddyfile. Version 0.9.5 was released over a moth ago but is missing in the unofficial PPA. It should not be to hard to automatically build these packages on new releases.
2 Likes
I realize this is frustrating for some sysadmins, but I have no intention of official Caddy packages until version 1.0… would rather focus on dev until then. Hope that’s okay. 
Caddy’s situation is a little bit unique. A packaging tool doesn’t satisfy a few of the requirements I have for automatic updates to Caddy, for instance, knowing the cipher suites supported by clients that connect to it. I also don’t like the idea of Caddy being crippled by a distro’s packaging policies and timelines.
For the plugin problem I suggest to create e.g. three versions:
- caddy (with basic plugins)
- caddy-minmal (without-plugins)
- caddy-full (with (allmost?) all plugins)
What are “basic” plugins?
Caddy without plugins is definitely a likely possibility.
You hesitate to recommend Caddy with all plugins - why is that?
Regardless, I don’t think we will offer Caddy with all plugins, especially not for automated deployments: this is a significant security problem. Because third party Caddy plugins are not vetted by the Caddy maintainers, anyone in the world would have a free ticket to run any code they want on your server at the next auto-update. At least when you manually select plugins, you give explicit permission for those authors to run their code on your machine, indicating that you trust them.
5 Likes
found my way here because as I’m deploying to production I realized I hadn’t installed on dev using a package. so I went looking for one and found none, just this thread.
forgive my naïveté but would it be so difficult for caddy to just do a listing on a directory and load any plugins it found there? then there could be a package caddy and another package caddy-cors that would require caddy and install only the cors plugin
This involves compiling Caddy. Not a big deal, it only takes 1-2 seconds (more with more plugins), but it requires you have Go installed. In essence, you’ve basically re-invited the GOPATH. 
so your package declares a dependency on the Go package and does the compilation. when a plugin package is installed, the install scripts re-compile Caddy with the new configuration
I’m with you, but I think its much better than nothing. I know the problems with distro’s packaging policies and timelines, for me its okay if there is a official Caddy apt repository I can add into my sources.list.
I just mentioned this to suggest caddy-minmal (for me it would be with minify)
You explained a good reason