Docker Hosting: Where to Run Containers and How to Do It Safely

The short version

For a handful of containers, rent a VPS that is a full virtual machine, install Docker Engine from Docker's own repository, turn on log rotation, and put a reverse proxy such as Caddy in front for HTTPS. Publish no other ports: published ports listen on every network interface by default, and Docker routes their traffic around UFW, so every port you publish is open to the internet whatever UFW says.

A VPS fits when you want

• One to a dozen services with fairly steady traffic
• A predictable monthly bill
• Root access and free choice of software
• Your data stored in a jurisdiction you picked

Look elsewhere when

• Traffic swings from nothing to thousands of requests and you only want to pay for what you use
• You need containers spread across several machines with automatic failover
• Nobody on the team wants to apply updates or check backups

• A full virtual machine. Docker needs control of kernel features such as namespaces and cgroups. A full virtual machine with its own kernel gives you that. Some budget VPS are themselves containers (OpenVZ or LXC), where Docker may not run at all or needs settings only the provider can change.
• Root or sudo access. The standard Docker Engine installation in this guide needs it, and it is also why conventional shared hosting cannot run Docker.
• Enough memory. Memory runs out long before processor power on a small Docker host. The next section has sizes.
• Disk space for images. Every image you pull stays on disk until you remove it, and old versions pile up after updates.
• A public IPv4 address. Caddy can get certificates over IPv6 alone, but visitors on IPv4-only networks could not reach you, so a dedicated IPv4 address is still the practical choice for anything public.
• An acceptable use policy that allows your workload. The rules apply to what runs inside your containers exactly as they would on the host.

1Prepare the server

Log in with SSH keys, apply updates, and turn on the firewall for SSH. UFW still protects services on the host itself, such as SSH, even though it does not police Docker's published ports.

sudo apt update && sudo apt upgrade -y
sudo apt install ufw
sudo ufw allow 22/tcp
sudo ufw enable

2Install Docker Engine from Docker's repository

Use Docker's own repository rather than the distribution's docker.io package, which Docker asks you to remove first if it is installed. These are Docker's commands for Debian 12 and 13; on Ubuntu, follow Docker's Ubuntu page, where only the repository lines differ. Docker's convenience script is meant for testing, not production.

sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/debian
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo docker run hello-world

If the last command prints "Hello from Docker!", the engine works. Docker starts automatically at boot.

3Turn on log rotation before you run anything

Docker's default log driver keeps everything a container prints, with no rotation, which is how small servers run out of disk. The local driver rotates logs automatically and keeps about 100 MB per container. The setting only applies to containers created after the change, so do it now.

echo '{ "log-driver": "local" }' | sudo tee /etc/docker/daemon.json
sudo systemctl restart docker

4Point your domain at the server

Create an A record, and an AAAA record if you use IPv6, for the hostname you want, such as status.example.com, pointing to your VPS. Caddy needs it in place to get a certificate.

5Write the compose file

Create a project folder with mkdir -p ~/status/conf && cd ~/status, then save this as compose.yaml. Only Caddy publishes ports. Uptime Kuma has none, so nothing reaches it except through Caddy.

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./conf:/etc/caddy
      - caddy_data:/data
      - caddy_config:/config

  uptime-kuma:
    image: louislam/uptime-kuma:2
    restart: unless-stopped
    volumes:
      - ./data:/app/data

volumes:
  caddy_data:
  caddy_config:

6Tell Caddy where to send traffic

Save this as conf/Caddyfile, with your own hostname. Containers in the same compose file reach each other by service name, so Caddy finds the app at uptime-kuma:3001.

status.example.com {
	reverse_proxy uptime-kuma:3001
}

7Start it and check

sudo docker compose up -d
sudo docker compose ps
sudo docker compose logs caddy

Once your DNS record resolves to the server and ports 80 and 443 are reachable, Caddy gets a certificate on its own and https://status.example.com loads. The unless-stopped restart policy brings both containers back after a crash or a reboot, unless you stopped them yourself.

8Keep it updated

Run this in the project folder every week or two. It pulls newer images, recreates only the containers that changed, and removes the old untagged images left behind. Your regular apt upgrade keeps Docker Engine itself current.

sudo docker compose pull
sudo docker compose up -d
sudo docker image prune -f

9Back up the project folder

Because Uptime Kuma's data lives in ./data, one archive of the folder holds the app's data, the compose file and the Caddyfile together. Caddy's certificates sit in the caddy_data volume and are not included, which is fine: after a restore, Caddy requests new ones. Stop the stack briefly so nothing is written mid-copy, then copy the archive off the server. For a database container, use the database's own dump tool instead of copying its files while it runs.

cd ~/status
sudo docker compose stop
sudo tar czf ~/status-backup-$(date +%F).tar.gz -C ~ status
sudo docker compose start

1. Trusting UFW to block Docker-published ports

Docker's installation guide says it plainly: if you use ufw or firewalld, ports you publish bypass your firewall rules, because Docker routes container traffic before those rules are checked. Published ports also listen on every interface by default, and plenty of example compose files publish an admin port such as "3001:3001". Publish only your reverse proxy, and bind anything else to the server itself with "127.0.0.1:3001:3001".

2. Treating the docker group as harmless

Adding your user to the docker group saves typing sudo, but Docker's own docs warn that the group grants root-level privileges. Anyone who can control the Docker daemon can mount the host's files into a container. If you want Docker without root, use rootless mode instead.

3. Opening the Docker API to the network

By default the daemon listens only on a local socket. To manage the server from your laptop, use SSH, which the Docker CLI supports directly, for example docker context create --docker host=ssh://user@your-server myvps. Never expose the API port to the internet.

4. Letting logs and images fill the disk

Without log rotation, a chatty container can fill a 25 GB disk on its own, and old images pile up after every update. Set the local log driver on day one, prune images after updates, and check usage with docker system df.

5. Keeping data inside the container

Anything written inside a container disappears when the container is removed, and an update removes it. Keep every piece of data you care about in a volume or a mounted folder, and test a restore before you need one.