Skip to content
SKESKE

Deployments

A compute deployment packages your application, pushes an immutable image to your cloud provider’s container registry, provisions infrastructure, and activates the new version. A static-site deployment builds the site locally or in CI, uploads its output, and publishes an immutable version that can be rolled back to without rebuilding.

Deploy

Section titled “Deploy”
Terminal window
ske deploy
Deployment 7246183051948032011 initialized.
Building image (linux/arm64)...
  #1 [internal] load build definition from Dockerfile
  ...
Image pushed.
Uploaded 128 assets.
Deployment 7246183051948032011 started.


[stack]       Stack ready
[function]    Functions updated
[alias]       Traffic switched
Deployment succeeded (sequence #42) in 2m 41s


  Application URL: https://abc123.execute-api.us-east-1.amazonaws.com

The Docker build’s own output is printed as it runs, and the [stage] lines are the deployment’s progress, reported by the API.

The application URL is the environment’s URL at your cloud provider: API Gateway for AWS compute, CloudFront for AWS static sites, Cloud Run for GCP compute, and Firebase Hosting (web.app) for GCP static sites. Domains covers serving it from your own domain.

The deployment pipeline for an application:

  1. Init — creates the deployment and gets registry credentials and the runtime’s generated Dockerfile from the API
  2. Check Docker — verifies Docker is available locally
  3. Build — builds the image from the generated Dockerfile, joined with your ske/Dockerfile if there is one
  4. Push — pushes the image to ECR (AWS) or Artifact Registry (GCP)
  5. Upload assets — copies the public directory out of the image and uploads its files for CDN delivery
  6. Confirm — hands the deployment to the API
  7. Poll — prints the deployment’s progress until it ends

Static-site deployments (early access)

Section titled “Static-site deployments (early access)”

A static site needs no Docker. The same ske deploy command runs the environment’s build command locally or in CI, with its build variables, and uploads the output directory. The selected framework preset controls SPA fallback, static page routing and cache headers.

On GCP, first enable Firebase Hosting on the connection. Each environment has its own Firebase Hosting site and default HTTPS web.app URL, with no network requirement. The CLI uploads through signed URLs into private GCS staging; SKE transfers the files to Firebase, finalizes the immutable version, and publishes it. Staging files are cleaned up after finalization. Cloud credentials remain on the server.

A failed build, upload or version preparation leaves the previous release live. Rollback publishes a retained version without running the build again. Adding custom domains does not replace the default provider URL in dashboard links or deploy output.

Deployment status

Section titled “Deployment status”
Terminal window
ske status
Latest deployment: 7246183051948032011
Type:   deploy
Status: succeeded
By:     [email protected]

Listing deployments

Section titled “Listing deployments”
Terminal window
ske deploy list
ID                   TYPE      STATUS     INITIATOR        CREATED
7246183051948032011  deploy    succeeded  [email protected]  2026-09-20T14:30:12.000000Z
7245860719322145803  rollback  succeeded  [email protected]  2026-09-19T09:15:40.000000Z
7245517348101873667  deploy    succeeded  [email protected]   2026-09-18T16:00:03.000000Z
7245207731180494857  deploy    failed     [email protected]  2026-09-18T15:45:27.000000Z

Use --limit to control how many results to show:

Terminal window
ske deploy list --limit 5

Deployment details

Section titled “Deployment details”
Terminal window
ske deploy show 7246183051948032011

Shows full deployment details including the build and provisioning output log.

What a deployment records

Section titled “What a deployment records”
  • Its number. Each deploy gets the environment’s next number (#42) as soon as it starts, and keeps it if it fails.
  • Where it came from: dashboard, cli (the CLI signed in as you), ci (an API token, the CLI’s in CI included), mcp, or system (SKE itself, such as a service’s env sync).
  • Whether it is live. Rolling back to the deployment that runs now is refused, since it would change nothing.

When a deploy fails

Section titled “When a deploy fails”

A compute deploy updates the environment’s stack before it switches traffic, and a failure after that doesn’t undo the stack update. The deploy’s output then says which stack changes stayed in place, or that it made none. Traffic stays on the previous release.

While a deploy runs, SKE checks on each step every 15 seconds at first, then every 30 seconds, then every minute for slow steps such as a CDN update or long deploy hooks.

In this section

Section titled “In this section”

Privacy PolicyTerms of Service