Notice: This add-on is now archived.
I’ve created a new Caddy add-on!
The only other Caddy add-on I could find is geared more towards simple proxying using the Hass.io config while this add-on just let’s you supply a Caddyfile. I hope someone finds it useful!
Following this thread. I currently have Caddy installed on an All In One (AIO) installation and looking to move to hassio.
To accomplish your goal, you’ll need a few pieces.
All of your services (zoneminder, etc) will need either static/reserved IPs or (better yet) DNS names set in your local DNS.
You’ll need a DDNS service (e.g. duckdns) if you can’t get a static IP from your ISP (doubtful) so you can access your router from the internet.
I really suggest you also set up Letsencrypt. It’s easy and it secures all of your services. You can add several subdomains to one certificate.
You’ll want to use separate subdomains for each service, e.g. mqtt.xxx.duckdns.org, appdaemon.xxx.duckdns.org, etc. You could theoretically use subpaths on a single domain, but some services don’t make it easy (or possible) to do this setup.
Then you set up a separate section in your Caddyfile for each service like:
https://<service>.xxx.duckdns.org {
tls /ssl/fullchain.pem /ssl/privkey.pem {
alpn http/1.1
}
proxy / <local ip/dns>:<local port> {
transparent
websocket
}
log stdout
errors stderr
}
Port forward 80 and 443 in your router to your Hass.io IP.octop, and you should be good to go.
If you want to use the same dns names in your local network, you’ll need to add each subdomain as a primary zone to your local dns and point it to the service.
You mention not using HTTPS or duckdns, but I don’t know how you’ll be able to do this without either.
Subpath? Not sure what this is. But I think should be OK subdomains if that way is more stable
some other user suggested to have this
internet ------ router (ssl) ------ pi3 with reverse proxy (ssl) ------ behind the reverse proxy everything http (not https) .
So to have https and duckdns but before the Pi3 doing the reverse proxy (nginx or caddy), and http behind it.
I hope I am clear
Another nice add-on from @korylprince. Thanks for that!
May I suggest that you provide a single add-on repository url for all your add-ons? That way its easier not to miss anything from you. I’ve noticed your other add-ons only by accident and that’s a shame.
Okay, back to topic:
I’m currently running into rate limits by Let’s Encrypt. Presumably because I instruct Caddy to request a certificate for my domain (using tls [email protected]) instead of providing any *.pem files. It looks like cryptographic assets requested that way are not stored in ssl/... but in Caddy’s working directory (see The .caddy folder):
Is there any chance to alter this behavior or do I have to use another add-on to keep my certs up to date?
Honestly, with what you’re trying to do, the other Caddy add-on would probably be better/easier to use. It can do LetsEncrypt and the proxying all through the JSON config.
So you would do:
internet -> router – (forward 80, 443) --> rpi3( Caddy add-on and duckdns) – (internal IPs and ports) --> internal services
I may consider adding a single repository, but it involves a lot of duplication of configs and commits with the way the current system works.
I just pushed version 1.1 that sets CADDYPATH to /ssl so Caddy won’t request every time it starts and you can use it’s certificates in other add-ons. Sorry I missed that!
Okay, thanks for the clarification regarding the single repository. It’s completely understandable that you want to avoid code duplication.
I’ve tried v1.1 but ran into a problem.
Complete log:
starting version 3.2.4
2018/02/02 13:29:13 could not save user: making user directory: mkdir /ssl/acme: read-only file system
Activating privacy features...
Is there anything I can do on my side to solve it?
Is there anything I can do on my side to solve it?
Update to 1.2.
I forgot to make that directory writable 
You’re fixing things fast 
I can report it works as expected now. Several restarts and no more rate limits by Let’s Encrypt.
What I’ve noticed though is, that the add-on does not start (or at least not successfully) when rebooting the host OS. The Boot option is configured to auto. I can’t find any logs regarding that topic. Manually starting or restarting the add-on never fails.
I’d also like to know if/how to use the input field in the add-on’s “Options”. It’s configured {} by default. Is it intended to provide Caddy command line flags here? I’m thinking about using -disable-http-challenge removing the need to open port 80 on my router just for the challenge. It’s nothing major if this isn’t possible, but I thought I’d ask if it is.
I’ve added a flags configuration option in version 1.3. See the documentation here.
As for the issue with it not starting, the startup is set to “services” which means it starts before homeassistant is started. Are you referencing the “homeassistant” hostname in your Caddyfile?
Have you checked both the supervisor as well as the add-on logs?
Thank you for adding the flags option.
I’m not referencing homeassistant but localhost in my Caddyfile. May that be the reason of failure?
While I’ve checked the logs of your add-on, I’ve totally forgot the supervisor’s. I’ll do that as soon as I’m able to reboot the host again.
I wouldn’t think so because localhost should always resolve. Hopefully the supervisor logs will give us an idea of what’s going on.
Okay, I did a little testing, but I’ll doubt it is of much help what I found… 
The supervisor’s log states the following error when enabling this add-on and rebooting the host os:
requests.exceptions.ReadTimeout: UnixHTTPConnectionPool(host=‘localhost’, port=None): Read timed out. (read timeout=60)
I’ve replaced localhost in my caddyfile with 127.0.0.1 then but that didn’t change a thing. I’m still getting the message from above saying localhost has timed out…
I’ve googled that message and it looks like it is related to docker images themselves and not caddy. A user stated that may relate to the engine responding to slow under high load. Some user had success increasing the read timeout, other not.
Unfortunately I’m not able to evaluate if this might be a possible solution in this case but I can report that the add-on never fails to start when everything else is already up and running.
My test setup is a Raspberry Pi 3 running Mosquitto, SSH, Samba and (your) Node-RED next to this add-on.
So I, too, did some digging. That error is actually coming from docker-py, a python wrapper around docker that the supervisor uses.
It is indeed an issue that crops up when the machine docker is running on is being taxed. Here’s one of a few issues related to this.
I’ve created an issue to have the timeout (currently 60s) increased to hopefully mitigate this issue.
The one thing you could possibly do to help is use a faster SD card.
The timeout was increased to 300s. Judging by the supervisor’s release history, I would expect it to be in version 0.86 which should come out within a couple weeks (total guess.)
Let’s hope it fixes this issue.
Okay, I’ll test and report then 
hi! Trying to use your addon, but I cna’t connect. I think (think) I followed weel all the instructions, but can’t connect from outside.
I have static IP, a duckdns account, forwarded port 80 and 443 to HASSIO, where I ran your addon, with the above config.
Is there any log somewhere?
EDIT:
I had to wait a minute or so, I can now log from outside the network, cool.
For using MQTT would this work? I guess we should use port 1883, correct?
https://mysub.duckdns.org {
tls /ssl/fullchain.pem /ssl/privkey.pem {
alpn http/1.1
}
proxy / 192.168.1.12:8123 {
transparent
websocket
}
log stdout
errors stderr
}
https://mysub-mqtt.duckdns.org {
tls /ssl/fullchain.pem /ssl/privkey.pem {
alpn http/1.1
}
proxy / 192.168.1.12:1883 {
transparent
websocket
}
log stdout
errors stderr
}