Deployments
The app-grouping unit — a cluster/namespace destination shared by many apps
Deployments
A deployment is a (cluster, namespace) destination pair — the unit Wardn groups apps under, and the boundary RBAC scopes to.
The model
org
└──▶ registered clusters (each with a namespace allowlist)
└──▶ deployments (cluster, namespace) pair
└──▶ Apps whose spec.destination points there- A deployment is derived, not stored — no
deploymentstable, no/deploymentsendpoint. It exists whereverAppssharespec.destination.cluster+spec.destination.namespace. - Multiple apps per deployment — nothing limits how many
Apps target the same pair. That's the intended shape: one namespace on one cluster holds the apps that make up a service. - The namespace is the unit —
deploymentscope means "this namespace on this cluster." Finer (per-app) access isn't a scope — you grant on the whole deployment or on the org.
Where deployments matter
RBAC
role_bindings with scope: "deployment" and scope_id: "cluster/namespace" cover every app targeting that pair:
# Alice gets sync on everything deploying into default on prod-cluster
curl -X POST http://localhost:8080/api/v1/auth/can-i -b cookies.txt \
-d '{"permission":"deployment:sync","scope":"deployment","scope_id":"prod-cluster/default"}'cluster scope covers all deployments on that cluster; org covers everything.
API routes
{namespace} in /apps/{ns}/{name} routes is the destination namespace — the deployment half. A name in a different destination namespace reads as 404:
GET /api/v1/apps/default/my-appPOST /apps validates destination.namespace against the cluster's registered allowlist (403 outside it) — which deployments can exist is a per-cluster decision made at registration.
App spec
spec:
destination:
cluster: prod-cluster # "" = management cluster
namespace: production # the deployment unitRenaming/deleting a cluster changes every deployment rooted on it — apps keep their destination.cluster string, so a removed cluster makes those apps unreconcilable until retargeted.
Deployment vs ArgoCD "project"
Wardn deployment | ArgoCD AppProject | |
|---|---|---|
| Stored resource | No — derived from spec.destination | Yes — a CRD |
| Groups by | cluster/namespace destination | Arbitrary app sets |
| Access control | role_bindings at the deployment scope | Project-scoped Casbin roles |
| Membership | None (teams/orgs own people) | Named project membership |
The split is deliberate: teams group people, deployments group apps, bindings connect them.
Limits today
| Capability | Status |
|---|---|
| Deployments as RBAC scope | ✅ |
| Namespace allowlist per cluster | ✅ — set at cluster registration |
List deployments (GET /deployments) | ❌ — derive by grouping the app list client-side |
| Per-app (below-deployment) RBAC scope | 📋 not planned — namespace is the unit |
Related
- Applications API — the
destinationfields deployments key off - RBAC — deployment scope + permission matrix
- Teams API — the people-grouping half
- Multi-cluster guide — registering clusters + namespace allowlists