Deployment lifecycle
The dashboard shows three statuses:
| Status | Description |
|---|
| Deploying | Image is being pulled and the enclave is booting |
| Running | Container is live and serving traffic |
| Failed | Something went wrong — check your config, image, and secrets |
Blue-green updates
By default, redeploying a container causes a brief window of downtime
while the old version stops and the new one starts.
If you need to avoid that, use a blue-green update instead.
Blue-green deployments run both versions simultaneously:
If the new version fails, the update is canceled and the current version keeps running.
No downtime and no rollback required.
For production containers where uptime matters, use blue-green updates
instead of direct redeployment. See the
production checklist for more recommendations. Starting an update
- Find your container in the Active tab
- Click Update
- Select the new Git tag to deploy
- Click Start Update
The current version keeps serving traffic while the new version boots up.
Update statuses
| Status | Description |
|---|
| Pending | New version is being deployed |
| Started | New version’s enclave is running, health checks in progress |
| Ready | New version is healthy and ready to accept traffic |
| Failed | New version failed to start |
Multi-GPU containers
Blue-green updates require running both the old and new versions at the same time.
Multi-GPU containers (8 GPUs) use all available GPUs on the host, so there are no
free GPUs to start a second copy.
Instead, multi-GPU updates stop the current deployment before starting the new one.
This means there is downtime during the update — typically while the new enclave
boots and loads your model. DNS records are kept in place during the transition so
clients reconnect automatically once the new version is ready.
The dashboard shows a two-phase progress indicator: stopping the old deployment,
then deploying the new one. If the new deployment fails, the container is left in a
failed state and you can retry or redeploy.
If you need zero-downtime updates for multi-GPU containers, you can pay for
additional GPUs to run both versions simultaneously during the transition.
Redeploying
Use Redeploy to re-launch a container with the same or modified configuration.
This is useful when:
- You’ve updated secrets and need the container to pick up new values
- A deployment failed and you’ve fixed the underlying issue
Clicking Redeploy opens the deploy form pre-populated with the
container’s current config. You can change the Git tag, SSH keys
(for debug containers), or other settings before submitting.
Using templates
Click Template on any existing container to copy its configuration into
the deploy form. This creates a new, independent container with the same
settings pre-populated. This is useful when you need to deploy multiple containers
with the same configuration.
Deleting a container
Click Delete on a container to permanently remove it. This:
- Stops the running enclave
- Cancels any in-progress update
- Deletes the container’s secret bindings
- Removes the container from your org
Deletion is irreversible. The container’s configuration, secret bindings,
and environment variables are permanently removed.
