Docker Networking for AI Agent Services

How Docker Bridge Networks Work

When you start a Docker Compose stack, Compose creates a dedicated bridge network for that stack. Every container in the stack is automatically connected to this network and assigned an IP address from a private subnet. Each container is accessible to other containers in the stack by its service name, because Docker runs an embedded DNS server that resolves service names to container IP addresses.

Bridge networks operate at Layer 2 (data link layer) and provide Layer 3 (IP) routing between containers and to the host system. Each bridge network has its own subnet, typically a /16 in the 172.x.0.0 range. Containers on the same bridge can communicate freely with each other on any port. Containers on different bridges cannot communicate unless they are explicitly connected to a shared network.

This automatic isolation is a security feature. Your production agent stack cannot accidentally communicate with a development stack on the same host, even if both stacks use the same service names and ports. Each stack gets its own network namespace with its own DNS resolution, preventing cross-stack interference without any firewall configuration.

Service Discovery for Agent Stacks

Service discovery is the mechanism by which one service finds and connects to another. In Docker Compose, service discovery happens through an embedded DNS server that Docker manages automatically. When your agent runtime needs to connect to PostgreSQL, it resolves the hostname postgres through Docker DNS, which returns the container IP address on the bridge network.

For AI agent configurations, this means your environment variables can use service names instead of IP addresses. Set DATABASE_URL to postgres://user:pass@postgres:5432/agentdb, MODEL_ENDPOINT to http://ollama:11434, and REDIS_URL to redis://redis:6379. These service-name-based URLs work identically in development, staging, and production because Docker resolves them to the correct container IP in every environment.

DNS resolution adds negligible latency, typically under 1 millisecond for cached lookups. For AI agent workloads where model inference calls take hundreds of milliseconds to seconds, DNS resolution time is irrelevant to overall performance. Docker caches DNS lookups and updates them automatically when containers are replaced or restarted.

If you rename a service in your Compose file, update all environment variables and connection strings that reference the old name. Docker DNS only resolves the current service names, and the old hostname will stop resolving immediately when the old container is removed.

Port Mapping and External Access

By default, containers on a bridge network can communicate with each other on any port without explicit port mapping. Port mapping controls which container ports are exposed to the host system and therefore accessible from outside Docker. The ports section in a Compose service maps a host port to a container port, making the service reachable from the host machine and any network the host is connected to.

For AI agent stacks, expose as few ports as possible. Only the entry point to your system needs host port mapping, typically the agent API on port 8000 or a web interface on port 3000. Internal services like PostgreSQL (5432), Ollama (11434), Redis (6379), and Qdrant (6333) should not have port mappings. They remain fully accessible to other containers in the stack through the internal network, but are invisible to anything outside Docker.

This minimal port exposure significantly reduces your attack surface. An unprotected PostgreSQL port exposed to the host network can be discovered by port scanners and attacked with default credentials. Keeping it internal to the Docker network means it can only be reached by containers in the same stack, which you control.

When you do need to expose a port, consider binding it to localhost (127.0.0.1) rather than all interfaces (0.0.0.0) if the service only needs to be accessible from the host machine itself. The syntax 127.0.0.1:8000:8000 binds the port to localhost only, preventing access from other machines on the network.

Custom Networks for Traffic Isolation

For production deployments with strict security requirements, define custom networks to isolate traffic between service tiers within a single stack. A common pattern uses a frontend network connecting the API gateway or web server to the agent runtime, and a backend network connecting the agent runtime to databases and model servers. The agent runtime joins both networks, while the API gateway joins only the frontend and databases join only the backend.

This network segmentation prevents the API gateway from directly accessing databases, which limits the blast radius of a security compromise. If an attacker exploits a vulnerability in your web-facing service, they cannot reach the database directly because the two services are on different networks. They would need to compromise the agent runtime first, which provides an additional layer of defense.

Define custom networks in the top-level networks section of your Compose file and assign services to networks using the networks key in each service definition. Services that need to communicate must share at least one network. A service connected to multiple networks can route traffic between them, acting as a controlled gateway between network segments.

Network aliases let you give a service multiple DNS names on different networks. This is useful when the same database service should be reachable as db on the backend network and as analytics-store on a monitoring network. Each alias resolves to the same container IP on its specific network.

Cross-Stack Communication

Sometimes you need services in different Compose stacks to communicate. Docker supports this through external networks. You create a named network outside of any Compose stack using docker network create, then have multiple stacks join it by declaring it as an external network in their Compose files. Only services that explicitly join the external network can communicate through it.

External networks are useful when you run shared infrastructure services (like a centralized PostgreSQL cluster, a Redis cache, or a monitoring stack) in one Compose deployment and connect multiple agent stacks to them. Each agent stack defines the shared network as external and joins the relevant services to it.

Manage external networks carefully because they bypass the automatic isolation that Compose provides. Document which stacks share external networks and which services are connected. Audit external network membership periodically to remove stale connections from decommissioned stacks.

Network Performance for AI Workloads

Network throughput between containers on the same bridge network is limited by the host loopback performance, which is typically 10 to 40 Gbps on modern hardware. This is more than sufficient for the text-based communication that AI agent stacks generate. Even large context windows with tens of thousands of tokens represent only kilobytes of data per request.

For AI workloads that transfer large binary payloads (like image data for vision models or audio data for speech models), network performance remains adequate on the same host because bridge network traffic does not traverse physical network interfaces. The data stays in kernel memory and is copied between container network namespaces at memory speed.

Latency between containers on the same bridge is typically under 0.1 milliseconds, which is negligible compared to the model inference time that dominates AI agent response times. If you observe unexpectedly high inter-container latency, check for DNS resolution issues, container CPU throttling (which delays network processing), or network driver problems rather than assuming the Docker networking layer is the bottleneck.