Use lifecycle actions to restart an existing service or stop and resume it without recreating its configuration. Use deploy to release new source and rollback to select an earlier artifact.
For API examples, set BEX_API_URL to your instance's API origin, BEX_TOKEN
to an authorized token, and SERVICE_ID to the service's stable id.
Use the corresponding controls in the dashboard if you prefer.
Restart a service
curl --fail-with-body -X POST "$BEX_API_URL/v1/services/$SERVICE_ID/restart" \
-H "Authorization: Bearer $BEX_TOKEN"Restart requests replacement of the running processes. It is not a command to build new source. Follow readiness and runtime logs after submitting it. Ordinary services use rolling replacement, but uninterrupted service depends on capacity, application shutdown, and readiness. A persistent disk requires stop-then-start replacement; do not promise a zero-downtime restart for that workload.
A restart can discard process memory and ephemeral files. External databases and correctly mounted persistent storage have separate lifecycles. Restarting a process does not undo its external writes or guarantee failed work is retried.
Suspend a service
curl --fail-with-body -X POST "$BEX_API_URL/v1/services/$SERVICE_ID/suspend" \
-H "Authorization: Bearer $BEX_TOKEN"Suspension preserves configuration while making the workload unavailable. Long-running services scale down; a cron service pauses scheduling. For a cron execution already in progress, use the run cancellation action rather than assuming suspension cancels it.
The operator reports convergence asynchronously, including Hibernated for a
suspended App. A successful API response is not proof that every process has
already stopped. Inspect status before relying on suspension during maintenance.
Suspension is not deletion, a backup, or a guarantee of zero charges: persistent storage and other resources can remain provisioned. Preserve required data outside ephemeral files before stopping a service.
Resume a service
curl --fail-with-body -X POST "$BEX_API_URL/v1/services/$SERVICE_ID/resume" \
-H "Authorization: Bearer $BEX_TOKEN"Resume clears the suspended state. Long-running workloads need time to start, pass health checks, and regain capacity; cron services resume their schedule. Verify application behavior before treating the service as restored.
Manual suspension and automatic idle hibernation are distinct. An intentionally suspended service should be resumed explicitly; do not assume an incoming request will wake it as it might an eligible idle service. For free-tier idle sleep, wake responses, and a bounded recovery client, see Idle services.
Managed datastores
PostgreSQL and Key Value expose their own restart/suspend/resume endpoints under
/v1/postgres/{id} and /v1/key-value/{id}. They are not application service
ids. These actions interrupt datastore connections and can affect every
application that shares the store. See Postgres and
Key Value before performing maintenance.
Diagnose a stalled action
Check the resource status, recent events, and logs. A resume can wait on scheduling, image access, mounted storage, dependencies, or failed health checks. Repeatedly submitting the action does not fix those causes. For a self-hosted instance, distinguish API acceptance from a running operator actually reconciling the requested state.
Use SSH and web shell for authorized inspection of a running instance.
For a temporary public maintenance response without suspending the workload, use maintenance mode.