Environments

UDS Core runs consistently from a developer laptop to a classified production enclave. The same packages, policy baseline, and observability stack travel across every environment — only cluster-level configuration changes.

Typical Environment Tiers

Environment	Typical Purpose	Typical Cluster
Local / Dev	Inner-loop development and package testing	k3d
CI / Test	Automated integration and end-to-end testing	k3d
Staging	Pre-production validation, config parity with prod	EKS, AKS, RKE2, or any CNCF-conformant distro
Production	Mission workloads, real users, compliance scope	EKS, AKS, RKE2, or any CNCF-conformant distro

Tip

For local development, Defense Unicorns publishes two pre-built bundles: k3d-core-slim-dev (Base + Identity & Authorization — lightweight, fast startup) and k3d-core-demo (Full Core — full-fidelity local environment). Both use the upstream flavor.

What Varies Between Environments

Cluster-level configuration is the primary dimension that changes across environments:

• Cluster identity — name and tags
• Domains & TLS — tenant and admin domains, custom CA certificates
• External integrations — database endpoints for Keycloak/Grafana HA, external object storage for Loki/Velero

What Stays the Same

Across every environment tier you deploy the same packages at the same version, the same policy baseline (Pepr policies, Istio authorization), and the same observability stack (Prometheus, Loki, Grafana). This consistency closes the gap that other platforms leave between dev and production — if it works in dev, it will work in staging and production. The only variables are cluster-level config, not the platform itself.

Danger

Don’t skip staging. Configuration differences between environments are the most common source of production issues, and local dev won’t surface them. A staging cluster with production-parity config catches problems before they reach real users.