✦ For everyone, free.

Practical knowledge for real and everyday life

Home

6.3.1.3 Environment Service URLs

A focused guide to Environment Service URLs, connecting core concepts with practical Docker and container operations.

Environment service URLs are addresses of other services an application depends on — a database, a cache, an external API — supplied through environment variables at run time, allowing the same image to correctly locate its dependencies regardless of how those dependencies are actually deployed in a given environment.

Supplying Service URLs at Run Time

Each dependency's location is provided as its own environment variable, read by the application rather than hardcoded into the image.

docker run \
  -e DATABASE_URL=postgres://prod-db.internal:5432/app \
  -e REDIS_URL=redis://prod-cache.internal:6379 \
  -e PAYMENT_API_URL=https://api.payments.example.com \
  myapp:1.0
Why Hardcoding Service URLs Into the Image Is Problematic

An image with a service URL hardcoded into it would need to be rebuilt every time that dependency's location changed, or would need an entirely separate image variant for each environment — both significantly worse than simply supplying the URL at run time.

ENV DATABASE_URL=postgres://prod-db.internal:5432/app

docker run -e DATABASE_URL=postgres://prod-db.internal:5432/app myapp:1.0

The second approach allows the exact same image to correctly connect to a different database simply by varying the runtime-supplied URL.

Using Container Name Resolution Within a Shared Network

When dependencies run as containers on the same Docker network, their service URLs can reference the dependency's container name directly, relying on Docker's built-in name resolution rather than needing a fixed IP address.

docker run --network mynet -e DATABASE_URL=postgres://db:5432/app myapp:1.0

Here, db resolves to whatever container is named db on the shared network mynet, rather than requiring a specific, fixed address.

Why Environment Service URLs Matter

Supplying dependency locations through environment variables, rather than hardcoding them, is essential for deploying the same image correctly across multiple environments where dependencies are located differently, and for adapting smoothly when a dependency's location changes without requiring an image rebuild.

Related content