Services on the same Compose network cannot resolve service names

[thromel]

Summary

Services started by container-compose cannot resolve each other by Compose service name, even when they are on the same Compose network. IP connectivity works, but DNS lookup for the service name returns NXDOMAIN.

This may depend on an upstream apple/container DNS capability, but it is worth tracking here because it is a core Compose compatibility blocker.

Related upstream issue: apple/container#856

Environment

- OS: macOS 26.5.1 (25F80)
- Xcode: 26.5 (17F42)
- container: 1.0.0 (release, commit ee848e3)
- container-compose: 1.0.0 installed via Homebrew
- Architecture: arm64

Reproduction

compose.yml:

services:
  web:
    image: nginx:alpine
    networks:
      - appnet

  probe:
    image: busybox:latest
    depends_on:
      - web
    networks:
      - appnet
    command: ["sh", "-c", "wget -qO- http://web"]

networks:
  appnet:

Run:

container system start
container-compose --file compose.yml up -d
container logs network-probe

Actual behavior

The probe service exits with:

wget: bad address 'web'

The services are attached to the custom network and IP connectivity works:

container inspect network-web
# network-web has 192.168.65.2/24 on appnet

container run --rm --network appnet busybox:latest wget -qO- http://192.168.65.2
# returns nginx welcome page

But DNS lookup fails:

container run --rm --network appnet busybox:latest nslookup network-web
container run --rm --network appnet busybox:latest nslookup web

Both return NXDOMAIN.

Expected behavior

Services on the same Compose network should be reachable by Compose service name, e.g. http://web, and eventually by configured network aliases.

If this requires upstream support from apple/container, container-compose should ideally document the limitation and track the dependency. If a workaround is possible in container-compose, service-name discovery is the most important Compose compatibility gap to close.