Stella Ops Suite — two-minute overview

Stella Ops is a self-hosted release control plane for non-Kubernetes container estates. Its promise is to help a team using existing CI deliver a governed release, recover safely and prove the decision later, including offline.

Direction accepted 2026-09-30. This overview describes the intended outcome. The capability matrix records dated source checks, and the governed release program records the remaining implementation and deployed acceptance work.

The customer problem to validate

A team may have useful build, scan, approval and deployment tools while still reconstructing the relationship between their records by hand. The product opportunity is a dependable chain from the exact artifact and risk decision to authorized delivery, observed target state, recovery and independent proof. Customer pilots must establish whether this gap matters enough to adopt and operate Stella.

The complete journey

Step	Required result
Prepare	A real CI artifact and its immutable digest, service/release identity, configuration and intended environments/targets.
Decide	Explainable policy and risk result, with input versions, VEX/reachability coverage and explicit unknown, stale, missing or unavailable evidence.
Authorize	Correctly scoped approval for the exact revision; exception, signing and deployment grants remain distinct.
Deliver and recover	Actual target observations with a named observer, plus safe interruption/retry/rollback handling. Dispatch alone does not establish completion.
Prove and reassess	Durable proof of the finalized decision, independent offline verification, and current risk shown alongside unchanged historical evidence.
Operate	Supported installation, upgrade, restore and maintenance within the customer’s trust/connectivity constraints.

Who uses it

Contributors request changes for owned services. Security managers investigate and explain risk. Operators deliver and recover releases. Assurance viewers inspect and verify records. Access administrators establish trust, connections and scoped permissions. See the role contract.

First proof of value

The first acceptance profile is one Docker/Compose estate, two environments, actual targets and an application with at least two components, inside one operator trust boundary. The four release roles use real restricted sessions. The acceptance matrix includes negative controls, recovery, changed risk and offline proof. This selected profile does not withdraw other verified capabilities.

Measure role completion, first-delivery time, block explanation, recovery, independent evidence verification and operating effort. Reachability support alone does not establish exploitability; regional crypto support does not establish certification; a source-wired endpoint does not establish a completed customer journey.

Scope and commercial terms

Keep existing CI and standard evidence formats. Prioritize a complete release journey before new discovery, framework scoring, analytics or federation expansion. Self-hosted/offline operation and operator-controlled custody remain constraints. Shared SaaS hosting for unrelated adversarial tenants is outside the current architecture.