Reliability
ComputeSphere is built so that the obvious failure modes — bad deploy, dead spherelet, platform maintenance — don't take your service offline. Four behaviors do most of that work, and they're on for every account, every tier, every deploy.
New spherelets boot. Traffic stays on old.
New pass health checks. Traffic moves over.
Old spherelets drain and exit.
The four behaviors
| What it means | |
|---|---|
| Zero-downtime deploys | New spherelets must pass health checks before old ones drain. No window where traffic has nowhere to land. |
| Health-checked rollouts | If new spherelets fail, the rollout halts and old ones keep serving. You get notified. |
| Immutable deployments | Every deploy is a snapshot. Rollback redeploys an old snapshot in under five seconds — no rebuild. |
| Multi-spherelet HA | Run two or more spherelets so a single restart isn't a brief outage. |
Zero-downtime deploys
Every change — first push, code update, env-var edit — rolls out the same way:
- New spherelets boot with the new image and config.
- Each one must pass its health check before joining rotation.
- Old spherelets drain only after the new ones are confirmed healthy.
- If new spherelets fail their health check, the rollout halts. Old spherelets keep serving. You're notified.
There's no flag for this. Every rollout works this way, on every tier.
Health checks
Your service is responsible for telling ComputeSphere when it's ready to serve.
- Liveness — is the spherelet alive? An unresponsive endpoint triggers a restart.
- Readiness — is the spherelet ready to handle a request? A spherelet that's alive but still warming a cache or opening a database connection should report not-ready until it's actually serving.
Web services get a basic HTTP health check by default. To tune the path or expected status code, see Health checks. Background workers and cron jobs have no inbound traffic, so liveness uses a process signal instead.
Rollback
Every deployment is immutable. Old deployments stay attached to the service. To roll back:
- Open the service's Deployments tab in the console.
- Find the version you want.
- Click Redeploy.
The image is already built — no rebuild required. Rollback typically completes in under five seconds. See Service actions for the full lifecycle.
Multi-spherelet HA
A service running on a single spherelet is a single point of failure. Even with zero-downtime deploys, you'll see brief restart windows during platform maintenance or when a spherelet gets rescheduled.
When brief unavailability isn't acceptable:
- Run at least 2 spherelets. Maintenance rolls one at a time; the other carries traffic.
- Turn on auto-scaling if your load varies. Set a minimum of 2 and a maximum bounded by your account capacity.
- Handle
SIGTERMgracefully. Your spherelet has ~30 seconds to finish in-flight requests before termination — drain the queue, close connections, exit clean.
Honest limits
- Single-spherelet services aren't HA. Two-spherelet minimum is the smallest configuration with no observable restart blip. Anything less is best-effort.
- In-flight requests on a draining spherelet have ~30 seconds. Long-running uploads or streams that exceed that window get cut. Move them to a background worker or a cron job if completion matters more than the request boundary.
- Health checks are how you opt into safety. A broken health-check endpoint that always returns 200 will mark a broken spherelet as healthy and break your rollout. Test the failure path.
- Rolling back rolls back code, not data. If your deploy ran a destructive migration, redeploying the old image won't undo it. Migrations are forward-only by default.
Targets vs guarantees
Operational targets and the formal SLA are on the SLA page. Live status is at status.computesphere.com.