Stacks

Retrieve all stacks for a project

Create a new stack inside a project

Retrieve a specific stack by ID

Update a stack's name or docker compose configuration

Delete a stack and its associated infra resources

Kicks off an asynchronous deploy. Synchronous pre-flight validation (billing, registry image access, compose presence, deploy lock) runs first; on success the endpoint returns 202 Accepted immediately and the deploy proceeds in the background. The final result is delivered over the WebSocket channel (GET /ws) and reflected in the stack status (poll GET .../stacks/{stackId} until it leaves deploying) and the activity feed (GET .../activities).

Stop a deployed stack

Resume a previously stopped stack

Returns the activity log for a stack — append-only history of operations (deploy, seed, service_action) with their status (in_progress, success, failed). Field names are camelCase.

Proxies the backbone's per-container view of the stack (state, health, uptime, ports per compose service) and reconciles stacks.status in DB as a best-effort side effect (never overwrites deploying). A crash-looping service (see /state-events) forces the stack status to error even when the live container roll-up would be running. Designed to be polled: a never-deployed stack returns 200 with an empty containers list.

Current per-container cpu/mem/network usage for the stack, queried from VictoriaMetrics, plus a stack-level aggregate (values summed across containers). Designed to be polled; a never-deployed stack returns 200 with an empty containers list and a zeroed aggregate.

Returns the per-service state transition journal recorded by the stack-state-poll cron (one event each time a service's aggregated container state or health changes; fromState is omitted on the baseline event), plus crashLooping: the services currently considered crash-looping. A service is flagged when it accumulated 3+ degrading transitions (a crash exit, or to restarting/dead, or unhealthy) within the last 10 minutes, or when its latest known state is restarting. A user-stopped service and a clean exit (code 0 or 143) are not counted. Crash-loop flags are computed over the recent journal independently of limit.

Runs docker-compose <action> <service> on the stack's VM, where action is one of restart, start, stop. Only the named service is affected — the rest of the stack is untouched. The stack must have been deployed first. The action is journaled in the stack activity feed (type service_action), on success and on failure.