Using Docker Networks to Isolate Your Services

When you first learn Docker, every container runs on the default bridge network and can reach every other container. This works until it does not. A compromised WordPress plugin that can reach your database server is a breach waiting to happen. Docker networks let you isolate services from each other, reducing the blast radius of any single compromise.

The Default Setup (and Why It Is Dangerous)

In a typical Docker Compose setup, all services are on the same network. Your reverse proxy can reach your CRM. Your CRM can reach your database. Your database can reach your monitoring tool. This is convenient, but it means that if an attacker compromises any service, they can probe and attack every other service on the network.

Network segmentation limits this. If each application has its own network, a compromise of your helpdesk does not expose your CRM database. The attacker is contained to the compromised application's network segment.

How to Segment with Docker Networks

Docker Compose supports defining multiple networks. Each application gets its own internal network for its database and any supporting services. The reverse proxy connects to each application's network to route traffic but does not need access to databases.

A segmented Compose file looks like this conceptually:

• Reverse proxy: Connected to every application's frontend network. Routes HTTP traffic. Cannot reach databases.
• Application A (CRM): Has two networks: one that connects to the reverse proxy (frontend), and one that connects to its database (backend). The database is on the backend network only.
• Application B (Helpdesk): Same pattern. Its database is isolated from the CRM database.

If Application A is compromised, the attacker can see the reverse proxy and Application A's database. They cannot see Application B or its database. The blast radius is limited to one application.

Practical Example: Nextcloud Network Segmentation

services:
  nextcloud:
    image: nextcloud
    networks:
      - proxy
      - nextcloud_backend
  nextcloud-db:
    image: postgres:16
    networks:
      - nextcloud_backend
  nextcloud-redis:
    image: redis:7
    networks:
      - nextcloud_backend

networks:
  proxy:
    external: true
  nextcloud_backend:
    internal: true

The proxy network connects to the reverse proxy. The nextcloud_backend is internal (cannot reach the internet) and only Nextcloud, its database, and its Redis instance are on it. No other application can reach Nextcloud's database.

When Segmentation Becomes Too Much

Network segmentation adds complexity. Each application needs its own network definition. Monitoring tools that need access to every database become harder to configure. For a stack of fewer than 10 applications on a single server, basic segmentation (separate networks for proxy, databases, and monitoring) is sufficient. For larger stacks or compliance-sensitive deployments, per-application segmentation is worth the overhead.

Start simple: at minimum, isolate databases onto a backend network that is not accessible from the internet. That single change prevents the most common attack path.

VPS1 configures Docker network segmentation for every managed stack. Your applications cannot talk to each other unless we explicitly allow it.