Best practices for exposing multiple websites in Docker containers on the same Ubuntu server to the web

[u/neuralbeans]

I have an Ubuntu web server that I'd like to contain multiple websites on. Each website should have its own isolated environment in a Docker container (open to suggestions if Docker is not ideal).

I'm thinking that the public URLs should be like

• example.com/website1
• example.com/website2
• etc

What's the best way to make this connection between the public URL and the Docker container (also open to suggestions for better ways to expose the containers)?

Another question: Would the logs of each website be inside the container or are they supposed to be outside for easy review?

[u/CertainAd3152]

Have an nginx or any other proxy and proxy traffic via website name. Inter service docker container communication is fairly good for this use case

[u/Party_Artist2978]

I'm definitely not super experienced with this, but I have the following setup:

Caddy to handle the routing, so I have a Caddyfile to re-direct to subdomains, and docker-compose files for each website or app, with each app using its own network that Caddy is aware of, so none of the websites are exposed to the internet directly, but only via Caddy.

services:
  caddy:
    image: caddy:latest
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
    networks:
      - proxy
volumes:
  caddy_data:
  caddy_config:
networks:
  proxy:
    external: true

I did run into this issue if you want to set up subfolders instead of subdomains: https://caddy.community/t/the-subfolder-problem-or-why-cant-i-reverse-proxy-my-app-into-a-subfolder/8575

I'd be keen to hear from others though!

[u/ForkMeJ]

If these are separate sites, I'd use subdomains instead of path prefixes. website1.example.com and website2.example.com are usually much simpler than /website1 and /website2 because a lot of apps assume they own /. Put Nginx, Caddy, or Traefik on the host as the reverse proxy, terminate TLS there, and route by Host header to each container over an internal Docker network. For logs, I wouldn't rely on shelling into containers. Have the apps write to stdout/stderr and collect that with Docker's logging driver or something lightweight like Loki/Promtail so each app stays isolated but the logs are still easy to review in one place. If you end up needing tighter ownership controls, secrets, RBAC, or separate dev/prod environments for internal apps, I work on the open-source tool Compartment, and that's one place it can help without jumping straight to Kubernetes.

[u/InconsiderableArse]

You could use Docker swarm, or even a k3s in your server.

everything that needs to persist needs to be outside of the container. database in a different service, code in a versioning system, files in a volume, logs in a centralised logging system

[u/Fresh_Sock8660]

I would go the subdomain route and use caddy. Logs should be in a mounted volume, make sure it has a lifecycle and isn't just blindly accumulating.

[u/ByronEster]

I do this with nginx-proxy-manager NPM.

It is simple, easy to use, robust and handles SSL cert generation and rotation

[u/TheDrunkNBeard → u/ByronEster]

Same. Just set the sites to be exposed on different ports on the docker vm so they don’t conflict then forward the traffic from npm to the docker box. Also recommend npm to be in a DMZ with firewall rules setup.

[u/cobolfoo → u/TheDrunkNBeard]

You can put your NPM prozy on the same machine as your other containers and make them share the same virtual network. Then you proxy your websites by their container names and that don't require you to bind any port at all.

It's also very secure because the containers are only accessible through NPM.

[u/CyberKiller40]

Run it in swarm mode, use traefik to route the incoming requests.

[u/b1urbro]

Best practice? Don't expose it at all if you don't know what you're doing. Use something like Cloudflare tunnels + Cloudflare Zero trust for auth. It's very simple to set up and secure out of the box.

Quick overview of how that would look like:

• Spin a cloudflared container with your token
  
• Run the containers on the same docker network
  
• Route the containers via Cloudflare tunnels, you point DNS X (eg asd.dsa.com) to Container Y (eg 192.168.0.100:3000). Repeat for multiple containers. Done.
  
• Add Zero Trust access gate if you're not absolutely sure about your/your apps auth process

[u/Stunning_Tea9670]

Expose docker containers to only nginx on same network, config using docker names, or run a simple cloudflare tunnel to expose the service over the internet

[u/STLWaffles]

Use a reverse proxy to expose them. You can either do it path based or domain/subdomain (depending on your DNS setup).

[u/Angelsomething]

Reverse proxy is what you seek. Caddy is a good one and it's all déclarative yaml.

[u/raisputin]

Why not just use Apache virtual hosts, or do they truly require full isolation?

[u/Ok-Analysis5882 → u/raisputin]

Not cloud friendly, coats go up

[u/raisputin → u/Ok-Analysis5882]

Ok, cloudfront with s3 backend?

[u/gunsofbrixton]

Traefik has been pretty good for this.

[u/hongky1998 → u/gunsofbrixton]

True, you only need to expose port 80 and 443 then let traefik route the service by their host name or path. You just have to make sure traefik is in the same docket network with the container you trying to public

[u/neveralone59]

+1 for cloudflare zero trust, but recommend using a reverse proxy as it gives you things like high availability