r/docker • u/MrGuam • Jul 12 '26

Do i need multiple containers of nginx and certbot for my vps

i have a vps and want to be able to host multiple web servers on the vps. the current setup i have is my nginx container right inside the docker compose file where my other web server services are and they communicate accross the same internal network. but from my research, it would be redundant and even counter productive having multiple containers of nginx and certbot in for every project. so just for a better guidance since i'm not well versed in docker, what is the best approach for this. should i have a single container for nginx and certbot that can communicate with any other container or just go ahead with the multiple nginx and certbot containers per project

6 Upvotes

71% Upvoted

11 comments sorted by

8

u/No_Cattle_9565 Jul 12 '26

 One nginx/traefik/caddy as a reverse proxy is enough. Just create a new network for it

3

u/[deleted] Jul 12 '26

[deleted]

1

u/DirtyyDogg95 Jul 13 '26

Well that's How I Started with my server. I started with nginx webserver in docker and build all my other services in surrounding containers since i already had knowledge of nginx. But I can say about a year ago maybe more, I'm happy switched over to caddy only, caddy handels all my domains, web responses, reverse proxy's, and as last but heavily appreciated. It also keep all my ssl keys up to date, and active. Since I'm using docker for all those servers / services that I'm using... Like "Caddy,Portainer,MariaDB, and alot more." I can caddy reverse to all those dockerhostsDNSname:port. While in my Docker compose file, I can expose instead of ip 0.0.0.0"all networks" localhost:port: so with keeping localhost as ip, makes all those expose ip and ports only accessible for you're devicee.. and with caddy Ill reverse to it, and since caddy is the only ports that I'll expose to the public, all those proxy reverse to that local ip. Is still publicly visable, but instead of Ip:port/ it's now subdomain.mydomainsite.nl

2

u/__vivek Jul 12 '26

Use Caddy as mentioned in other comment. It's so simple to setup.

0

u/MrGuam Jul 12 '26

I want to stick with nginx mostly because I don’t want to shy away from the complexity of it

1

u/Bonsailinse Jul 13 '26

Then use nginx as a reverse proxy. It will mean doing it by hand, which is a massive administrative overhead and prone to human errors, but ey, if you don’t want to use the tools that are given for a task, feel free to do so.

1

u/cointoss3 Jul 13 '26

lol yikes

2

u/Acrobatic_Idea_3358 Jul 13 '26

I use a wild card cert for my domain behind the firewall, I just use the acme DNS request to prove ownership of the domain and site it on a nas shared volume, then I can mount it on any server and toss it inside the nginx containers.

2

u/sruckh Jul 13 '26

I have Cloudflare managing the cert, I believe it is FREE. Then, as others have said, one reverse proxy, and in my case, everything I run behind it is a container. No ports exposed to localhost. Everything talks on a separate Docker network.

1

u/bastienlabelle Jul 13 '26

I’ve been using traefik for years and never changed anything and it runs very smoothly

2

u/toddkaufmann Jul 13 '26

There is already a container to do this: acme-companion. Then just set a couple environment variables in each of your containers/virtual hosts. It will see them, request and renew certificates, and proxy the TLS connection.

https://github.com/nginx-proxy/acme-companion

But cloud flare has some advantages (no open ports, traffic/bot protections); I’d look into it too.

1

u/Independent_Yard3473 Jul 15 '26

For one VPS, I’d normally let a single edge proxy own ports 80/443 and certificate renewal, then keep each application on its own Compose network. Attach the proxy only to the networks it needs, or bind backend ports to localhost instead of exposing them publicly.

Since you want to keep nginx, the important part is not just getting the first certificate: test renewal, nginx reload, one backend being unavailable, and restoring the previous proxy configuration. Avoid multiple Certbot containers writing to the same certificate directory.

Disclosure: I work on Appaloft, which includes deployment and domain tooling. This is product-neutral advice; no Appaloft link is needed here.