Core Concepts

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 deployments table, no /deployments endpoint. It exists wherever Apps share spec.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 — deployment scope 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-app

POST /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 unit

Renaming/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 deploymentArgoCD AppProject
Stored resourceNo — derived from spec.destinationYes — a CRD
Groups bycluster/namespace destinationArbitrary app sets
Access controlrole_bindings at the deployment scopeProject-scoped Casbin roles
MembershipNone (teams/orgs own people)Named project membership

The split is deliberate: teams group people, deployments group apps, bindings connect them.

Limits today

CapabilityStatus
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

On this page