docker exec#

The obvious one. Drop into a shell:

docker exec -it mycontainer sh

Use sh not bash because Alpine images do not have bash. Once inside, you can poke around:

# Check what processes are running
ps aux

# Look at environment variables
env | sort

# Test network connectivity
wget -qO- http://other-service:3000/health

# Check disk usage
df -h

But what if the container has no shell? Minimal images built FROM scratch or distroless images strip everything out.

docker logs#

Before exec-ing into anything, check the logs:

# Last 100 lines
docker logs --tail 100 mycontainer

# Follow in real time
docker logs -f mycontainer

# Logs since a specific time
docker logs --since 2026-03-29T10:00:00 mycontainer

# With timestamps
docker logs -t mycontainer

The --since flag is underrated. When a container has been running for weeks, you do not want to scroll through megabytes of old logs.

docker inspect#

This tells you everything about the container’s configuration:

# Full JSON dump
docker inspect mycontainer

# Just the IP address
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' mycontainer

# Environment variables
docker inspect -f '{{json .Config.Env}}' mycontainer | jq .

# Mount points
docker inspect -f '{{json .Mounts}}' mycontainer | jq .

# Port mappings
docker inspect -f '{{json .NetworkSettings.Ports}}' mycontainer | jq .

# Health check status
docker inspect -f '{{json .State.Health}}' mycontainer | jq .

docker cp#

Copy files in or out of a running container:

# Copy a config file out for inspection
docker cp mycontainer:/etc/nginx/nginx.conf ./nginx.conf

# Copy a fix in
docker cp ./fixed-config.json mycontainer:/app/config.json

This works even if the container has no shell or text editor.

nsenter: The Nuclear Option#

When docker exec is not enough or the container has no shell, nsenter lets you enter the container’s namespaces from the host:

# Get the container's PID
PID=$(docker inspect -f '{{.State.Pid}}' mycontainer)

# Enter its network namespace
sudo nsenter -t $PID -n ss -tlnp

# Enter all namespaces (like exec but from the host)
sudo nsenter -t $PID -m -u -i -n -p -- /bin/sh

This is useful for network debugging. You can run tcpdump, ss, or ip inside the container’s network namespace even if those tools are not installed in the container.

docker diff#

See what files changed since the container started:

docker diff mycontainer

Output looks like:

C /app
A /app/data/cache.db
C /tmp
A /tmp/something-unexpected

A means added, C means changed, D means deleted. This is great for finding containers that are writing to unexpected places.

Debugging Network Issues#

When containers cannot talk to each other:

# Check which networks a container is on
docker inspect mycontainer -f '{{json .NetworkSettings.Networks}}' | jq 'keys'

# Ping from one container to another
docker exec web ping -c 3 api

# Check DNS resolution
docker exec web nslookup api

# List all containers on a network
docker network inspect mynetwork -f '{{range .Containers}}{{.Name}} {{.IPv4Address}}{{end}}'

One-Liner Health Checks#

# Which containers are unhealthy?
docker ps --filter health=unhealthy --format '{{.Names}}: {{.Status}}'

# Which containers restarted recently?
docker ps --format '{{.Names}}: {{.Status}}' | grep -i restarting

# Resource usage snapshot
docker stats --no-stream --format 'table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}'

The instinct to restart a broken container is strong. But nine times out of ten, the information you need to fix the actual problem is sitting right there in the logs, the inspect output, or the filesystem diff. Restarting just resets the evidence.

It sounds like a mess, but it is actually pretty clean. The trick is structure: one compose file, two networks and some naming discipline.

One Compose File, Two Networks#

Every service lives in a single docker-compose.yml. I tried splitting it into multiple compose files early on and it was a nightmare. Services that need to talk to each other end up on different networks, you forget which file defines what, and debugging becomes archaeology.

One file means one place to look. The trade-off is that the file is about 200 lines long, but that is way better than hunting through five separate files.

The networking is simple: two Docker bridge networks. The first one connects Caddy to the internet. The second one connects Caddy to every backend service. Services that need to be reached by Caddy join the backend network. Services that need direct port access to the internet get explicit port mappings.

The WireGuard container is the exception. It runs with host networking because it needs raw access to the network stack for the VPN tunnel. Everything else uses the bridge networks.

Container Naming#

I name every container explicitly with container_name. Docker Compose generates names like wleeaf-caddy-1 by default, which is ugly in logs and hard to type in commands. Explicit names mean I can do docker logs caddy instead of docker logs wleeaf-caddy-1.

This also matters for DNS resolution inside Docker networks. When you give a container a name, other containers on the same network can reach it by that name. So my Caddy config just says reverse_proxy gitea:3000 and Docker handles the resolution.

Resource Reality#

People overestimate how much RAM you need. Here is what my containers actually use:

The reverse proxy sits at 15 megabytes. The git server uses about 110. The mail server is the hungriest at 160. The Matrix homeserver varies between 100 and 500 depending on federation activity. The database backing it uses 70. Everything else is under 50 each.

Total memory usage hovers around 2.5 gigabytes. That leaves five gigs free for spikes, builds, and the occasional agent session eating a gig for a few minutes.

CPU is basically idle. The load average rarely goes above 0.1 unless someone is building a Docker image or running a CI job. Four cores is overkill for this workload.

Secrets Management#

I keep secrets in a .env file next to the compose file. Docker Compose reads it automatically. Database passwords, API tokens, and hashed passwords all live there. The compose file references them with the dollar-sign-curly-brace syntax.

The .env file is not in any git repo. I back it up manually. Some people use Docker secrets or Vault for this, but for a single-server personal setup, a .env file is fine.

Restart Policies#

Every service has restart: unless-stopped. This means containers come back after a reboot or a crash, but stay down if I explicitly stop them. I used to use always but that fights you when you are debugging, because the container keeps restarting while you are trying to read the logs.

The one exception is the CI runner. It has restart: unless-stopped too, but I sometimes need to stop it to free resources during heavy builds. With unless-stopped, it stays down until I bring it back up.

Volume Strategy#

I mount named directories from the host filesystem, not Docker volumes. Every service gets a directory under the main project folder. Caddy gets ./caddy, Gitea gets ./gitea, the mail server gets ./stalwart, and so on.

This makes backups trivial. I can tar the entire project directory and I have everything: configs, data, and the compose file itself. Docker volumes are fine, but they hide the data in a location you have to look up every time.

The Upgrade Dance#

Upgrading a service usually means changing the image tag and running docker compose up -d. For services using latest, I pull first with docker compose pull and then bring them up.

I do not use Watchtower or any automatic update tool. I want to know exactly when things change. An automatic update at 3 AM that breaks the mail server is not a problem I want to have.

The whole setup has been running for months with essentially zero unplanned downtime. The only time services go down is when I am actively working on them. For a personal infrastructure project, that is more than good enough.