Deployments · Actions

Service actions

Six actions manage a running service: Deploy, Redeploy, Restart, Stop, Start, and Rollback. The difference between them matters — pick the wrong one and you'll either burn a deploy you didn't need or miss the config change you wanted live.

At a glance

Action	When to use it	Picks up env changes?	Pulls new code?	Holds your spherelet capacity?
Deploy	Ship new code	Yes	Yes	Yes
Redeploy	Apply config changes without shipping new code	Yes	No	Yes
Restart	Bounce spherelets to clear runtime state	No	No	Yes
Stop	Take a service offline and free its capacity	—	—	No
Start	Bring a stopped service back online	Yes	No	Yes (re-claims a slot)
Rollback	Restore a previous deploy when something went wrong	No (snapshot from that deploy)	Yes (the older image)	Yes

Across every action, your volumes, custom domains, TLS certificates, and configured environment variables are preserved. Only Delete removes those.

To ship an image you already tested in one environment to another without rebuilding it, use Promote — it runs as a new build on the target environment.

Restart and Redeploy look similar — they aren't

This is the most common foot-gun on every PaaS, ours included.

• Restart bounces your spherelets with the exact configuration that's already running. Useful when something has gone sideways in the runtime — a hung connection, a stuck job, a memory leak.
• Redeploy re-rolls your spherelets with your latest saved configuration. Useful when an external knob changed (autoscaling, networking, or anything you adjusted from the service page outside the Variables tab).

In practice you rarely click Redeploy directly, because saving an environment variable already redeploys (or rebuilds) for you. Use Redeploy when a non-variable setting changed and needs to take effect.

Saving environment variables and secrets

Saving a variable applies it for you. The Apply changes? dialog names the action so it matches what happens:

Change	Button	What happens
A variable the running service reads	Save & redeploy	Your spherelets restart with the new values on the existing build, on the same rolling-update path your other deploys use.
A Build only variable, or a browser-bundle variable (NEXT_PUBLIC_*, VITE_*, …) in the build's scope	Save & rebuild	The value is baked in at build time, so a redeploy can't change it. The save starts a new build that reads the new value, then deploys it.

Save only stores the change without applying it. See Build, runtime, or both for how scopes decide which values reach the build.

If your save doesn't actually change anything — same key, same value as what's already live — nothing happens. The save is a no-op. This protects you from accidentally restarting your spherelets when you've toggled a value back to its original.

If you want to stage multiple variable edits together, make all your edits in the editor and save once at the end. One redeploy (or rebuild), all your changes.

Deploy

Click Deploy to ship new code. ComputeSphere builds your image, starts a new spherelet, waits for it to pass the health check, then routes traffic to it. The previous spherelet keeps serving traffic the whole time.

During a deploy:

• The previous spherelet keeps serving traffic until the new one passes its health check — zero downtime
• Environment variables and secrets are read at spherelet start, so new values take effect on the new instance. Variables scoped to the build are read during the build.
• If the service has a pre-deploy command, it runs once against the new image before any new spherelet starts. If it fails, nothing rolls out.
• Volumes keep their data
• If the build fails, the deploy is canceled. Your running spherelet is untouched.
• Cancel build on the Builds tab stops a build right away — including a running pre-deploy command. Your running spherelet is untouched.

Build time: typically 1–3 minutes. Health check timeout: 60 seconds.

$ csph deploy

Redeploy

Click Redeploy to re-roll your service with your latest saved configuration — same image, latest env variables, latest secrets, current scale. Use this when you've changed configuration but haven't pushed new code.

During a redeploy:

• The current build is reused — no rebuild, and no pre-deploy command
• Environment variables and secrets saved since the last deploy are picked up. Values scoped Build only, and values already baked into the image, don't change until the next build.
• The previous spherelet keeps serving traffic until the new one is healthy — zero downtime
• Volumes keep their data

$ csph services redeploy

Restart

Click Restart to bounce your spherelets with the exact configuration that's running now. Useful when something has gone sideways — a hung connection, a memory leak, a stuck job.

Restart does not pick up environment variable changes made since the last deploy. If you've just changed a variable and want it live, click Redeploy instead.

During a restart:

