Skip to main content

Production Deployment Model designed

This page explains how GPUaaS is intended to reach production. It is not only a list of controls; it is the deployment and promotion model security and ops should review.

Environment Path​

Layered Production Shape​

Current reality:

  • kind and dev-control are active delivery environments;
  • demo and staging are the next repeatable production-like steps;
  • production should reuse the same automation and profile model, not a separate hand-built deployment path.

Production Shape​

The intended production deployment model is:

LayerProduction intent
EdgeCloudflare or equivalent managed edge, TLS, WAF, controlled host routes
Control planeKubernetes-based deployment model closer to the current RKE2/staging direction
IdentityHA IdP posture with realm drift/recovery evidence
Data servicesDurable Postgres, Redis, NATS, Temporal, backups, restore proof
Runtime accessManaged route families for browser/API paths plus controlled terminal gateway
Secrets and PKIRuntime secret manager, service identity, certificate lifecycle
Observabilitylogs, metrics, traces, alerts, correlation, release evidence

Deployment Principle​

Production should be config-driven and repeatable:

  • same automation, different environment profile;
  • same artifact digests validated by CI;
  • same UAT and evidence model promoted across environments;
  • no hidden production-only shell steps.

Promotion Model​

Promotion is not “build once and hope.” It is:

  1. CI proves contract/build/test/security posture;
  2. environment automation renders the target profile;
  3. UAT/security/staging prove behavior in production-like conditions;
  4. release evidence packet captures SHA, digests, approvals, residual risk, rollback, and environment readback;
  5. production rollout proceeds through rings and reserve posture.

Promotion As Environment Progression​

Deployment Responsibilities​

Rings and Capacity​

Production needs reserve capacity and staged rollout.

RingPurpose
Ring 0Internal or platform-only validation
Ring 1UAT/security or tightly controlled canary
Ring 2Production canary
Ring 3Broad production
Ring 4Sensitive or specially governed tenants

This matters more for GPU nodes and node-agent or runtime changes than for a simple web-only service.

What Security and Ops Should Review​

ConcernWhat the page should answer
Is production a different architecture?No. It is the same product model with stronger environment controls and evidence gates
Can we recreate staging and production from config?That is the intended operating rule
Are rollout and rollback explicit?Yes: profile rendering, promotion gates, rings, reserve, restore, and evidence
Are edge, identity, data, and runtime boundaries named?Yes: they are separate layers, not implied implementation details
Can reviewers find what is still missing?Yes: staging evidence, GitOps/promotion maturity, reserve/rings, and full production-like validation remain visible gaps

Current Gaps That Still Matter​

  • dedicated UAT/security and staging/pre-prod proof still needs to mature;
  • progressive delivery and ring enforcement need more runtime-level automation;
  • production evidence must become first-class for release decisions;
  • secrets/PKI, east-west controls, and identity HA posture must be proven in production-like environments, not only kind/dev.

Why This Helps Reviews​

Security and ops reviews go badly when they only see feature pages and control lists. They need one place that explains:

  • what production is supposed to look like;
  • how promotion works;
  • how rollback works;
  • what is already implemented versus still planned.

This page is that bridge.

Canonical sources