Services
A service is a container the platform runs and keeps running: an MCP server that gives your agents tools, a retrieval endpoint they ground against, an internal API of your own. You supply an image and per-replica CPU and memory, and the platform schedules it, restarts it when it exits, maintains the replica count, probes it for readiness, and makes it reachable at a stable address. Each service reports as Healthy, Degraded, or Failed, and the Replicas tab is where you find out which replica is responsible.
Configuring a service
Configuration is split into sections, shown as a form or as YAML.

Identity. The service name, set at creation and fixed after.
Image. The container image to run, either one pushed to the project's registry or an external one.
Resources & Scaling. CPU and memory per replica, and whether the replica count is fixed or autoscaled.
Networking. The port the container listens on, whether it is publicly reachable, and how readiness is checked.
Environment & Secrets. The configuration and credentials passed to the container.
Schedule. When the service runs.
Revisions and deploying
Every deploy creates a revision. The panel on the left lists them, with the live one marked Deployed and everything before it Superseded. Compare Revisions shows what changed between any two, and Go to logs opens the Logs page with this database already selected. See Logs under Governance.
Editing a service edits what is running. There is no draft state the way there is for an agent, so Deploy changes takes effect immediately. The safety net is revisions rather than drafts: deploy, then compare or roll back if the change misbehaves. Restart cycles the service without touching its configuration.

Open an older revision and the view goes read-only, offering Restore and deploy instead. Restoring promotes that revision's image, environment, secrets, and schedule back to the live configuration.
Whether you can deploy depends on your role in the project. Without the permission the configuration is readable but not editable, and project roles are managed from the organization level.
Replicas
Replicas is read-only. Each replica shows its status, age, and requested CPU and memory, and opening one gives diagnostics: restart count, limits, health check state, last termination, and recent events. That is where you look when a service is unhealthy and you need to know whether it crashed, was killed, or never started.
Services can also be managed from the command line, including declaratively from a stack file. See the CLI documentation for iai services.
Last updated
Was this helpful?

