Operator and project
About Stella Ops
Stella Ops proves what is running in every environment, why it was allowed there, and whether that proof still holds.
A self-hosted release control plane for container estates outside Kubernetes: Docker Compose, SSH/WinRM hosts. Two input pillars — Vulnerabilities and Deployment — joined into one output: Proof.
Product status: v1.0-RC1, release candidate.
Two pillars, one output
Vulnerability evidence and deployment history usually live in separate tools. Stella Ops records both against the same immutable image digest, so every release decision can be traced, exported, and re-checked. Digest-firstRelease identity based on immutable content hashes (SHA-256 digests) rather than mutable tags — ensuring byte-identical deployments
SBOMSoftware Bill of Materials - a complete list of all packages and dependencies in your software inventory, advisory matching, VEXVulnerability Exploitability eXchange - machine-readable statements about whether vulnerabilities are actually exploitable in your context statements, and reachability evidence for every image digest.
Promotions, approvals, and rollbacks across environments — recorded against the digest that ran, not the tag.
Signed, replayable verdicts and exportable evidence. Re-run a decision later and the same inputs yield the same answer.
The custody spine
- Source
- Build
- Scan
- Verdict
- Decision
- Deploy
- Watch
Each stage carries one of three states: MISSING, RECORDED, or SIGNED. A gap in the chain stays visible as a gap.
Developed in Europe, Swiss-hosted
Stella Ops is developed in Europe; our own infrastructure is hosted in Switzerland. This website and the Stella Ops brand are operated by a company registered in Bulgaria — see the legal notice for full operator details. The product is built for operators who need release evidence to stay inside their own boundary, under their own keys, on their own infrastructure.
The operating company is registered in Bulgaria, in the European Union. Our own services are hosted in Switzerland, which holds an EU adequacy decision; no US-headquartered vendor sits in your supply chain.
You run the control plane on your own infrastructure. There is no mandatory external control plane.
Core operations work disconnected. Advisories and updates arrive as signed bundles you verify before import.
What makes it different
Every release decision is sealed with its inputs. Re-run it months later and verify the verdict is identical.
Evidence and audit →
The control plane keeps comparing the running digest against the approved digest. A mismatch means an unapproved or altered image — flagged, not assumed away.
Estate and drift →
Uncertainty is tracked and budgeted, not hidden. A stage with no evidence reports MISSING and stays on the ledger until it is answered.
Reachability →
Air-gapped installs run the same decisions as connected ones. Feeds and updates travel as signed bundles.
Sovereign and air-gap →
Who it is for — and who it is not
Teams deploying containers with Docker Compose, on SSH/WinRM hosts, who need to show why each release was allowed. Most teams already have scanners and CI; Stella Ops adds the control plane that turns them into one verifiable release process.
Kubernetes-only teams that already run a mature evidence chain from build to production. Stella Ops is built for estates outside Kubernetes that need stricter release control.
Source-available under BUSL-1.1
The code is source-available under the Business Source License 1.1. You can read it, build it yourself, and check that the product does what this site says. The free tier covers 3 environments and 999 new-digest scans per rolling 24 h.
Contact and responsible disclosure
For security-sensitive contact and vulnerability reporting, follow the process in /security/. Keys for signed mail and verification are pinned at /keys/.
For general discussion and support channels, email hello@stella-ops.org.