Manage deployments
The Deployments page lists every deploy in your organisation. From each row you can edit it, resize it, attach routes, watch its logs, view its metrics or delete it.
The Deployments table#
Open Deployments. The table covers every project and environment, newest first.
- Deploy
- The deploy name. A Public badge means it's exposed through edge ingress.
- Build
- The build it runs, as
name:tag. - Resources
- The build's CPU and memory, per replica, with a
/replicasuffix when there's more than one replica. Click it to open Adjust resources. - Location
- Where the deploy runs.
- Tenancy
- Inherit, Shared or Dedicated, plus the machine type when the deploy pins its own.
- Replicas
- The replica count. When autoscaling is on it also shows the range, such as
2 (HPA 2–6). - Variables
- A summary of its environment variables, such as
2 vars · 1 secret. - Environment
- The environment it belongs to.
- Created
- When the deploy was created.
Row actions#
| Action | What it does |
|---|---|
| Routes (link icon) | Attach and remove hostnames and path prefixes, and see the CNAME to publish. See Routes and path prefixes. |
| Edit | Opens Edit deploy. See Edit a deploy. |
| Adjust resources | Opens the Resources drawer to change CPU and memory per replica. See Adjust resources. |
| ⋮ → Watch logs | Search and live-tail output from the deploy's replicas. See Logs. |
| ⋮ → View metrics | CPU, memory, network in and out, and restarts. See Metrics. |
| ⋮ → Delete | Deletes the deploy. See Delete a deploy. |
Edit a deploy#
Choose Edit on the row, change what you need, then choose Save deploy.
| Field | Editable |
|---|---|
| Project, Environment | No. They're fixed when the deploy is created. To move a workload, create a new deploy in the other environment. |
| Build | Yes. This is how you roll out a new version or roll back. See Update and redeploy. |
| Deploy name | Yes. |
| Tenancy, Machine type | Yes. |
| Location | Yes. |
| Replicas | Yes, minimum 1. |
| Publicly expose this deploy (edge ingress) | Yes, if the selected build has a container port. |
| Environment variables | Yes: plain variables and secret references. |
Saving keeps the deploy's autoscaling settings as they were. The form doesn't edit them.
Adjust resources#
Choose Adjust resources (or click the Resources value) to open the Resources drawer.
- Change CPU and Memory with the − and + buttons, or click the value to type an exact amount. Quick presets set both at once: Nano (0.125 CPU, 256 MB), Small (0.5 CPU, 512 MB), Medium (1 CPU, 1 GB) and Large (2 CPU, 4 GB).
- The drawer shows the allocation Per replica and the Total across every replica.
- On a shared deploy, memory must stay within 1–4 GB per CPU; changing CPU moves memory into range.
- On a dedicated deploy, requests are capped to what the machine type can fit.
- Only managers and admins can change resources.
Confirming in the Update resources dialog will create an updated build configuration and redeploy this workload. This workload may restart while the new resource allocation is applied. In practice it creates a new build with the same image, tag and port and the new CPU and memory, named with the next version suffix (api becomes api-v2), and points the deploy at it. The original build is kept.
See CPU and memory for units and bounds.
Delete a deploy#
Choose ⋮ → Delete and confirm Delete deploy "name"?. The deploy and its replicas stop running. Its build, and the environment's secrets, stay where they are, so you can deploy again later.