Updating Caddy config from external host

Help
#1

1. Caddy version (caddy version): v2.1.1

2. How I run Caddy:

a. System environment: Ubuntu 18.04 LTS

b. Command:

nohup caddy run --resume > /etc/caddy/logs/std1.out 2> /etc/caddy/logs/std2.out &

d. My complete Caddyfile or JSON config:

beta1.tripkindle.com {
  root * /var/www/html
  encode gzip zstd
  try_files {path} {path}/ /index.html
  file_server
}

3. The problem I’m having and what I have done for now:

  • I have a website served by Caddy hosted on Digital Ocean.
  • My use case involves programmatically adding domains to the Caddy configuration from an external API.
  • I have a Node.js API deployed on Heroku that needs to modify the Caddy configuration to add more domains.
  • Currently, I am SSHing into the host running caddy from the Node.js API and adding domains to the config by using the /load enpoint for localhost:2019
  • How can I use the :2019 port so I don’t have to SSH into the host running Caddy via the Node.js API to update its config? Is there a better and secure way to update the Caddy config from an external source?
  • What is the recommended way to update Caddy’s running config from, say, a heroku app?
#2

You can change the admin endpoint which defaults to localhost:2019 to 0.0.0.0:2019 to accept requests from outside, but be aware that this also introduces security risks if some bad actor has access to this API.

Another approach would be to make use of SSH tunnels instead – I wrote about this here:

#3

Also, have you considered using On-Demand TLS? You didn’t describe your usecase that deeply, but it might be more appropriate for you rather than updating the config manually when you need to add new domains:

#4

Thank you @francislavoie, would you recommend SSH tunnelling, or my current way of using credentials to login via the Node.js API?

#5

I have considered On-Demand TLS but adding domains to the config seems to be a more stable way

#6

What do you mean by this? On-Demand TLS is very stable. It’s used in production by very large orgs.

It’s up to you, really. Setting up an SSH tunnel would avoid needing to move your command execution context to the SSH connection and you can make the requests locally. If you aren’t doing anything other than pushing data to the config API, I think the SSH tunnel is probably simpler.

#7

Refers to the conversation here - Dynamically adding multiple domains and its limit - #17 by Whitestrake

Thanks @francislavoie

#8

On-Demand TLS has the same rate limits as whatever you’re trying to do, because ultimately they both use Let’s Encrypt.

I don’t see any other points that would imply instability. That’s a long thread, could you be more specific?

#9

Was referring to the following from the thread:

That’s exactly correct. First handshake is slow, the rest are as normal since Caddy will have the certificate on hand after that.

Adding and removing programmatically has the benefit of a certain level of permanence and Caddy knows to continue maintaining the cert for the domain you’ve chosen. On-Demand TLS certificates will drop out if Caddy stops getting requests for them, I believe. Francis would probably set up On-Demand TLS, based on his posts; Matt appears to recommend the programmatic approach.

I myself like the simplicity and lack of requirement for extra software external to Caddy, that would actually perform this programmatic updating, so On-Demand TLS is appealing to me in that regard. But the programmatic approach also has its merits. I’d definitely strongly weigh the latter if I was already writing any kind of API interaction for my back end systems.

#10

This topic was automatically closed after 30 days. New replies are no longer allowed.