Deploy from CI

Everything you can do to an MCP server from the dashboard, you can do from a pipeline. The deploy API is authenticated with an API key rather than a browser session, so a CI runner can drive it without a human present.

This is not the same API with a token on it

Most platforms hand CI a long-lived admin credential and hope. A Statio key acts with the authority of the person who created it and can never exceed it. A pipeline key cannot deploy a server its owner has no rights to, and revoking that person's access revokes the pipeline at the same moment. There is no separate list of machine permissions to keep in step with the human one.

Cutting a release

Bash

curl -X POST \
  -H "Authorization: Bearer $STATIO_KEY" \
  -H "Content-Type: application/json" \
  -H "X-Idempotency-Key: $(uuidgen)" \
  -d '{"force":false}' \
  https://api.statio.dev/v1/servers/$SERVER_ID/releases

Returns a deployment to poll. The build runs in the background: spec fetch, generation, image build, rollout, tool discovery.

The idempotency key matters

Send one on every release. A pipeline step that times out and retries must not start a second build of the same commit. With the key, the retry replays the original response instead of duplicating work.

Watching it

GET /v1/servers/{serverId}/deployments/{deploymentId}
GET /v1/servers/{serverId}/deployments/{deploymentId}/logs

Poll until status reads succeeded or failed. The logs endpoint returns the complete build and deploy output, which is what you want your pipeline to print when a deploy fails, rather than sending someone to a dashboard.

Rolling back

POST /v1/servers/{serverId}/rollback
{"targetVersion": 4}

This redeploys the image already built for that version. It does not rebuild, so you get back exactly what was running before rather than whatever your spec says today. That distinction matters at 2am: a rollback that rebuilds is another deploy wearing an older number.

Warning

Rollback returns your code, not your configuration. Credentials, permissions and outbound allowlists are current-state and are not versioned with the image.

Environments

POST /v1/servers/{serverId}/environments/{environmentId}/deploy
POST /v1/servers/{serverId}/environments/{environmentId}/promote

Deploy to a lower environment, then promote upward. Promotion requires a different capability from deploying: a developer with full deploy rights still cannot promote their own work to production. That separation is enforced by the same roles that govern everything else, not by a second approvals system.

Full reference

Every endpoint, generated from the specification the service actually serves, is in the API reference.