4 ms·

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 p

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.

bauerd 10y ago
>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 https://forum.caddyserver.com/t/packaging-caddy/61
- singlow 10y ago
  Nginx had the same issue. Ubuntu ships 3 or 4 versions - nginx-light, nginx, nginx-full, nginx-extras - for different numbers of modules included.
  - finid 10y ago
    With dynamic modules support now in Nginx, that practice should end.
    - JdeBP 10y ago
      As Michael Lustfield said in Debian bug #790623 in October 2015.
- dozzie 10y ago
  > [...] 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.
- overcast 10y ago
  Yeh I've dug through that forum post a hundred times by now, the best option is the public script. https://getcaddy.com/ https://getcaddy.com/
- rrdharan 10y ago
  golang somewhat recently gained dynamic plugin support; wonder if that can be leveraged in Caddy? https://beta.golang.org/pkg/plugin/ https://beta.golang.org/pkg/plugin/
  - CSDude 10y ago
    Yes, but at the moment its only Linux
mholt 10y ago
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.
- overcast 10y ago
  awesome! Thanks for chiming in Matt.
- Walkman 10y ago
  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!

bauerd 10y ago

>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 https://forum.caddyserver.com/t/packaging-caddy/61

singlow 10y ago
Nginx had the same issue. Ubuntu ships 3 or 4 versions - nginx-light, nginx, nginx-full, nginx-extras - for different numbers of modules included.
- finid 10y ago
  With dynamic modules support now in Nginx, that practice should end.
  - JdeBP 10y ago
    As Michael Lustfield said in Debian bug #790623 in October 2015.
dozzie 10y ago
> [...] 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.
overcast 10y ago
Yeh I've dug through that forum post a hundred times by now, the best option is the public script. https://getcaddy.com/ https://getcaddy.com/
rrdharan 10y ago
golang somewhat recently gained dynamic plugin support; wonder if that can be leveraged in Caddy? https://beta.golang.org/pkg/plugin/ https://beta.golang.org/pkg/plugin/
- CSDude 10y ago
  Yes, but at the moment its only Linux

mholt 10y ago

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.

overcast 10y ago
awesome! Thanks for chiming in Matt.
Walkman 10y ago
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!