It combines caddy with docker-compose labels, making it super easy to spin up new projects that can immediately be exposed.
https://github.com/lucaslorentz/caddy-docker-proxy
I actually do this, because I kinda like having the proxy config right next to the app config in my Compose file, but I also dislike how much manual configuration Traefik needs. Downside is you need to know how to write Caddyfile (easy enough) and then also know how to write labels so CDP translates them into the correct Caddyfile (also easy enough, but could be annoying if you're learning both at the same time). Upshot is that once you know how it translates and you know what you need to write, it works just like Traefik but with just two labels, and I think that's pretty neat.
Caddy can support a surprising amount of weird and wonderful configurations, too.
I.e. it makes Caddy act a bit more like Traefik. Most of the time, you'll just add the label `caddy.reverse_proxy={{upstreams http 8080}}` to your containers and the plugin will regenerate Caddy's configuration whenever the container is modified.
To avoid downtime try using:
health_uri /health
lb_try_duration 30s
api.xxx.se {
encode gzip
reverse_proxy api:8089 {
health_uri /health
lb_try_duration 30s
}
}
Ideally, during deployment of a new version the new version should go live and healthy before caddy starts using it (and kills the old container). I've looked at https://github.com/Wowu/docker-rollout and https://github.com/lucaslorentz/caddy-docker-proxy but haven't had time to prioritize it yet.
https://en.wikipedia.org/wiki/Reverse_proxy
If you use LetsEncrypt's DNS-01 challenge to setup the SSL automatically, you can even deploy valid working SSL for IPs in the private range (192.168.x.x, 10.x.x.x etc etc), allowing auto-deployment of SSL for private services on your LAN, not just publicly accessible/exposed IPs. You can get around port forwarding during initial letsencrypt setup with this too, as all happens via DNS providers public APIs.
> https://letsencrypt.org/docs/challenge-types/#dns-01-challen...
Caddy is really easy to deploy as a Docker instance as well. There are many, many ways to accomplish LetsEncyrypt with HA though! It's really just an example of a common generic reverse proxy problem - searching for "reverse proxy letsencrypt" will show you many other ways to do it too. If you are using Docker to host your services at small scale, there are some really clever options now that auto-configure Caddy and SSL via letsencrypt all just using docker compose:
This is pretty neat. One of my gripes about docker-compose - and a major why I've been hesitant to add support for it - is that the updates are not zero-downtime. That makes it much more annoying to use for app deploys as you either have to rewrite the compose command as a docker command (defeating part of the purpose of a compose file) or accept the downtime during a deploy. I'll definitely be including this tool (or something like it) with Dokku once I actually add compose support.
Combining this with either Caddy Docker Proxy[1] or Traefik[2] could be quite nice for a very simple app deployment system.
Would be super awesome for this functionality to land in the official `compose` plugin, but for now this is a great way to dip your toes into app deployments without too much overhead.
There is a small island of productivity tools around docker-compose that would be super nice to build, and it's nice to see something like this land :)
- https://github.com/lucaslorentz/caddy-docker-proxy
- https://doc.traefik.io/traefik/providers/docker/I think this approach should work fine with https://github.com/lucaslorentz/caddy-docker-proxy as well.
Here's my setup.
I have a mini-pc with 32gigs of ram running as my combo "compute" and "storage" server.
It has an attached 5 bay enclosure with 8TB of storage on it.
On it I run
- Caddy to host static sites (my blgo) and to terminate HTTPS for other services - audiobookshelf (mostly unused)
- calibre-web (organizes ebooks)
- diun (notifications about docker image updates)
- gitea (personal git repos, mostly useless honestly but I do put some things in here before they go to GitHub)
- home-assistant (heavily used)
- mealie (heavily used)
- mpd (music player daemon, moderately used throughout my house)
- a VPN container for things that I want to only run inside a VPN and never when the VPN is down
- plex (heavily used to organize and play media elsewhere in the house)
- postgres
- scrutiny (for consolidated reporting of disk issues across my machines)
- shiori (read-it-later style bookmark manager)
- snapcast (coordinates multi-room audio throughout my house on a bunch of raspberry pis attached to speakers, heavily used)
- syncthing (heavily used)
- vaultwarden (heavily used)
- woodpecker (self-hosted CI, moderately used)
- zwave-js-ui (manages the zwave based smart home devices I have...about 20 or so)
My router/firewall is a separate devices running OPNsense and I use Wireguard to remote in - also works wonderfully.
I run all the services with docker-compose. The server itself is a bit of a snowflake but all the critical parts of the services are in their respective docker directories so backup is a snap (aside from postgres which has a separate backup process).
Currently I'm working on documenting a recovery procedure for Vaultwarden from our Backblaze backups so that in the event something happens to me my wife will be able to recover the Vaultwarden instance and our passwords. That's a fun exercise in documentation and simplifying the process.
Snapcast has really been a dream for multi-room audio setup. It presents a Spotify Connect device to anyone on my wifi. It has a separate stream which comes from whatever is being played on MPD and it is easily configured to play audio from whichever of those two streams is actively playing music...so I don't have to manually switch between them.
Caddy has been great for organizing everything and ensuring each service has HTTPS. I understand Traefik is somewhat more purpose built for doing this with a bunch of containers but I haven't had a need to switch.
I do use https://github.com/lucaslorentz/caddy-docker-proxy for letting the containers themselves describe their respective domains and mapping.
I do have a VPS and use it for the occasional site that needs to be more reliable than my home internet (which itself is quite reliable but I'm not counting 9s there). More and more I find I'm comfortable putting random static sites on my machine at home, though.
Parting thought: Exposing all of these details is a bit of a security concern, for sure. But ultimately I think it's (a) Not a huge security concern -- I need to assume any attacker knows what I'm running anyway, and (b) part of the fun is talking about it so I lose some value if I don't.
It's somewhat PITA to configure if you don't need a public cert, eg something for testing or not having a public A/AAAA record, but otherwise the automagik just works.
The only negative moment is what Caddy container restarts when the dependent containers starts|restarts, so you briefly lose all connectivity to all sites behind Caddy.
Seems easier to set it up directly in the docker compose files rather than have an extra interface. I guess you can do more in NPM but for me it's enough.
https://github.com/lucaslorentz/caddy-docker-proxy
Pretty nice, handles routing to your containers and manages LetsEncrypt for you. Response times are super fast too (<= 100ms for an ASP Web API application which uses Postgres via Entity Framework).
> when your biggest selling point is how neat the configuration is to write
To clarify, neat/easy configuration isn't our biggest selling point in v2. Flexible configuration is (one of them, anyway). Marketing an advanced web server as "easy" was a mistake in hindsight, so we don't do that anymore.
As for your use case, understandably it's slightly more tedious to do what you're trying to do. However, in our experience in helping hundreds of users in the forums and from what we see in issues, transparent proxy was the more common use case by far, and disabling that is usually as simple as setting the Host header to the address of the upstream. And we feel that enabling HTTPS universally is easier to understand than only enabling HTTPS for some hosts, and we made sure it's easy to disable when necessary.
(Most people just use Caddy, rather than proxying to it from other servers like Traefik, since Caddy can fit those use cases as well, especially with this plugin: https://github.com/lucaslorentz/caddy-docker-proxy)
I eventually moved to caddy (https://caddyserver.com/) and it is fantastic. Works seamlessly and I got all my obvious and not so obvious questions answered.
The automated pulling of container data is not automatic, but there is a port for that (https://github.com/lucaslorentz/caddy-docker-proxy) with a great meta-language.
There are a few improvements to be done with the logging part, overall it is really worth checking.
Like this? (Am not a Docker user, but I know this is an insanely popular solution) https://github.com/lucaslorentz/caddy-docker-proxy
There's also a WIP ingress controller: https://github.com/caddyserver/ingress/
Traefik is a reverse proxy for containers out of the box, apparently you would need some plugin to have that feature on Caddy : https://github.com/lucaslorentz/caddy-docker-proxy
As such, it seems like Traefik would be easier to setup for your use case.