Deployments · Lifecycle

Deployments

Trigger, roll out, verify, roll back. Same flow whether you ship from source or a container image.

$ csph deploy

A deployment is one rollout of a service. A service is the long-lived thing you create once; deployments are the history of every push, image bump, and config change against it.

01

What gets deployed

Every deployment ships one of three sources. ComputeSphere auto-detects which you have — csph deploy does the right thing from your repo root without extra flags. The tabs below show what each path produces.

Point at a Git repository — GitHub, GitLab, Bitbucket, or Azure DevOps. ComputeSphere clones it, detects your language and package manager, and builds a container image for you. Pushes to the tracked branch trigger a new deployment automatically.

$ csph deploy --repo github.com/me/api --branch main

Override the auto-detection when you need to:

$ csph deploy --build 'go build -o app .' --run './app'

02

The lifecycle

Every deployment moves through the same five phases. You can watch it live in the console, with csph deployments watch, or via the API.

01 Trigger

git push, csph deploy, API call, or schedule

02 Build

Image built (Git/Dockerfile paths) or pulled (image path)

03 Roll out

New spherelets start; old ones keep serving traffic

04 Health check

New spherelets must pass before traffic shifts

05 Live

Traffic moves to the new spherelets; old ones drain

Zero-downtime by default. The old spherelet keeps taking traffic until the new one passes its health check. If the new one fails, the rollout aborts — the old spherelet keeps running and your service stays available. You don't need to do anything to get this; it's the only mode we ship.

03

Deploy from your terminal

Configuration is per-deploy. Pick the spherelet shape, count, region, and environment variables at the command line — or set them on the service once and let subsequent deployments inherit them.

$ csph deploy --image ghcr.io/me/api:v1 --shape MAX --count 3 --env DATABASE_URL=$DATABASE_URL --env LOG_LEVEL=info

Spherelet shapes. Pick FLX (Flex, 0.25 vCPU / 512 MB), MAX (Standard, 1 vCPU / 2 GB), or PWR (Performance, 2 vCPU / 4 GB). Per spherelet. Multiply by --count for total. Autoscaling can grow --count up to your account capacity; see Scaling.

Environment variables. --env KEY=VALUE at deploy time, or csph services set-env KEY=VALUE on the service. Secret variables (csph services set-secret) add a restartedAt annotation to force a rolling restart when they change.

04

Rollback and history

Every deployment is addressable. List them, inspect one, or roll back instantly. No data is lost — the prior image, build, and config are preserved on the platform side.

$ csph deployments list --service svc_abc

$ csph deployments get dep_xyz

$ csph rollback dep_xyz

A rollback is itself a deployment — it goes through the same five-phase lifecycle and emits a new deployment ID. Old traffic continues until the rollback's new spherelets pass health checks, then traffic shifts. The "broken" deploy stays in your history; nothing is destroyed.

When deployments fail

Build fail

Compile error or missing dependency. The previous deployment keeps serving traffic. Check build logs in the console or via csph logs --build.

Image pull fail

Wrong registry credentials or non-existent tag. Confirm csph services set-registry was run, and that the tag exists.

Health check fail

New spherelets started but didn't pass their /healthz probe in the configured window. Traffic stays on the old spherelets; the rollout aborts.

Out of memory

Spherelet OOM-killed during startup. Step up a shape (Flex → Standard → Performance) or reduce memory pressure in your image.

Next

• Custom domains — bring your own hostname; ComputeSphere issues and renews TLS
• Autoscaling — let spherelet count grow with CPU load, capped by your account capacity
• Observability — request rate, latency, error rate, and spherelet CPU/memory out of the box
• Concepts — account, project, environment, service, spherelet, deployment