Hacker News Reader

Comment by overcast | Hacker News Reader

So far I'm loving Caddy. Super simple to configure, and the auto management of SSL certificates is magical. However, for all of the simplicity, they are still pretty resistant to properly packaging it up in the repositories. By far the longest part of getting it running, is the stupid manual configuration of launch daemons, working directories, and permissions. For software that prides itself on dead simple management, the basics of getting it into a package manager should not even be a discussion.

With that said, I 100% moved all of my sites from Nginx to Caddy after the config file setup is around three lines per site.

View on HN

Of the 5 announcements we made yesterday, milestones for 0.11, 0.12, and 1.0 was one of them (and their details will be published to GitHub soon): one of the main purposes of 1.0 being stable is so that we can find ways to distribute Caddy better for people who want to use package managers. I know holding out isn't a popular decision but we really want to make sure we get it right given Caddy's unique needs with regards to plugins.

awesome! Thanks for chiming in Matt.

That's very nice to hear! I prefer this "make it great and release when it's perfect" attitude because it means way better quality and care I can rely on for the long term. Thanks for making Caddy, I'm pretty sure I will use it at one point!

>the basics of getting it into a package manager should not even be a discussion.

Last time I looked into it, their problem was that Caddy plugins must be configured at compile-time, because runtime plugins seem to be hard to do with Golang (besides RPC). Because there's a handful of Caddy plugins, they'd either have to provide a slim package with no plugins, or ship with all or only some blessed plugins. Obviously all approaches have drawbacks … they discussed the option of shipping their own package manager for Caddy plugins, too (shudder).

See: https://forum.caddyserver.com/t/packaging-caddy/61

Nginx had the same issue. Ubuntu ships 3 or 4 versions - nginx-light, nginx, nginx-full, nginx-extras - for different numbers of modules included.

With dynamic modules support now in Nginx, that practice should end.

As Michael Lustfield said in Debian bug #790623 in October 2015.

> [...] their problem was that Caddy plugins must be configured at compile-time, because runtime plugins seem to be hard to do with Golang [...] they'd either have to provide a slim package with no plugins, or ship with all or only some blessed plugins.

Or ship the source in the package and build the target binary in the post-install. Or do what Debian does with Exim and nginx: provide several packages, each with different set of plugins compiled in. And these are just ideas from top of my head.

Yeh I've dug through that forum post a hundred times by now, the best option is the public script. https://getcaddy.com/

golang somewhat recently gained dynamic plugin support; wonder if that can be leveraged in Caddy?

https://beta.golang.org/pkg/plugin/

Yes, but at the moment its only Linux

Reply on news.ycombinator.com