Deploy

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. Metadata is not received separately because the bundle describes itself — the manifest lives inside the bundle, so a single digest covers code, assets, and config all at once. Receiving it as a separate field would create input the digest does not cover.

Bundle layout (gzipped tar):

runlot.json manifest (required) worker/ worker code. can be omitted for a static site assets/ static assets. can be omitted

Uploading the same digest again creates a new version — a deployment is not "upload this code" but the event "serve this now", and for rollback history to stay readable, each such event has to remain on its own.

When the upload succeeds, the new deployment goes live immediately.

Provenance headers (optional). Since the body is the bundle itself, metadata arrives as headers. The CLI reads the git of the folder it deploys and includes it; if there is no git, it omits them. CP cannot verify these, so they are display-only — they are not grounds for authorization or placement.

X-Runlot-Git-Commit HEAD hash (hex, 7-64 chars) X-Runlot-Git-Message first line of the commit message, percent-encoded (truncated at 200 chars) 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

Moves project_live to an older deployment without creating a new deployment. Since artifacts are immutable, the rolled-back result is exactly the same bytes that were being served at that time.

operationId rollback

Request body: application/json · object