By default, services in Compose are reachable by their service name. With aliases, you can give a service additional hostnames on a network, no extra DNS config required. Basic usage Add aliases under the network attachment: services: primary: image: postgres networks: app-net: aliases: - db - database - postgres-primary networks: app-net: From any other container on app-net, you can reach the service as primary, db, database, or postgres-primary. All four hostnames resolve to the same container. ...

Not everything in your stack is a container. Managed databases, SaaS APIs, VPN tunnels, Kubernetes intercepts, all sit outside Docker but still need to be wired into your local environment. Compose 2.36 introduced provider services to declare and manage these alongside your containers. The syntax A provider service replaces image: with a provider: block: services: api: image: my-api:latest tunnel: provider: type: telepresence options: namespace: avatars service: api port: 5732:api-80 Two parts: ...

LLMs are now first-class citizens in Compose. The models top-level key lets you declare which models your application needs and wire them into your services, all in the same Compose file. Basic usage Declare a model at the top level, reference it from a service: models: smollm: model: ai/smollm2 services: app: image: myapp models: - smollm When the stack starts, Compose ensures the model is available locally and connects the app service to it. The container receives endpoint information via environment variables. ...

Both entrypoint and command define what runs when a container starts. They look similar, but they play different roles, and confusing them leads to surprising behavior. The mental model When a container starts, Docker runs: <entrypoint> <command> entrypoint is the executable command is the default arguments passed to it If the image’s Dockerfile has ENTRYPOINT ["python"] and CMD ["app.py"], the container runs python app.py. Overriding from Compose Both can be overridden in Compose: ...

You’ve used secrets for sensitive data (Tip #22). For non-sensitive config files like nginx.conf or prometheus.yml, there’s a parallel feature: configs. Basic usage Define a config at the top level, reference it in a service: configs: nginx_conf: file: ./nginx.conf services: web: image: nginx configs: - source: nginx_conf target: /etc/nginx/nginx.conf The file is mounted read-only inside the container at the target path. No need to declare a volume mount manually. ...