• The same build runs on a fresh spherelet
• Environment variables and secrets use their last-deployed values, not the latest saved values
• Spherelets are replaced one at a time, keeping at least one serving traffic — zero downtime if your service has more than one spherelet
• Volumes keep their data

$ csph services restart

Stop

Click Stop to take your service offline. ComputeSphere scales your spherelets to zero and returns the spherelet capacity to your account, so you can use it on another service.

Your URL keeps resolving — visitors see a branded page reading "This service is stopped. The owner can restart it from their ComputeSphere dashboard." Your custom domains, TLS certificates, environment variables, secrets, and volumes are all preserved.

During a stop:

• Spherelets scale to zero — no compute work happens
• The spherelet capacity returns to your account's available capacity
• Custom domains, TLS certificates, and configuration are preserved
• Volumes keep their data
• The auto-generated URL and any custom domains return a 503 page with the stopped message
• Cron services stop firing scheduled jobs until the service is started again

$ csph services stop

Start

Click Start to bring a stopped service back online. ComputeSphere claims a spherelet from your account's available capacity, restores your previous spherelet count, applies any environment variable changes you saved while the service was stopped, and resumes serving traffic.

During a start:

• A spherelet is claimed from your account's available capacity
• The previous spherelet count is restored
• Environment variables and secrets saved while stopped are picked up
• The same build runs — Start doesn't rebuild
• Volumes keep their data

If your account doesn't have capacity available — every spherelet in your plan is allocated to another running service — Start will fail with a clear message. Stop another service to free a spherelet, or add capacity to your plan.

$ csph services start

Rollback

Click Rollback to restore a previous deploy. Useful when something you just shipped is broken and you want the previous version back fast, without rebuilding.

Every successful Deploy and Redeploy is automatically saved as a revision — there's nothing to opt into. Open the Deployments tab on your service to see the full history. The current revision is highlighted; older revisions show a Restore button.

What rollback restores

When you click Restore on revision N, your service returns to the configuration captured in that deploy's snapshot:

• The container image from revision N
• Environment variable values from revision N
• Secret variable values from revision N
• CPU and memory shape from revision N (Flex, Standard, or Performance)
• Health-check configuration, command, container ports, and build configuration from revision N
• Cron schedule and entrypoint (for cron services) from revision N

What stays at current values

Rollback is a code-and-config action, not a full system rewind. These keep their current settings:

• Spherelet count. If you scaled to five spherelets after the revision you're restoring, you stay at five.
• Autoscaling rules.
• Custom domains and TLS certificates.
• Persistent volume data and size.
• Account plan and billing.
• Integrations, webhooks, and alerts.
• Git repository binding for autodeploys.

A note on rotated secrets

Because secrets are captured by value in the revision snapshot, rolling back to revision N restores the secret values that were in effect at that point. If you rotated a secret because it was leaked, rolling back to a pre-rotation revision will resurrect the older value. The confirmation modal calls this out. If you've rotated a secret since the revision you're rolling back to, change the secret again after the rollback completes — or pick a more recent revision.

Autodeploy pauses on rollback

If your service is connected to a Git repository for autodeploys, autodeploy is paused after rollback. This protects the rolled-back state from being immediately overwritten by the next push.

The repository configuration section on the service page shows a Autodeploy paused — rollback active. Your next git push won't override revision N notice with a Resume autodeploy button. Click it when you've finished investigating and are ready for new pushes to deploy normally.

Pushes that arrive while autodeploy is paused don't build. Each one is recorded in the service's activity as "Push to <branch> (<sha>) skipped: auto-deploy is paused", so you can see what you'll pick up when you resume. Resuming doesn't build the skipped pushes — push again, or click Deploy.

When rollback won't work

ComputeSphere keeps your last 20 successful deploys. Revisions older than that are pruned by the retention policy and no longer appear in the Deployments tab.

Pre-flight checks may block a rollback when:

• Your service is mid-action. A deploy, restart, or stop is in progress — wait for it to finish, then try again.
• The historical revision needs more resources than your current plan allows. If you downgraded your plan after the snapshotted deploy and the older shape (Standard / Performance) doesn't fit your current capacity, stop another service or upgrade your plan before rolling back.

Rollback flow

