check:infra

Validate Docker infrastructure declarations across all features and the product without starting any containers.

Usage

splent check:infra

What it checks

Ports

• Declaration conflicts. Detects when multiple features or the product declare the same host port.
• Running containers. Warns if any declared port is already in use by a running Docker container.

Services

• Service name collisions. Warns when multiple features define a service with the same name (last one wins during merge).
• Container name collisions. Fails if multiple features use the same container_name.

Networks

• External network availability. Verifies that all networks declared as external: true actually exist in Docker.

Build contexts

• Dockerfile existence. Verifies that every service with a build: directive points to a valid build context directory containing a Dockerfile.
• Context path resolution. Checks that relative build context paths resolve correctly from the feature’s docker/ directory.

Health checks

• Health check coverage. Warns when a service does not define a healthcheck. Services without health checks cannot participate in ordered startup via depends_on: condition: service_healthy.

Volumes

• Volume name conflicts. Detects when multiple features declare the same named volume with incompatible configurations (e.g., different drivers or driver options).

Output

  Infrastructure check

  Ports
  [OK] No port conflicts (4 ports declared)
  [WARN] Port 5269 already in use by running container: sample_splent_app_web

  Services
  [OK] No service name collisions (4 services)
  [OK] No container name collisions (4 named containers)

  Networks
  [OK] Network 'splent_network' exists

  Build contexts
  [OK] All build contexts resolve to valid Dockerfiles (2 services)

  Health checks
  [WARN] Service 'mailhog' has no healthcheck defined
  [OK] 3 of 4 services define health checks

  Volumes
  [OK] No volume name conflicts (2 named volumes)

  All passed with 2 warning(s) (8 checks OK).

Integration

• Part of splent doctor (step 8).
• Used as pre-flight check in product:derive.
• Can be run standalone at any time.

See also

• check:docker. Docker daemon and Compose availability
• check:features. Feature cache, symlinks, install state
• product:derive. Full derivation pipeline with pre-flight checks