Summary
Within an application, all services currently start concurrently. The
multi-service proposal explicitly deferred ordering as "a future concern"
(workflow/proposals/accepted/2026-04-27-multi-service-support.md). Some
applications need a service to be ready before another starts — for
example, a Rails web service that should not begin booting until its
Vite dev server is serving assets, or a worker that needs a local
queue/cache process up first.
What needs to happen
- Add a
depends_on field at the service level. Value is a list of
sibling service names within the same application.
- A service waits in
down until all of its dependencies are up
(TCP readiness has succeeded) before transitioning to starting.
- Bringing an application
up walks the dependency graph: services
with no remaining unmet dependencies start in parallel; the rest
follow as their dependencies become ready.
- Bringing an application
down reverses the order — dependents stop
before their dependencies.
- Reject configurations with cycles or with a dependency that names a
service that does not exist in the same application.
- A dependency that crashes leaves dependents in
down. The application
status derivation already covers this (any crashed → crashed).
- On-demand startup still triggers the whole application; the loading
page still subscribes to whichever specific service was requested
and redirects when that service is up, regardless of where it sits
in the graph.
Open questions
- Cross-application dependencies — out of scope for this issue, or
worth pulling in?
- Should
depends_on accept a richer form (e.g., { service = "vite", wait = "up" }) for future expansion, or stick to a flat list of
names?
- Per-service start timeout currently fires from the moment the OS
process is spawned. Does waiting on dependencies count against that
60-second budget, or does the timer start when the service actually
enters starting?
References
specs/process-management.md — Service Lifecycle, Application status
derivationworkflow/proposals/accepted/2026-04-27-multi-service-support.md —
decision deferring service dependency ordering
Summary
Within an application, all services currently start concurrently. The
multi-service proposal explicitly deferred ordering as "a future concern"
(
workflow/proposals/accepted/2026-04-27-multi-service-support.md). Someapplications need a service to be ready before another starts — for
example, a Rails web service that should not begin booting until its
Vite dev server is serving assets, or a worker that needs a local
queue/cache process up first.
What needs to happen
depends_onfield at the service level. Value is a list ofsibling service names within the same application.
downuntil all of its dependencies areup(TCP readiness has succeeded) before transitioning to
starting.upwalks the dependency graph: serviceswith no remaining unmet dependencies start in parallel; the rest
follow as their dependencies become ready.
downreverses the order — dependents stopbefore their dependencies.
service that does not exist in the same application.
down. The applicationstatus derivation already covers this (any
crashed→crashed).page still subscribes to whichever specific service was requested
and redirects when that service is
up, regardless of where it sitsin the graph.
Open questions
worth pulling in?
depends_onaccept a richer form (e.g.,{ service = "vite", wait = "up" }) for future expansion, or stick to a flat list ofnames?
process is spawned. Does waiting on dependencies count against that
60-second budget, or does the timer start when the service actually
enters
starting?References
specs/process-management.md— Service Lifecycle, Application statusderivation
workflow/proposals/accepted/2026-04-27-multi-service-support.md—decision deferring service dependency ordering