We were unable to load Disqus. If you are a moderator please see our troubleshooting guide.
Nice! I have updated the post with your suggestion
Thank you!
Hi Carlos,
the first block in your Caddyfile is not needed, because caddy binds to port 80 anyways to fulfill the ACME-Challenge, and redirects all requests from port 80 to 443 by default: https://caddyserver.com/doc... (See in the middle of the "On demand TLS" block)
Hi Carlos,
thanks for your article.
Currently I am struggling with caddy I think as the rest is already working.
I am always getting this error:
Internal Server Error
The server encountered an internal error and was unable to complete your request.
Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
More details can be found in the server log.
Unfortunately there is nothing in caddy's error log.
The std log only states: "GET / HTTP/2.0" 500 289
Any idea?
Thanks!
Hi there!
Have you checked owncloud logs? It looks like an error from Apache
Hi Carlos. Thanks for your article. This looks really convenient.
Is there a reason, that you are not using a data container for the caddy container volumes? So I would suggest using somethings like:
caddy-data:
image: exekias/caddy
command: /bin/true
volumes:
- /caddy
- /Caddyfile
caddy:
...
volumes-from:
- caddy-data
Ok, I got the point. With this setup changes to the Caddyfile would be not so convenient any more.
You are indeed right about the data volume :), but I would use it for caddy folder only (the one that keeps certificates and state).
As you wondered, it's useful to have Caddyfile in your filesystem, so you can easily make changes
Hi Carlos, nice article.
I want to bring to your attention that it is preferred to persist certificates on host machine to prevent running into Let's Encrypt rate limits. That way, restarting the container won't regenerate new certificates.