compose
A full Docker Compose project as one Unibench service. The escape hatch when the topology you need doesn't fit any other service type.
Manifest knobs
[services.legacy]
type = "compose"
file = "./docker-compose.yml"
project_name = "legacy" # default: <unibench-project>-legacy
profile = "dev" # optional compose profile to activate
healthcheck = { kind = "command", command = "docker compose exec api curl -fsS http://localhost/" }
Lifecycle
docker compose -f <file> up -don start.docker compose -f <file> downon stop (10s grace on each container).- Healthcheck is whatever the manifest declares; the orchestrator
doesn't peek into individual compose-service states. If your
compose project has its own healthchecks (
healthcheck:in the YAML), usehealthcheck = { kind = "command", command = "docker compose -f ./docker-compose.yml ps --status running --quiet" }or similar to gate on them.
Inspection drawer
compose services don't get a type-specific inspector. The Logs tab
tails docker compose logs. For per-container logs, drop into the
shell:
docker compose -f ./docker-compose.yml logs <service-name>
Common gotchas
- The orchestrator owns the lifecycle, not the compose binary.
Running
docker compose downmanually thenunibench refreshdoesn't restart anything — the orchestrator thinks the service is still up. Useunibench stop+unibench startto keep state in sync. - No port injection.
composeservices don't export$<NAME>_PORTfor dependents because the topology is multi-container and there's no obvious "the" port. If you need a downstream service to reach one container, hard-code the IP / port or declare an explicit env bridge.
When to use this vs container
- One container, simple config →
container. - Multi-container, your own networking, you already have a
docker-compose.ymlyou trust →compose. - A specific service from your compose file that you'd rather model
individually → split it out of the compose file into a
containerservice and keep the rest in compose.