oiyai / docs
Services

Restart a service

Replace allocated compute while preserving service identity, configuration, and workspace.

DEPLOYMENT-DEPENDENT CAPABILITYThe current preview source implements restart across the common service API and clients. It requires an updated control plane and regional gateway; source support alone is not evidence of a completed runtime rollout.

What restart does

Restart releases the existing compute allocation and recreates the service with the same image, command, environment, resource profile, persistent volume, and physical placement. The service ID and endpoint remain stable.

Processes and network connections end. Temporary container files are disposable. Keep important files under /workspace and maintain backups. Restart does not checkpoint process memory or preserve an interactive session.

When to use it

Use restart for a service that has allocated compute and is running, or is in error while still allocated. A paused service uses start/wake, not restart. Busy, deleted, or storage-incompatible states reject restart.

Restart requires a verified account, eligible placement, current pricing, and sufficient balance. It can allocate billable replacement compute. Review active jobs before submitting the action.

Submit the action

POST /api/services/{id}/actions uses authentication and an idempotency key:

{ "action": "restart" }

Do not include resources. Only the resize action accepts a resource object. Restart is not a way to conceal a configuration or size change.

The response is a Service object acknowledging asynchronous work. Inspect the service, events, and application readiness before reconnecting a client.

CLI and Python

The current source-distributed clients support:

oiy restart SERVICE_ID --request-id restart-intent-001
from oiy_ai import Client

service = Client().action(
    "SERVICE_ID",
    "restart",
    idempotency_key="restart-intent-001",
)

Replace SERVICE_ID with the actual UUID. Follow developer setup before using the source packages. MCP clients use oiy_service_action with action: "restart".

Retry an uncertain response

Inspect current state first. Retry the same intent with the same idempotency key and identical body. A new key represents a new request and can trigger another restart. The gateway reconciles an uncertain replacement allocation rather than deliberately tearing it down on every retry.

A manual restart overrides idle-sleep protection and interrupts active work. Activity leases remain during admission and are cleared once the old compute allocation is confirmed released. A continuing external task can register new activity afterward. If a new rate applies, it takes effect only after the old allocation's release is confirmed.

On this page