Deployments
Deploy stacks to clusters with status tracking and controls
What you see
URL: /deployments
The deployments page shows every binding between a stack and a cluster. Click any row to open its detail page.
List page
Shows all deployments with status, cluster, and quick actions (deploy, undeploy, delete). Click Create to add a new deployment by selecting a stack and cluster.
Detail page
URL: /deployments/{id}
Full control over a single deployment across five tabs: Overview, Services (compose only), Logs, Ingress, and Backups. See the Deployment Detail page for full documentation.
Header actions
| Action | Description |
|---|---|
| Deploy / Redeploy | Generate K8s manifest and apply to the cluster |
| Restart | Restart the running workload pods |
| Undeploy | Remove K8s resources, keep the deployment record |
| Save as Template | Save current config as a new or updated stack template |
| Delete | Remove the deployment record entirely |
A banner appears when configuration has changed since the last deploy.
Status badges
| Badge | Meaning |
|---|---|
| deployed | Running on the cluster |
| pending | Created but not deployed |
| deploying | Manifest being applied |
| error | Deploy failed |
| undeployed | Previously deployed, now removed |
Compose stack deployments
Deploying a compose stack creates one parent deployment plus child deployments for each non-primary service. The Services tab shows all services. The Logs tab supports per-service log viewing.
LAN access
When a deployment is exposed via NodePort, a LAN access address is shown on the deployment detail page and on the Infrastructure Canvas. This is the direct host:port address for accessing the service from the local network without going through ingress or a gateway.
Pod placement
PodWarden tracks which K8s node each deployment's pods are actually running on. This is visible on the Infrastructure Canvas as red dotted edges from the deployment to the host node. Placement is determined by querying the K8s API for real pod assignments, not just the configured placement preference.
Creating a deployment — node pin
When you create a new deployment from the stack editor's Deployments facet (the create-mode form), a Node select appears next to the cluster selector. It is populated with the schedulable nodes on the selected cluster.
- Default ("any node — scheduler decides"): leave the select at its default. Kubernetes places the deployment on the most suitable available node.
- Pin to a specific node: choose a node name from the list. The deployment is created with
placement.node_nameset to that node, and Kubernetes hard-schedules the workload there.
Cordoned (unschedulable) nodes are excluded from the list. If you want to move a running deployment to a different node, undeploy it, change the node selection, and redeploy — there is no in-place node migration.
How deployments work
- Create a deployment by selecting a stack and cluster
- Configure resources, env vars, ports, volumes on the detail page
- Deploy to generate K8s manifest and apply via kubectl
- Monitor status, view logs, inspect pod health
- Expose with LAN access or ingress rules
- Back up persistent volumes
- Iterate by modifying, redeploying, and optionally saving as template
Related docs
- Deployment Detail -- Tabs and configuration
- Infrastructure Canvas -- Visual topology with pod placement
- Apps and Stacks
- Clusters
- Deployment guide
- Compose Stacks