Deploys.app Docs

Deployments overview

A deployment is a running workload. Each one has a name, an image, a few knobs (resources, port, environment), and a single screen in the console where everything about it lives.

What you see in the list#

The Deployments page lists every workload in the current project — across all locations — with its type, memory request, replica range, location, and the timestamp of the last successful rollout.

console.deploys.app/deployment?project=acme
Deployment list in the consoleDeployment list in the console
Five deployments in the acme project — two web services, two workers, and a cron job — each in the same location.

The leading icon shows status at a glance:

  • Green check — the latest revision rolled out and pods are healthy.
  • Yellow pause — the deployment is paused; existing pods stop and traffic returns 503.
  • Spinning arrow — a rollout is in progress.
  • Red cross — the rollout failed; the previous revision keeps serving.

The deployment detail page#

Clicking a deployment opens its dashboard. The same screen serves five tabs:

  • Metric — live CPU, memory, request rate, and egress charts.
  • Details — the full configuration the deployment was rolled out with.
  • Revision — the rollout history, with a one-click rollback for each.
  • Logs — a live stream of container stdout/stderr.
  • Events — the Kubernetes events behind the scenes (useful when something refuses to start).
console.deploys.app/deployment/detail?project=acme&location=gke.cluster-rcf2&name=web
Deployment detail screen showing URL, image, resources, and replicasDeployment detail screen showing URL, image, resources, and replicas
Every fact about a running workload — public URL, image tag, resources, env groups — in one place.

Two actions hang off the top right:

  • Deploy New Revision — opens the deploy form pre-filled with the current configuration. Submit it and the new revision rolls out alongside the old one with health-checked traffic shifting.
  • Pause — stops the workload without deleting it. Resume restores it from the same revision. Useful for cost control on staging or for emergency stops.

The rollout lifecycle#

A successful deployment passes through three states the console surfaces:

  1. PendingThe new revision is being scheduled. Pods are pulling the image and starting up. The previous revision keeps serving traffic.
  2. HealthyReadiness checks pass on the new pods. Traffic begins shifting onto the new revision. The deployment status icon turns green.
  3. Steady-stateThe new revision is the only one serving. Autoscaling continues in the configured replica range. Metrics flow into the dashboard and usage to billing.

If readiness never passes, the rollout fails and the previous revision keeps serving — you don’t get a broken deployment because of a bad image.

How to drive it#

Anything you can do from this page, you can do from the CLI or API. The console, CLI, and API all hit the same backend.

# list deployments in a project
deploys deployment list --project acme

# get the full config of one deployment
deploys deployment get --project acme --location gke.cluster-rcf2 --name web

# pause a deployment
deploys deployment delete --project acme --location gke.cluster-rcf2 --name old-worker
NoteFor each command above the equivalent API call is POST https://api.deploys.app/deployment.<verb> with the same fields as JSON. See the API overview.
On this page