4 ms·

Hm, yeah I hope so too :/ Been using Caddy in prod for a year now, this issue, rare as it may be, could single-handedly get me back on nginx. Having the server

Hm, yeah I hope so too :/ Been using Caddy in prod for a year now, this issue, rare as it may be, could single-handedly get me back on nginx. Having the server be unable to start through circumstances outside of the system's control is just such a huge no.

danielbln 9y ago
Same here, was very pleased with Caddy so far, but it being tightly coupled to LE being up, despite having certs cached is a no-go for our production systems and if this stays like that, would make me go back to nginx for the services I've used caddy so far. edit: looks like the dev added a fix to only refuse the start if the cached certs are dangerously close to expire. that satisfies me and I'll be continue to be using caddy.
- discreditable 9y ago
  Call me crazy but I think it's a little silly for an https server to refuse to start just because its certificate is invalid. I recognize that some folks might like that failure mode however.
enimodas 9y ago
Why did you switch away from nginx?
- scrollaway 9y ago
  Not having to deal with certificate renewal is a big deal.
  - fb03 9y ago
    I am running nginx reverse-proxying to a python API right now. Dealing with certificate renewal is a matter of running a daily cronjob issuing 'certbot renew'. If it works it replaces the fullchain.pem certificate, and that's it, easy peasy. Am I missing something?
    - scrollaway 9y ago
      And by running Caddy instead, I have one less piece to monitor and worry about. The way Let's Encrypt works, it makes a lot of sense to have the functionality be part of the web server.
      - JshWright 9y ago
        > The way Let's Encrypt works, it makes a lot of sense to have the functionality be part of the web server. That's an odd thing to say in this particular conversation thread... Why would you want to tightly couple your webserver to the availability of another service provider?
        scrollaway 9y ago
        It's not tightly coupled any more than it would be with certbot. The issue I filed is an issue because it's unexpected behaviour (despite early closure, it has actually now been fixed).
      - stephenr 9y ago
        > by running Caddy instead, I have one less piece to monitor and worry about No, with Caddy you have several vaguely related pieces glued together with superglue. > The way Let's Encrypt works, it makes a lot of sense to have the functionality be part of the web server. I think this thread is pretty much proof that that approach will bite you in the ass.
        scrollaway 9y ago
        > I think this thread is pretty much proof that that approach will bite you in the ass. What bit me here is the fact that I'm running alpha software instead of a battle-tested web server; I'm doing so willingly, with full awareness of the risks that that entails. Drawing the conclusion you did from the variables at play is shortsighted. If anything bites people in the ass, it's prejudice and shortsightedness. I wouldn't want you handling my ops/infrastructure.
  - majewsky 9y ago
    Is it? I spent one day getting certbot up and running, and ever since then it's been pretty much a done deal.
    - manigandham 9y ago
      That's 1 day that I didn't have to spend, even better when dealing with many instances.
      - majewsky 9y ago
        Okay, I agree, with two caveats: 1. The cost does not scale with the amount of instances since it is the one-time cost to create the configuration package. 2. If you decide to go for Caddy instead, you'll have to spend the same time, if not more, learning Caddy.
- eridius 9y ago
  I switched from nginx to caddy for my (extremely low-traffic) server because I was tired of having to copy & paste a bunch of SSL setup any time I was configuring a new domain.
GiorgioG 9y ago
I'm done with Caddy - this is security theater at its finest. Back to nginx we go. Why did I pick Caddy, because it was simple/easy/fast-to-setup.
- e_d_e_v 9y ago
  I moved from Caddy to Traefik (https://traefik.io/ https://traefik.io/) several months ago. Granted, nginx has years (decades?) on some of these newer webserver/reverse-proxies, but I have been happy with all the built in niceties of traefik so far (single binary, etc), and haven't really experienced any negatives.
  - mholt 9y ago
    You're not bit by this? https://github.com/containous/traefik/issues/791 https://github.com/containous/traefik/issues/791
    - e_d_e_v 9y ago
      Nope.

danielbln 9y ago

Same here, was very pleased with Caddy so far, but it being tightly coupled to LE being up, despite having certs cached is a no-go for our production systems and if this stays like that, would make me go back to nginx for the services I've used caddy so far. edit: looks like the dev added a fix to only refuse the start if the cached certs are dangerously close to expire. that satisfies me and I'll be continue to be using caddy.

discreditable 9y ago
Call me crazy but I think it's a little silly for an https server to refuse to start just because its certificate is invalid. I recognize that some folks might like that failure mode however.

enimodas 9y ago

Why did you switch away from nginx?

scrollaway 9y ago
Not having to deal with certificate renewal is a big deal.
- fb03 9y ago
  I am running nginx reverse-proxying to a python API right now. Dealing with certificate renewal is a matter of running a daily cronjob issuing 'certbot renew'. If it works it replaces the fullchain.pem certificate, and that's it, easy peasy. Am I missing something?
  - scrollaway 9y ago
    And by running Caddy instead, I have one less piece to monitor and worry about. The way Let's Encrypt works, it makes a lot of sense to have the functionality be part of the web server.
    - JshWright 9y ago
      > The way Let's Encrypt works, it makes a lot of sense to have the functionality be part of the web server. That's an odd thing to say in this particular conversation thread... Why would you want to tightly couple your webserver to the availability of another service provider?
      - scrollaway 9y ago
        It's not tightly coupled any more than it would be with certbot. The issue I filed is an issue because it's unexpected behaviour (despite early closure, it has actually now been fixed).
    - stephenr 9y ago
      > by running Caddy instead, I have one less piece to monitor and worry about No, with Caddy you have several vaguely related pieces glued together with superglue. > The way Let's Encrypt works, it makes a lot of sense to have the functionality be part of the web server. I think this thread is pretty much proof that that approach will bite you in the ass.
      - scrollaway 9y ago
        > I think this thread is pretty much proof that that approach will bite you in the ass. What bit me here is the fact that I'm running alpha software instead of a battle-tested web server; I'm doing so willingly, with full awareness of the risks that that entails. Drawing the conclusion you did from the variables at play is shortsighted. If anything bites people in the ass, it's prejudice and shortsightedness. I wouldn't want you handling my ops/infrastructure.
- majewsky 9y ago
  Is it? I spent one day getting certbot up and running, and ever since then it's been pretty much a done deal.
  - manigandham 9y ago
    That's 1 day that I didn't have to spend, even better when dealing with many instances.
    - majewsky 9y ago
      Okay, I agree, with two caveats: 1. The cost does not scale with the amount of instances since it is the one-time cost to create the configuration package. 2. If you decide to go for Caddy instead, you'll have to spend the same time, if not more, learning Caddy.
eridius 9y ago
I switched from nginx to caddy for my (extremely low-traffic) server because I was tired of having to copy & paste a bunch of SSL setup any time I was configuring a new domain.

GiorgioG 9y ago

I'm done with Caddy - this is security theater at its finest. Back to nginx we go. Why did I pick Caddy, because it was simple/easy/fast-to-setup.

e_d_e_v 9y ago
I moved from Caddy to Traefik (https://traefik.io/ https://traefik.io/) several months ago. Granted, nginx has years (decades?) on some of these newer webserver/reverse-proxies, but I have been happy with all the built in niceties of traefik so far (single binary, etc), and haven't really experienced any negatives.
- mholt 9y ago
  You're not bit by this? https://github.com/containous/traefik/issues/791 https://github.com/containous/traefik/issues/791
  - e_d_e_v 9y ago
    Nope.