Common Docker Compose Security Mistakes in Self-Hosted Homelabs

try { if(localStorage) { let currentUser = localStorage.getItem('current_user'); if (currentUser) { currentUser = JSON.parse(currentUser); if (currentUser.id === 3901336) { document.getElementById('article-show-container').classList.add('current-user-is-article-author'); } } } } catch (e) { console.error(e); } Kai Builds Posted on Apr 28 Common Docker Compose Security Mistakes in Self-Hosted Homelabs #selfhosted #security #docker #opensource Self-hosting is great because it gives you control. You can run your own apps, keep your data closer to you, avoid some vendor lock-in, and learn how your stack actually works. But there is a tradeoff: once you self-host, you are also responsible for the boring parts. Exposed ports. Container defaults. Secrets. Backups. Updates. Reverse proxies. Databases. A lot of self-hosted setups start small: services: app: image: myapp:latest ports: - "8080:8080" db: image: postgres:latest ports: - "5432:5432" Enter fullscreen mode Exit fullscreen mode It works. The app is online. Everything feels fine. But a working Docker Compose file is not always a safe Docker Compose file. Here are some common security mistakes I keep seeing in self-hosted Docker Compose setups. 1. Exposing databases directly A database usually does not need to be exposed to the public internet. This is risky: services: db: image: postgres:16 ports: - "5432:5432" Enter fullscreen mode Exit fullscreen mode The same applies to services like: PostgreSQL: 5432 MySQL / MariaDB: 3306 Redis: 6379 MongoDB: 27017 Elasticsearch / OpenSearch: 9200 In many self-hosted stacks, the database only needs to be reachable by other containers on the same Docker network. A safer pattern is often to avoid publishing the database port at all: services: db: image: postgres:16 volumes: - db_data:/var/lib/postgresql/data app: image: myapp:1.0.0 depends_on: - db Enter fullscreen mode Exit fullscreen mode If you really need local access, bind to localhost instead of all interfaces: ports: - "127.0.0.1:5432:5432" Enter fullscreen mode Exit fullscreen mode This is not a complete security solution, but it is usually safer than publishing the database broadly. 2. Running privileged containers This is another setting worth reviewing carefully: services: app: image: example/app:latest privileged: true Enter fullscreen mode Exit fullscreen mode privileged: true gives a container much broader access to the host than most services need. Sometimes it is required. Many times it is not. If a container asks for privileged mode, it is worth asking: Why does this service need it? Can I use specific capabilities instead? Is there a documented reason? Is this image trusted? Is this service exposed publicly? Privileged containers are not automatically bad, but they should not be invisible. 3. Using network_mode: host without thinking Host networking can be useful, but it also removes some of Docker's network isolation. services: app: image: example/app:latest network_mode: host Enter fullscreen mode Exit fullscreen mode With host networking, the container shares the host network namespace. That can make port exposure harder to reason about, especially in a homelab where services are added over time. Before using host networking, check: Does this service actually require it? Which ports does it open? Is it behind a reverse proxy? Is it only reachable over a VPN or private network? Would a normal Docker network work instead? 4. Running containers as root Many containers run as root by…

This excerpt is published under fair use for community discussion. Read the full article at DEV Community.