dev, staging, prod trio, plus any regional, customer-specific, or role-specific environments you add.
The distinction between static and preview environments is whether they’re meant to stick around:
| Static | Preview | |
|---|---|---|
| Lifetime | Persistent | Ephemeral |
| Overlay | Base + per-env patches | deploy/overlays/ephemeral |
| Readiness monitoring | Tracked | Excluded |
| Global AutoDeploy | Supported | Not applicable |
| Namespace on delete | Preserved | Removed |
Creating static environments
See the main Environments overview for the create dialog walkthrough, including:- Cluster and namespace selection
- Labels for grouping and filtering
- Cloning deployment configuration from a source environment (strategy, resources, autoscaling, health checks, ArgoCD config)
Common static environment setups
Single cluster, multiple environments by namespace — the classic: one cluster withdev, qa, staging, prod namespaces. Simple, cheap, good for small teams. Enable environment name prefix if you want to collapse this further into a single namespace.
Per-environment cluster — each environment gets its own cluster. Better isolation, higher cost. Common for regulated workloads where prod must be on a separate network.
Regional fleet — multiple regional environments (us-east, eu-west, ap-southeast) deployed to regional clusters. Use labels to deploy to all of them at once (e.g. region:prod label on every production regional environment).
Customer-specific — per-customer environments, each with its own cluster or namespace, labeled by customer. Label-based deployments let you roll out to every customer or a specific customer cohort.
Deploying to a static environment
Clicking a static environment in the sidebar opens the environment deployment page — the same page used for preview environments. See Deploying Services for the deploy flow.Production readiness and static environments
Production Readiness Checks only apply to static environments. When enabling readiness for a service, ephemeral environments are filtered out of the selection dialog — readiness scores wouldn’t be meaningful on a 24-hour preview anyway.Best practices
- Clear naming — stick to lowercase-and-hyphens (
dev,staging,prod-us-east) so names work as Kubernetes namespaces and DNS labels without mangling. - Labels over sprawl — as the fleet grows, consistent labels (
region:us-east,role:prod,team:payments) save you from writing per-environment rules. - Clone when adding siblings — cloning deployment strategy, resources, autoscaling, and health checks keeps new environments consistent with existing prod-like environments without retyping.
- AutoDeploy on dev, not prod — enable AutoDeploy on
devso every commit lands automatically. Keepstagingandprodmanual (or gated through PR reviews) so rollouts are deliberate.