Docker for your websites: 7 practical tips for running containers on your own server
A Redis cache, a queue worker, a small internal API next to your site — Docker makes it clean on your own VPS. Here are seven habits that separate a tidy container setup from a fragile one.
Running a website rarely stops at PHP and a database. Sooner or later you want a Redis cache, a queue worker, a small internal API or a headless service running next to it. Docker is the cleanest way to do that on your own VPS — but a few habits separate a tidy setup from one that breaks at 3 a.m. Here are seven worth adopting.
1. One network per site, and talk by name
Put each site's containers on their own Docker network and let them reach each other by container name (redis:6379) rather than localhost. It keeps services discoverable, avoids port clashes between projects, and means one site's containers can't accidentally talk to another's.
2. Don't publish ports you don't need
A Redis instance or internal API that only your app uses should never be bound to a host port. Reach it over the internal network instead. Every published port is attack surface — expose only what the public genuinely needs, which is usually just your web app.
3. Pin image tags — avoid :latest
redis:latest today and redis:latest in three months can be different major versions. Pin to something specific like redis:7-alpine (or a digest) so a rebuild can't silently change — or break — a service you depend on.
4. Always set a restart policy
Without --restart=unless-stopped, a server reboot leaves your side services down and your app throwing connection errors until you notice. Set the policy once and containers come back on their own after a reboot or a crash.
5. Treat Docker as isolation, not a security wall
Containers share the host kernel. They're excellent for keeping projects tidy and dependencies separate — but they are not a hard boundary between untrusted tenants. Set memory and CPU limits so one container can't starve the others, and assume a compromised container can pressure its neighbours.
6. Know how to read the logs
When something breaks, docker logs --tail 100 <name> is your first stop. Make sure your containers log to stdout/stderr (most official images already do) so the output is actually captured and not buried in a file inside the container.
7. Label everything
On a server hosting several sites, docker ps turns into noise fast. Label each container with the site it belongs to (--label site=acme) so you can filter, audit and clean up later without guessing which container powers what.
The easy way
Every tip above is a manual step you can forget or get wrong. This is exactly the kind of busywork a good panel should handle for you. In ShadowPanel, adding a container to a site automatically gives it its own per-site network, a site label, an unless-stopped restart policy and validated, non-privileged port mappings — from a clean UI, with logs and start/stop/restart one click away. You get all seven good habits by default, without memorising a single flag.
Run containers the tidy way
Free tier — 3 sites, no credit card — and you can install on any Ubuntu VPS in about ten minutes:
curl -fsSL https://shadowpanel.de/install.sh | bash