18 KiB
18 KiB
Stella Ops Suite card
What Stella Ops Suite is
Stella Ops Suite is a centralized, auditable release control plane for non‑Kubernetes container estates. It sits between your CI and your runtime targets, governs promotion across environments, enforces security + policy gates, and produces verifiable evidence for every release decision—while remaining plug‑in friendly to any SCM/CI/registry/secrets stack.
What it does
- Release orchestration (non‑K8s): UI-driven promotion (Dev → Stage → Prod), approvals, policy gates, rollbacks; steps are hook‑able with scripts (and/or step providers).
- Security decisioning as a gate: scan on build, evaluate on release, and re‑evaluate on vulnerability intelligence updates without forcing re-scans of the same artifact.
- OCI-digest first: treats a release as an immutable digest (or bundle of digests) and tracks “what is deployed where” with integrity.
- Toolchain‑agnostic integrations: plug into any SCM / repo, any CI, any registry, and any secrets system; customers can reuse what they already run.
- Auditability + standards: audit log + evidence packets (exportable), SBOM/VEX/attestation-friendly, standards-first approach.
Core strengths
- Non‑Kubernetes specialization: Docker hosts/Compose/ECS/Nomad-style targets are first-class, not an afterthought.
- Reproducibility: deterministic release decisions captured as evidence (inputs + policy hash + verdict + approvals).
- Attestability: produces and verifies release evidence/attestations (provenance, SBOM linkage, decision records) in standard formats.
- Verity (integrity): digest-based release identity; signature/provenance verification; tamper-evident audit trail.
- Hybrid reachability: reachability-aware vulnerability prioritization (static + “hybrid” signals) to reduce noise and focus on exploitable paths.
- Cost that doesn’t punish automation: no per-project tax, no per-seat tax, no “deployments bill.” Limits are only: (1) number of environments and (2) number of new digests analyzed per day.
Why Stella wins vs competitors (in one line each)
- CI/CD tools (Actions/Jenkins/GitLab CI): great at running pipelines, weak at being a central release authority across environments + registries + targets with audit-grade evidence and security decisioning as a gate.
- Deployment tools / CD orchestrators (Octopus/Harness/Spinnaker/CloudBees): strong promotions, but security depth (reachability, attestations, continuous re-evaluation) is often bolt‑on, and pricing often scales poorly (projects/services/users).
- Docker registries / artifact platforms (Harbor/JFrog/Docker registry ecosystems): can store + scan images, but don’t provide a release governance control plane (promotion workflows, approvals, policy reasoning, deploy execution across targets).
- Vulnerability scanners / CNAPP (Trivy/Snyk/Aqua/Anchore/etc.): can scan well, but do not provide release orchestration + promotion governance + deploy execution with a single evidence ledger.
Feature table: Stella vs “typical” alternatives (detailed)
Legend:
- Native = built-in, first-class
- Partial = exists but not release-centric / limited scope
- Via integration = possible but not owned end-to-end
- N/A = not a focus of that tool category
- Varies = depends heavily on vendor/edition/plugins
| Feature area | Stella Ops Suite (Release + Security Control Plane) | CI/CD tools (Actions/Jenkins/GitLab CI) | CD/Deploy orchestrators (Octopus/Harness/Spinnaker) | Registries / artifact platforms (Harbor/JFrog/Docker) | Scanners / CNAPP (Trivy/Snyk/Aqua/Anchore/etc.) |
|---|---|---|---|---|---|
| Primary abstraction | Release by OCI digest + environment promotion | Pipeline run / job | Release / deployment pipeline | Artifact/image repo | Scan report / project |
| Non‑K8s container focus | Native (Docker/ECS/Nomad style) | Partial (scripts can deploy anywhere) | Partial (often broad incl. K8s) | Native for registries; not deploy | N/A |
| Environment model (Dev/Stage/Prod) | Native (envs are first-class) | Partial (vendor-dependent env tracking) | Native | Partial (some repos have “projects,” not env) | N/A |
| Promotion workflow (Dev→Prod) | Native | Via integration / custom pipeline | Native | N/A | N/A |
| Approvals / manual gates | Native | Partial (manual steps exist) | Native | N/A | N/A |
| Separation of duties (policy) | Native (policy-driven) | Partial / varies | Partial / varies | N/A | N/A |
| Freeze windows / release windows | Native (policy-driven) | Varies | Varies | N/A | N/A |
| Deployment execution to targets | Native (agents + target adapters) | Via scripts | Native | N/A | N/A |
| Rollback / redeploy same digest | Native | Via scripts | Native | N/A | N/A |
| Target inventory (hosts/services) | Native | N/A | Partial (depends) | N/A | N/A |
| Scriptable step hooks | Native (hooks everywhere) | Native (pipelines are scripts) | Native/Partial (often supported) | N/A | Partial (hooks in CI) |
| Pluggable connectors (SCM/CI/registry) | Native design goal (reuse customer stack) | N/A (they are the CI) | Partial | Partial | Partial |
| Registry-neutral operation | Native (works with any registry; can reuse) | Via scripts | Via integration | Registry-centric | N/A |
| Release gating based on security | Native (scanner verdict is a gate) | Via integration | Via integration | Partial (policy usually at pull time) | N/A (scanner doesn’t deploy) |
| Scan timing: build-time | Native (CI integration) | Via integration | Via integration | Partial | Native |
| Scan timing: release-time | Native (gate uses cached evidence) | Via integration | Via integration | Partial | Partial |
| Scan timing: CVE update re-evaluation | Native (continuous re-eval) | Rare / custom | Rare / custom | Partial (platform dependent) | Varies (often supported) |
| New-digest accounting (don’t charge for redeploys) | Native (digest-cache first) | N/A | N/A | N/A | Varies |
| SBOM generation | Native | Via integration | Via integration | Partial | Native/Partial |
| VEX support (clarify not-affected/fixed) | Native (standards-first) | Via integration | Via integration | Partial | Varies |
| Reachability analysis | Native (incl. hybrid reachability) | Via integration | Via integration | Rare | Varies (often not reachability) |
| Hybrid reachability (static + optional runtime signals) | Native | N/A | N/A | N/A | Rare |
| Exploit intelligence / prioritization (KEV-like, etc.) | Native / planned (as decision inputs) | Via integration | Via integration | Partial | Varies |
| Backport / fix verification | Native / planned (noise reduction) | N/A | N/A | N/A | Rare |
| Attestability (produce attestations/evidence) | Native (evidence packet export) | Partial | Partial | Partial | Partial |
| Verity (signature/provenance verification) | Native (enforce verifiable releases) | Via integration | Via integration | Partial (registry dependent) | Partial |
| Reproducibility (replayable decision/evidence) | Native (policy+inputs hashed) | Rare | Rare | N/A | N/A |
| Central audit ledger (who/what/why) | Native | Partial (logs exist, not unified) | Partial (deployment logs) | Partial (artifact logs) | Partial (scan logs) |
| “Why blocked?” explainability | Native (decision reasons + evidence refs) | Varies | Varies | Varies | Varies |
| Multi-toolchain governance (one control plane over many stacks) | Native | No (each CI silo) | Partial | No (registry silo) | No (scanner silo) |
| Open-source extensibility | Native (OSS agents/connectors, paid core) | Native OSS for some (Jenkins) | Varies | Varies | Varies |
| Pricing pain point | No per-seat / per-project / per-deploy tax | Often per-seat or usage | Often per-project/service/user | Often storage/traffic/consumption | Often per-seat / consumption |
| Best fit | Non‑K8s container teams needing centralized, auditable releases + security gates | Teams wanting pipeline automation | Teams wanting deployment automation (security bolted on) | Teams needing artifact storage + basic scanning | Teams needing scanning, not orchestration |
Interpretation: Stella is not trying to “replace CI” or “be a registry.” It is the release integrity layer that (a) makes promotion decisions, (b) executes deployments to non‑K8s container targets, and (c) produces verifiable evidence for audit and reproducibility—while reusing the customer’s existing SCM/CI/registry.
Stella pricing proposal (all features included; only scale limits)
Pricing principle: You pay for (1) environments and (2) new artifact digests analyzed per day. Deployments/promotions are unlimited (fair use), and re-evaluation on CVE updates is included and does not consume “new digest analyses.”
| Plan | Price | Environments | New digests analyzed/day | What’s included |
|---|---|---|---|---|
| Free + Registration (monthly token renewal) | $0 | 3 | 333 | Full suite features, unlimited deployments (fair use), evidence + audit, integrations |
| Pro | $699 / month | 33 | 3333 | Same features |
| Enterprise | $1,999 / month | Unlimited | Unlimited | Same features, “no hard limits,” fair use on mirroring/audit-confirmation bandwidth |
“Fair use” (make it explicit so it’s credible)
-
Unlimited deployments/promotions assume normal operational usage (no abusive tight-loop triggers).
-
“Unlimited” in Enterprise is protected by fair use for:
- vulnerability feed mirroring bandwidth and update frequency
- audit confirmation / evidence export traffic spikes
- storage growth beyond reasonable bounds (offer storage retention controls)
Short “elevator pitch” for the card (copy-ready)
Stella Ops Suite gives non‑Kubernetes container teams a central release authority: it orchestrates environment promotions, gates releases using reachability-aware security and policy, and produces verifiable, auditable evidence for every decision—without charging per project, per seat, or per deployment.
If you want, I can compress this into a true one-page “sales card” layout (same content, but formatted exactly like a procurement-ready PDF/one-pager), and a second version tailored to your best ICP (Docker host fleets vs ECS-heavy teams).