The clean way to run dev, staging, and prod on Syself Autopilot is one cluster per environment, declared from the same templated Cluster manifest with per-environment values. Because a cluster is a single declarative object, promoting a change from dev to prod is promoting a file, and the environments stay genuinely isolated.

A cluster per environment, not a namespace per environment#

You could separate environments by namespace in one cluster, but separate clusters are the stronger boundary and usually the right call:

• Isolation. A dev experiment that breaks the cluster, exhausts a quota, or takes down the control plane cannot touch prod, because prod is a different cluster with its own control plane and etcd.
• Independent versions. Dev can run a newer Cluster Stack release than prod, so you test the upgrade in dev before prod ever sees it. Namespaces cannot do that; they share one Kubernetes version.
• Independent access. Each cluster has its own credentials and RBAC, so dev access never grants prod access.

Namespaces still have a place for separating teams or apps within an environment; they are just the wrong tool for separating environments.

One templated manifest, per-environment values#

Keep a single Cluster template and a values file per environment, so the three clusters differ only where they should. Kustomize overlays fit this well: a base Cluster and a dev, staging, and prod overlay that patch what changes.

What differs per environment:

• The Cluster Stack release (the version pin, below).
• Machine sizes and counts. Dev runs small and cheap; prod runs the production HA baseline . See Size a cluster for cost for choosing machine types per environment.
• Region, if you place environments differently.

What stays identical: the worker classes, the topology shape, and the network settings. Identical structure is what makes a promotion trustworthy.

Promote a version dev, then staging, then prod#

The core workflow is moving one Cluster Stack release along the environments:

1. A new release lands. Point dev at it (Update within a version or Upgrade to a new Kubernetes version ), and run your tests against dev.
2. When dev is healthy, point staging at the same release and validate under production-like load.
3. Only then point prod at it.

Keep prod pinned to a known-good release while dev tracks the latest. The pin is what stops prod from moving until you decide; dev moving first is what gives you the confidence to move prod.

Isolate credentials and access per environment#

Give each environment its own identity provider groups and RBAC, so a developer with full dev access has read-only or no access to prod. Keep each environment's Secrets, registry credentials, and cloud tokens separate. This is easiest when the environments are separate clusters, because the boundary is structural rather than a namespace label someone could get wrong.

Drive the whole thing from Git so a promotion is a reviewed pull request; see GitOps overview .