Hello! New here to Caddy and the Caddy community. I just set up Caddy (v2) with the official docker image, using the docker flag
--network host. It seems to simplify my life a lot, since I now can manage it as if it was running directly on the host machine. I can point it to
I now wonder - are there any caveats with doing it like this? Security concerns etc. (I was thinking about the admin port but if I understood it correctly it should still only be reachable from localhost).
docker run -d --network host -v caddy_data:/data -v caddy_config:/config -v $PWD/Caddyfile:/etc/caddy/Caddyfile --name stoic_cannon caddy caddy run --watch --config /etc/caddy/Caddyfile
I split your post into a new thread — please don’t post new questions on old threads!
--network=host is fine if your usecase is that you don’t have your other services dockerized. Effectively you’re running it like if it wasn’t dockerized from the perspective of networking.
Welcome @einarpersson - thanks for joining. I hope that Caddy will serve you well!
First of all, the reason I “recycled” the other topic was that I was under the impression that I was basically asking the same question. “How do I use caddy-docker as a reverse proxy for other docker containers?” But sure, I didn’t mind to get a thread of my own.
Second, why would my suggestion imply that I don’t have other services dockerized? If I for example run a node-app in a container and expose it on port 3000, I should be able to just point caddy to
What is the recommended way of running a caddy container and using it as a reverse proxy to point it to other containers (maybe running on different docker networks)?
If you use something like
docker-compose to orchestrate your containers, then it becomes very easy to reverse proxy to your other containers. Instead of using
localhost, you would use the docker-compose service name.
For example, if you’re running a
caddy service and say, a
django-app service, then you could do:
This makes use of Docker’s internal DNS, which docker-compose uses to add hostnames for each container running in a network.
Hmm, yes I get what you are saying. The reason I wanted to have caddy on the host was that I tend to have one docker network / stack per application. But maybe I should reconsider this and have them run on the same docker network. I’m not really sure.
Well thanks for your thoughts anyhow!
What you can do is make the caddy container join each of your other separate networks (with
docker network connect <network> <container> or via docker-compose
Wait, maybe a stupid question but does this mean that the caddy container can belong to / connect to several networks at the same time?
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.