Deploys

GET /v1/orgs/{orgSlug}/projects/{projectName}/deployments

The newest version comes first. Artifacts are immutable and are never deleted.

operationId listDeployments

POST /v1/orgs/{orgSlug}/projects/{projectName}/deployments

The body is the bundle tarball itself. It takes no separate metadata because the bundle describes itself — the manifest is inside the bundle, so one digest covers the code, the assets and the configuration. Taking separate fields would create an input the digest does not cover.

Bundle layout (gzipped tar):

runlot.json manifest (required) worker/ worker code. Not needed for a static site assets/ static assets. Optional

Uploading the same digest again creates a new version — a deploy is not "upload this code" but "serve this now", and for the rollback history to be readable each of those events has to be recorded.

When the upload succeeds, the new deploy becomes live immediately.

Provenance headers (optional). The body is the bundle itself, so the metadata arrives in headers. The CLI reads the git information of the folder it deploys and sends it; when there is no git it sends nothing. CP cannot verify them, so they are for display only — they are never grounds for authorization or placement.

X-Runlot-Git-Commit HEAD hash (hex, 7–64) X-Runlot-Git-Message First line of the commit message, percent-encoded (cut at 200 characters) X-Runlot-Git-Branch Branch name, percent-encoded X-Runlot-Git-Dirty true|false — whether there were uncommitted changes

operationId createDeployment

Request body: application/gzip · string

POST /v1/orgs/{orgSlug}/projects/{projectName}/rollback

It moves project_live to an older deploy without creating a new one. Because artifacts are immutable, the rolled-back result is exactly the same bytes that were served at the time.

operationId rollback

Request body: application/json · object