1. Open the Deployments tab on your service.
2. Find the revision you want to restore. Each row shows the image, who deployed it, when, and the commit message.
3. Click Rollback on that row.
4. Confirm the action in the modal — it shows the version transition (e.g. v22 → v17) and reminds you that autodeploy will pause.
5. Click Roll back. Your service status moves to Rolling back while ComputeSphere applies the previous configuration.
6. When the rolled-back spherelet passes its health check, traffic shifts and the status returns to Running. The repository configuration section now shows the autodeploy-paused notice.
7. Investigate the issue, then click Resume autodeploy when you're ready to take new pushes again.

The previous spherelet keeps serving traffic until the rolled-back spherelet is healthy — zero downtime when your service has more than one spherelet.

Rollback doesn't run the service's pre-deploy command. It restores the image, not your database — a migration the newer version ran stays applied.

$ csph services rollback --revision <N>

List available revisions first with csph services revisions.

Cron services

Rollback isn't available on cron services yet. The Deployments tab shows the deploy history, but the Restore button is hidden. We'll ship rollback for crons after the web-service rollout. To revert a cron change today, Redeploy from your previous commit.

State reference

A service is always in one state. Most states are transient and resolve within seconds.

State	What it means
Deploying	A new build is starting. Your previous spherelet keeps serving traffic.
Running	Your spherelet is healthy and serving traffic.
Redeploying	Your spherelet is being re-rolled with your latest configuration.
Restarting	Your spherelet is being bounced with the current configuration.
Stopping	Your service is being taken offline and its capacity returned to your account.
Stopped	Your service is offline. Spherelets are at zero. Your URL returns the stopped page.
Starting	Your service is coming back online from Stopped.
Rolling back	Your service is being restored to a previous revision. Your current spherelet keeps serving traffic until the rolled-back one is healthy.
Failed	The last action did not complete. Your previous spherelet is still serving traffic. Fix the underlying issue and run the action again.

If a state lasts longer than 10 minutes, ComputeSphere automatically retries it. If it still doesn't resolve, the state moves to Failed. Your running service is never affected by a stuck action — only the new attempt fails. The recovery path is always "fix the cause and run the action again" — push a fix, edit a variable, free some capacity — not blindly retrying the same broken artifact.

When things go wrong

The deploy failed. Your previous spherelet keeps serving traffic. Open Build logs to see why the build failed — usually a syntax error, a missing dependency, or a failing health check. Fix the cause and click Deploy again.

The service won't start. Check Runtime logs. The most common causes are: a missing environment variable, a port mismatch (your code listens on a different port than your service config), or a failing health check endpoint.

Start failed because your account is at capacity. Every spherelet in your plan is allocated to a running service. Stop another service to free a spherelet, or upgrade your plan to add capacity.

A clicked action looks stuck. ComputeSphere automatically retries any action that lasts longer than 10 minutes. You don't need to click anything — just wait. If the state moves to Failed, look at Runtime logs or Build logs for the cause, fix it, and run the action again.

You double-clicked an action. Clicking Restart, Redeploy, or Deploy twice in quick succession runs as a single operation. We deduplicate within a five-second window.

Rollback failed because the image couldn't be pulled. The container image for that revision was removed from your registry. Push the image again, or restore a different revision that still has its image available. The rollback will surface this through the runtime event stream as an image-pull error.

Rollback was blocked because your service is at capacity. The historical revision needs a larger spherelet shape (Standard or Performance) than your current plan allows. Stop another service to free capacity, or upgrade your plan, then try again.

Your push didn't deploy after a rollback. Autodeploy is paused after a rollback to protect the restored revision. The service's activity shows each skipped push as "Push to <branch> (<sha>) skipped: auto-deploy is paused". Open the service page, find the repository configuration section, and click Resume autodeploy on the inline notice. Then push again.

The build succeeded but nothing rolled out. Check the build for Pre-deploy command output — a pre-deploy command that exits non-zero fails the build before rollout. See When it fails.

An older revision isn't in the Deployments tab. ComputeSphere keeps your last 20 successful deploys. Older snapshots are pruned by the retention policy.

Related

• Environment variables — the full reference for variable and secret storage, including build and runtime scopes
• Pre-deploy commands — migrations and release tasks that run before a new build rolls out
• Promote — deploy a tested image to another environment without rebuilding
• Health checks — what defines "healthy" for the deploy and start flows
• Spherelets — Flex, Standard, Performance shapes and how capacity works on your account