This doesn’t scale well… It works for small numbers of plugins, but after a while it’s just unsustainably bloated.
1 Like
That’s true, but I don’t know if the goal of the project is to have many-many plugins, or just a reasonable set. Nor do I know how much “bloat” is caused by a given number of projects, with Go being so memory efficient anyway.
@andyjeffries I’d venture the goal of Caddy is to have a plugin for any functionality a user may wish to add. I think it’s a bad idea to lock ourselves into an inherently broken infrastructure (i.e. one we know doesn’t scale appreciably).
I spent some time brainstorming something similar to the Debian popularity contest, but that comes with it’s own set of maintainability issues. I honestly believe having a tool responsible for automating the management of your Caddy installation is the lowest-friction way to handle the issue.
For what it’s worth, starting with Caddy 0.9, plugins will offer to do a lot more than just act as directives. They can change how the Caddyfile is loaded, they can even replace the HTTP server. And with time they will be able to do more, like add hooks to the API, etc.
Thanks for chiming in Cyril! We’ll keep that in mind as we go forward, once we decide how and what we want to do. 
1 Like
I used this simple command line (https://getcaddy.com | bash) on a CentOS server and was very pleased withe result. In a matter of seconds, I had the right build, installed at the right place and I just had to caddy my folder to launch the server.
Very impressed with this process and I don’t see why I would need more. Even on my Mac, I first installed Caddy with Homebrew, but I think this method is better. 
2 Likes
Just started thinking about how to install Caddy on a production server and I’d like to throw one other possibility into the mix: A Snap package.
Although it started out as Ubuntu only it looks like snapd will see widespread adoption on other Linux distros and it seems to be more suited to golang’s all-in-one-binary approach. I’m planning on taking a closer look at this over the next few evenings.
As for plugins, Nginx has exactly the same problem does it not? Build time options only. IIRC on Ubuntu 16.04 distro Nginx packages the approach is to supply three packages. A minimal (no plugins), common (most common plugins) and full (all the plugins). Something worth considering for Caddy packages.
1 Like
Packaging is absolutely necessary, and I’ve had multiple people (and our company) refuse to use Caddy simply because updating it doubles the effort: You have one way to update all packages in your entire system and another way to update just caddy.
Even for myself, and even though I love automatic TLS, I found myself just now using nginx because I didn’t want to go through yet another “download caddy, customize the systemd file, create the /etc/caddy dir, sysctl daemon-reload, sysctl enable, repeat regularly or get pwned” cycle.
If you mean for Caddy to be used in production, it needs packages. I know that it’s really hard to add packages with plugins, but don’t let perfect be the enemy of good.
5 Likes
Stavros is 100% correct. With packaging for Debian- and Red Hat-derived distros (i.e. apt and yum), Caddy has a chance. Without packaging, once nginx/Apache/etc build in ACME cilents, Caddy becomes rather less interesting.
3 Likes
We could consider that, but deciding what is “common” seems tricky – at both technical and social levels. In order to avoid conflict, we’d need a concrete way to define “common” – what is that definition? And why not just build “common” plugins into the standard builds in the first place, if they’re so common?
Or they’re not “so” common, just “sort of” common. But what does that mean exactly?
@robertp @Stavros That’s fine, we understand the importance to some of packaging Caddy; but what do you have to offer by way of solutions for this free-to-use-totally-volunteer project? 
1 Like
Landed here doing a search for a Yum repo for Caddy. I checked the plugins, I don’t want any. I just want a solid, easy to use http server that supports lets encrypt out of the box. And I want to get security updates like I do for every thing else instead of having to periodically check for updates myself, and install.
Use case: I’m setting up a demo server for an open source project. I’ll probably do the extra effort of letsencrypt with nginx, cause then I can forget about it and let the package manager do it things. Otherwise I think this is a great project!
Interesting! So you also want auto-updates in production? That scares most people…
I wouldn’t exactly say that… I never run yum automatically, and often make use of --enablerepo, --disablerepo. And I’m small, I don’t have a provisioning system, etc. I just want to install Caddy, and get updates in the way thats consistent with everything else on my server.
1 Like
Okay, gotcha. So you still run updates yourself.
Yes. I’m not in ops, or even dev-ops. So when I want to put out a demo, I want it to be easy and quick.
I already build nightly RPMs of various other things, no reason why I couldn’t do it myself, and likely will cause I absolutely hate the dance of configuring nginx. Just wanted to add my voice into the “for a repo” crowd with my reasoning.
1 Like
So, I am as late as it is possible to be to this conversation.
Some time ago I packaged caddy as an experiment Building a caddy PPA it was a pain (packages suck like that for the packager) then went silent for some time due to my current work project being on a crazy race for a release, now I have time back and took time to “automate” the way caddy is built for that ppa.
My current painpoint is, building a Tag of caddy is nearly impossible without some guesswork because there is neither vendoring nor godeps that I can see.
The ppa is currently up and features systemd files and upstart files so everybody can get it running with minimal effort.
The .deb only builds for trusty, xenial an yakkety since it requires go 1.6 not available in every distro version but it is not a real issue since the 3 .debs end up being the same as the main thing there is the binary which is just the same for every distro.
I know .deb files (or any distro for that matter) lower the barrier for certain types of users so I find certain value in them.
I am now building also a snap package that has the binary for now and soon, when I discover how to, will also have the systemd magic included.
Needless to say that everyone that wants to collaborate on it is more than welcome 
The only thing I am still missing is, I intend to bundle all the “plugins” but I have no clue on how to build caddy with the plugins so if anyone can point me in the right direction that would be awesome.
2 Likes
Love @abiosoft’s docker solution for plugins, as easy as:
docker build -t caddy --build-arg plugins=multipass https://github.com/abiosoft/caddy-docker.git#:php
I wont docker build into a package, I thought plugins where just something you would build into caddy as part of the static go build.
There must be other way to bundle that which doesn’t require docker. (tx for the answer though)
2 Likes
All you have to do is add the import for each plugin you want to plug in in run.go (although you could technically plug them in anywhere between main() and there).
Eventually we’ll probably have a tool that does this for you (I’ve posted a proposal for it in these forums already) but it’s not ready yet.
1 Like
If we ship Caddy via an RPM, does that mean it gets built from source, or how does that work?
And would it be a problem, given that Red Hat, for example, modifies Go crypto code: https://twitter.com/kennwhite/status/793060823388127232 ?