refactor OFFER.md for clarity and structure; update product description and pricing model
This commit is contained in:
@@ -1,234 +1,236 @@
|
|||||||
# Stella Ops Suite (On‑Prem) — Offer & Pricing
|
# Stella Ops Suite — Pricing & Offer Guide (On‑Prem)
|
||||||
|
_Evidence-grade release orchestration for containerized applications outside Kubernetes._
|
||||||
_Self-hosted release governance + reachability-aware security gating for **non‑Kubernetes** container deployments._
|
|
||||||
|
|
||||||
**All features are included at every tier.**
|
|
||||||
You pay only for:
|
|
||||||
|
|
||||||
1) **Environments** (policy/config boundaries)
|
|
||||||
2) **New digests deep‑scanned per month** (evidence-grade analysis of new container artifacts)
|
|
||||||
…and optionally support **tickets** if you want help.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 1) What Stella Ops Suite is
|
## What Stella Ops Suite is
|
||||||
|
|
||||||
**Stella Ops Suite is a release control plane + evidence engine for containerized applications outside Kubernetes.**
|
Stella Ops Suite is a centralized, auditable release control plane for non-Kubernetes container estates. It:
|
||||||
|
- orchestrates environment promotions (Dev -> Stage -> Prod),
|
||||||
|
- gates releases using reachability-aware security and policy,
|
||||||
|
- and produces verifiable evidence for every decision (exportable and replayable).
|
||||||
|
|
||||||
It provides:
|
You can run Stella in two modes:
|
||||||
- **Centralized release orchestration** (environments, promotions, approvals, rollbacks, templates)
|
- **Verified releases (recommended):** promotions require Stella evidence for each new digest.
|
||||||
- **Practical security signal** (reachability + hybrid reachability) to reduce noise and focus on exploitable risk
|
- **Unverified releases (CD-only):** orchestration runs without evidence gates (still logged, but not certifiable).
|
||||||
- **Auditability and attestability** (evidence packets, deterministic decision records, exportable audit trail)
|
|
||||||
- **Toolchain interoperability** (plugins for SCM/CI/registry/vault/agents)
|
|
||||||
|
|
||||||
This is designed for:
|
|
||||||
- **Small teams** that want a real, usable free tier (not a toy)
|
|
||||||
- **Mid-size companies (10–100 people)** that need **certifiable**, audit-friendly releases with practical security gates, without running Kubernetes
|
|
||||||
- **On‑prem or air‑gapped environments** where SaaS-based governance is not an option
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 2) Key outcomes for customers
|
## The problem we solve
|
||||||
|
|
||||||
### Secure and certifiable releases (without Kubernetes)
|
Teams deploying containers without Kubernetes often cobble together a fragmented toolchain:
|
||||||
- Gate promotions on **evidence** (SBOM + reachability + policy explain traces)
|
|
||||||
- Produce **audit-grade proof** of “who approved what, why, and based on which evidence”
|
|
||||||
- Keep “what is deployed where” authoritative, digest-based, and reproducible
|
|
||||||
|
|
||||||
### Reduce security noise and engineering churn
|
| Function | Typical tools | Typical gap |
|
||||||
- Reachability-aware prioritization focuses attention on vulnerabilities that are actually on exploitable paths (vs. raw CVE count)
|
|---|---|---|
|
||||||
|
| Vulnerability scanning | Trivy, Grype, Snyk | Scanner output isn't automatically tied to approvals, promotions, and audit export |
|
||||||
|
| SBOM generation | Syft, manual export | SBOM exists, but not linked to release decisions |
|
||||||
|
| Deployment | Docker Compose, shell scripts, Ansible | No deterministic release ledger; approvals are informal; rollback is ad-hoc |
|
||||||
|
| Approvals | Slack, email, Jira | Not cryptographically bound to the exact artifact(s) deployed |
|
||||||
|
| Audit trail | Spreadsheets, Confluence | Not replayable; evidence is not end-to-end; "why approved?" is hard to prove |
|
||||||
|
|
||||||
### Predictable cost
|
**Result:**
|
||||||
- No per-user cost
|
- Release decisions are not traceable to the evidence they were based on.
|
||||||
- No per-project/microservice tax
|
- Audits and incident reviews require manual reconstruction and often produce evidence gaps.
|
||||||
- No per-target/machine tax
|
- Operational confidence depends on tribal knowledge.
|
||||||
- No surprise overages (add-ons are explicit and self-serve)
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 3) What every tier includes (no feature gating)
|
## What "evidence-grade" means
|
||||||
|
|
||||||
All tiers (including Free) include the full Stella Ops capability set:
|
An **evidence-grade release** is one where:
|
||||||
|
1. Each new artifact digest can be deeply analyzed to produce SBOM + reachability evidence.
|
||||||
|
2. Promotion decisions are recorded with the exact evidence they were based on.
|
||||||
|
3. Approvals are linked to specific artifact digests and policy outcomes.
|
||||||
|
4. The decision chain is hashable, exportable, and replayable.
|
||||||
|
5. Operators can ask "why was this blocked?" and get a deterministic explanation trace.
|
||||||
|
|
||||||
### Release orchestration (non‑K8s)
|
This is Stella's core value: end-to-end release certification, not just scanning or CD automation.
|
||||||
- Environments, promotions, approvals, rollbacks
|
|
||||||
- Templates and step graphs (sequential/parallel)
|
|
||||||
- UI visualization of deployments in progress (per-step logs)
|
|
||||||
- Deployment inventory view (“what is deployed where”)
|
|
||||||
|
|
||||||
### Deployment execution (non‑K8s)
|
|
||||||
- Docker Compose deployments
|
|
||||||
- Scripted deployments (**.NET 10 scripting only**)
|
|
||||||
- Immutable generated deployment artifacts
|
|
||||||
- “Version sticker” written to deployment directory for traceability
|
|
||||||
- Support for replicas and controlled restarts/reloads (e.g., config update + nginx reload)
|
|
||||||
|
|
||||||
### Security & evidence
|
|
||||||
- Scan on build, gate on release, continuous re-evaluation on vuln intel updates
|
|
||||||
- Reachability + hybrid reachability
|
|
||||||
- Evidence packets and deterministic decision records (hashable, replayable)
|
|
||||||
- Exportable audit trail (for compliance, internal audit, incident reviews)
|
|
||||||
|
|
||||||
### Extensibility
|
|
||||||
- Plugin model for SCM/CI/registry/vault/agent providers
|
|
||||||
- Plugin-specific deployment steps supported by the workflow engine
|
|
||||||
|
|
||||||
### Operability
|
|
||||||
- **Doctor tooling** for self-service diagnostics (connectivity, agent health, configuration sanity, “why blocked?” traces)
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 4) Verified releases vs Unverified releases
|
## What Stella delivers (one platform, one evidence chain)
|
||||||
|
|
||||||
Stella supports both operational styles.
|
| Capability | What Stella does | Why it matters |
|
||||||
|
|---|---|---|
|
||||||
### Verified releases (recommended for production)
|
| Reachability-aware security decisioning | Deep scans produce evidence that can reduce "raw CVE noise" by focusing on what's relevant to your app's execution paths | Engineers spend less time on false urgency; policy gates are more credible |
|
||||||
A **Verified Release** is one where promotions require Stella evidence for each new digest:
|
| Evidence packets | Hashable, immutable bundles linking SBOM + reachability + policy verdict + approvals | Auditors and incident responders can verify "what was known" at decision time |
|
||||||
- SBOM + reachability evidence
|
| Release orchestration (non-K8s) | Environments, promotions, approvals, rollbacks, step graphs, per-step logs | Replaces informal approvals and script sprawl with a governed control plane |
|
||||||
- policy evaluation records
|
| Policy engine + explainability | Declarative gates with deterministic evaluation and "why blocked?" traces | Governance becomes inspectable, repeatable, and defensible |
|
||||||
- approval records (where required)
|
| Deployment execution | Docker Compose + scripted deployments; immutable generated artifacts; version stickers; controlled restarts/reloads | "What was deployed where" becomes precise and reconstructible |
|
||||||
- exportable evidence packet
|
| Audit export | Compliance-ready export of decision evidence | Reduces audit time and evidence gaps |
|
||||||
|
|
||||||
Verified releases are intended for teams that need “certifiable” releases and practical security.
|
|
||||||
|
|
||||||
### Unverified releases (CD-only usage)
|
|
||||||
Stella can also run “CD-only” workflows where evidence gates are bypassed:
|
|
||||||
- still orchestrated, logged, and visible
|
|
||||||
- useful for teams that want orchestration without security certification
|
|
||||||
|
|
||||||
**Note:** CD-only users are not the primary target audience for Stella Ops Suite. The product is optimized for verified releases and auditable security.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 5) Pricing (On‑Prem Suite)
|
## Competitive anchors (public list pricing signals)
|
||||||
|
|
||||||
**Annual billing:** pay annually and get **1 month free** (pay for 11 months).
|
These are not full TCO models; they are public, vendor-published pricing anchors that shape buyer expectations.
|
||||||
|
|
||||||
> **Important:** All tiers have the same features. Only the scale limits and included support channels differ.
|
- **Snyk Team**: starts at **$25/month per contributing developer**, **minimum of 5 contributing developers**, and **products are purchased separately**. citeturn1view0
|
||||||
|
- **Snyk Free** includes **Snyk Container tests/month = 100** (container testing limit on Free). citeturn1view0turn0search3
|
||||||
|
- **Octopus Deploy**: **annual billing only** for Octopus Cloud and Octopus Server. citeturn1view1
|
||||||
|
- **Octopus Free** includes **10 projects, 10 tenants, and 10 machines**. citeturn1view2
|
||||||
|
- **Octopus Professional** is listed **from $4,170 USD/year**. citeturn1view2
|
||||||
|
|
||||||
### 5.1 Stella Ops Suite tiers
|
### A simple comparison that buyers can sanity-check
|
||||||
|
A common "two-tool" baseline for non-K8s governance is:
|
||||||
|
- a CD/orchestration tool (e.g., Octopus) plus
|
||||||
|
- a paid scanner for teams (e.g., Snyk Team)
|
||||||
|
|
||||||
| Tier | Monthly | Annual (11×) | Environments | New digests deep‑scanned / month | Deployment targets | Support |
|
Using public minimums:
|
||||||
|---|---:|---:|---:|---:|---:|---|
|
- Octopus Professional starts at $4,170/year (~$347.50/month annualized). citeturn1view2
|
||||||
| **Free** | $0 | $0 | **10** | **1,000** | **Unlimited** | Self-service (Doctor) + community forum |
|
- Snyk Team minimum purchase (5 contributing devs) starts at 5 x $25 = $125/month, per product. citeturn1view0
|
||||||
| **Plus** | **$199** | **$2,189** | **10** | **10,000** | **Unlimited** | Same as Free |
|
|
||||||
| **Pro** | **$599** | **$6,589** | **100** | **100,000** | **Unlimited** | Priority forum + **2 tickets/month** (typical response ~3 business days; best-effort) |
|
|
||||||
| **Business** | **$2,999** | **$32,989** | **1,000** | **1,000,000** | **Unlimited** | Priority forum + email channel + **20 tickets/month** (typical response ~24 hours; best-effort) + fair use |
|
|
||||||
|
|
||||||
### 5.2 Add-ons (self-serve)
|
That baseline is **~$472.50/month** before add-ons, scaling effects, or additional products.
|
||||||
|
|
||||||
| Add-on | Price | Notes |
|
Stella **Plus** is **$399/month** and includes the integrated evidence-grade orchestration + security gate in one platform.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Pricing model (simple, predictable)
|
||||||
|
|
||||||
|
**All features are included at every tier.** No capability is gated behind higher tiers.
|
||||||
|
|
||||||
|
You pay for:
|
||||||
|
1) **Environments** (policy/config boundaries: dev/stage/prod, regions, compliance zones, tenant boundaries)
|
||||||
|
2) **New digest deep scan credits per month** (evidence-grade analysis of previously unseen OCI digests)
|
||||||
|
|
||||||
|
Deployment targets are **unlimited** (no per-target / per-machine licensing).
|
||||||
|
|
||||||
|
### Monthly scan credits (how to interpret them)
|
||||||
|
- Credits are counted **per month** and reset monthly.
|
||||||
|
- You may burst within the month; a soft protective rate limit may exist to prevent abuse, but licensing is based on the monthly pool.
|
||||||
|
- Re-deploying or promoting an already-scanned digest does not consume credits.
|
||||||
|
- Re-evaluation on vulnerability intel updates does not consume credits.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Tier overview (Suite: Orchestrator + Scanner)
|
||||||
|
|
||||||
|
**Annual billing:** pay for 11 months, get 12 (1 month free).
|
||||||
|
|
||||||
|
| Tier | Monthly | Annual (11x) | Environments | New digest deep scans / month | Support |
|
||||||
|
|---|---:|---:|---:|---:|---|
|
||||||
|
| **Free** | $0 | $0 | **3** | **999** | Doctor self-diagnostics + community forum |
|
||||||
|
| **Plus** | **$399** | **$4,389** | **33** | **9,999** | Doctor + priority forum + **1 support ticket/month** |
|
||||||
|
| **Pro** | **$999** | **$10,989** | **333** | **99,999** | Doctor + priority forum + **5 support tickets/month** |
|
||||||
|
| **Business** | **$2,999** | **$32,989** | **3,333** | **999,999** | Doctor + priority forum + **email channel** + **25 support tickets/month** (best-effort) + fair use |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Add-ons (self-serve)
|
||||||
|
|
||||||
|
| Add-on | Price | Intended use |
|
||||||
|---|---:|---|
|
|---|---:|---|
|
||||||
| **+10 support tickets** | **$249** | For bursts/incidents or expansion without tier change |
|
| **+10 support tickets** | **$299** | Incident bursts, onboarding assistance, expansion without tier change |
|
||||||
| **+10,000 new digest deep scans** | **$249** | Burst capacity (premium) |
|
| **+10,000 new digest deep scans** | **$499** | Temporary capacity for release sprints, migrations, or one-off spikes |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 6) Definitions and how metering works
|
## What every tier includes (no feature gating)
|
||||||
|
|
||||||
|
### Release orchestration (non-K8s)
|
||||||
|
- Environment management with promotion rules
|
||||||
|
- Approval workflows (manual, automated, policy-gated)
|
||||||
|
- Rollback orchestration with evidence preservation
|
||||||
|
- Step graphs (sequential and parallel execution)
|
||||||
|
- Real-time deployment UI with per-step logs
|
||||||
|
- Deployment inventory ("what is deployed where")
|
||||||
|
|
||||||
|
### Deployment execution
|
||||||
|
- Docker Compose deployments
|
||||||
|
- Scripted deployments (.NET 10 scripting)
|
||||||
|
- Immutable generated deployment artifacts
|
||||||
|
- Version stickers for traceability
|
||||||
|
- Controlled restarts and config reloads
|
||||||
|
|
||||||
|
### Security and evidence
|
||||||
|
- Scan on build, gate on release, continuous re-evaluation
|
||||||
|
- Reachability and hybrid reachability analysis
|
||||||
|
- Evidence packets (hashable, immutable, replayable)
|
||||||
|
- Deterministic decision records
|
||||||
|
- Exportable audit trail
|
||||||
|
- "Why blocked?" explainability traces
|
||||||
|
|
||||||
|
### Extensibility and operability
|
||||||
|
- Plugin model for SCM, CI, registry, vault, and agent providers
|
||||||
|
- Workflow engine supports plugin-specific steps
|
||||||
|
- Doctor tooling for self-service diagnostics (connectivity, agent health, config validation)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Definitions
|
||||||
|
|
||||||
### Environment
|
### Environment
|
||||||
An **Environment** is a policy/config boundary (e.g., dev/stage/prod; region splits; customer isolation boundaries), with its own:
|
A policy and configuration boundary with its own:
|
||||||
- policy profile
|
- Security policy profile
|
||||||
- targets/agents selection
|
- Target/agent selection
|
||||||
- secrets/config bindings
|
- Secrets and config bindings
|
||||||
- promotion rules
|
- Promotion rules and approval requirements
|
||||||
|
|
||||||
|
Examples: dev/staging/prod, regional deployments, compliance zones, customer isolation boundaries.
|
||||||
|
|
||||||
### Deployment target
|
### Deployment target
|
||||||
A **Deployment Target** is any endpoint that can receive a deployment (Docker host group, script target via SSH/WinRM provider, etc.).
|
An endpoint that receives deployments (Docker host, VM, scripted target via SSH/WinRM provider).
|
||||||
**Targets are unlimited in licensing**. Fair use applies only in extreme abuse scenarios.
|
|
||||||
|
Targets are **unlimited** at all tiers.
|
||||||
|
|
||||||
### New digest deep scan
|
### New digest deep scan
|
||||||
A **New Digest Deep Scan** occurs the first time Stella deeply analyzes a unique OCI digest to produce:
|
A deep scan occurs the first time Stella analyzes a unique OCI digest, producing:
|
||||||
- SBOM
|
- SBOM
|
||||||
- reachability/hybrid reachability evidence
|
- reachability and hybrid reachability evidence
|
||||||
- vulnerability findings + verdict
|
- vulnerability findings with an evidence-backed verdict
|
||||||
- evidence references for gating and audit
|
- an evidence packet usable for gating and audit
|
||||||
|
|
||||||
#### What does NOT consume deep scan quota
|
Does not consume scan credits:
|
||||||
- Re-deploying or promoting an already-scanned digest
|
- re-deploying/promoting an already-scanned digest
|
||||||
- Re-evaluation when vulnerability intelligence updates (CVE feed updates); Stella re-computes risk using existing evidence
|
- re-evaluation on CVE/vuln intel updates
|
||||||
|
- querying existing evidence packets
|
||||||
|
|
||||||
### Tickets
|
### Support ticket
|
||||||
A **ticket** is a support request handled by maintainers via the paid ticket channel. For fast resolution, tickets require:
|
A bounded support request handled by maintainers. For effective resolution, include:
|
||||||
- a clear problem statement
|
- clear problem statement
|
||||||
- reproduction steps
|
- reproduction steps
|
||||||
- the **Doctor bundle** output (when applicable)
|
- Doctor bundle output (when applicable)
|
||||||
|
|
||||||
Tickets are designed to be bounded, so Stella can remain self-serve by default.
|
Tickets are bounded so Stella can remain self-serve by default.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 7) Fair use (Business tier)
|
## Choosing the right tier
|
||||||
|
|
||||||
Business tier includes very high scale limits and support capacity. To keep pricing predictable and sustainable, fair use applies to:
|
| Your situation | Recommended tier | Why |
|
||||||
|
|---|---|---|
|
||||||
- vulnerability feed mirroring bandwidth and frequency (if mirroring is enabled)
|
| Evaluating Stella with real workflows | **Free** | Full features; enough capacity to test verified releases in practice |
|
||||||
- audit confirmation/verification traffic (if configured)
|
| Small team, low artifact churn | **Free** | 999 scans/month covers many small estates |
|
||||||
- excessive support ticket volume beyond included entitlements
|
| Production team with growing CI/CD velocity | **Plus** | 9,999 scans/month supports broad evidence coverage without sampling |
|
||||||
- abusive automation patterns that intentionally generate excessive duplicate work
|
| Multi-team / multi-region governance | **Pro** | 333 environments + 99,999 scans/month + ticket access |
|
||||||
|
| Platform org with formal audit posture | **Business** | Scale + email channel + high ticket allowance |
|
||||||
Fair use is intended to prevent abuse, not to penalize normal operational usage.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 8) Why Stella pricing is simpler than typical alternatives
|
## Fair use (Business tier)
|
||||||
|
|
||||||
### The common pain with “legacy” stacks
|
Fair use exists to prevent abuse, not normal operational usage. It may apply to:
|
||||||
Many release and security tools charge based on organizational and deployment complexity:
|
- vulnerability feed mirroring bandwidth/frequency (if mirroring is enabled)
|
||||||
- per developer/committer
|
- automation patterns that intentionally generate duplicate work
|
||||||
- per project/microservice
|
- ticket volume beyond included entitlements
|
||||||
- per deployment target/machine
|
|
||||||
- per add-on module
|
|
||||||
|
|
||||||
That pricing becomes unpredictable as your architecture grows.
|
|
||||||
|
|
||||||
### Stella’s approach
|
|
||||||
Stella is priced like infrastructure:
|
|
||||||
- **Scale with environments and new artifacts** (the two things that actually grow with your release and security footprint)
|
|
||||||
- Keep all features available at all tiers
|
|
||||||
- Keep adoption friction low for on‑prem teams
|
|
||||||
|
|
||||||
Stella is designed to replace (or reduce dependence on) a multi-tool stack:
|
|
||||||
- one tool for CD governance + evidence
|
|
||||||
- another tool for scanning
|
|
||||||
- plus “glue” for approvals, audit, and exceptions
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 9) Which tier is right for you?
|
## Deployment and licensing
|
||||||
|
|
||||||
### Free
|
- On-premises deployment (you host Stella on your infrastructure)
|
||||||
Best for:
|
- Offline-friendly licensing options (air-gapped supported)
|
||||||
- startups and small teams
|
- Updates included during subscription term
|
||||||
- evaluation in real workflows
|
- You provide compute/storage for scanning and evidence retention
|
||||||
- internal PoCs
|
|
||||||
- teams learning the verified-release model
|
|
||||||
|
|
||||||
### Plus ($199/month)
|
|
||||||
Best for:
|
|
||||||
- mid-size teams that want verified releases but do not want vendor support
|
|
||||||
- organizations that need a predictable monthly cost and on‑prem control
|
|
||||||
|
|
||||||
### Pro ($599/month)
|
|
||||||
Best for:
|
|
||||||
- teams operating many environments and high artifact churn
|
|
||||||
- those who want occasional maintainer help without a heavy support relationship
|
|
||||||
|
|
||||||
### Business ($2,999/month)
|
|
||||||
Best for:
|
|
||||||
- regulated and compliance-driven teams
|
|
||||||
- platform teams supporting multiple product groups
|
|
||||||
- customers who want best-effort response channels and bounded ticket entitlements
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 10) Commercial notes (On‑Prem)
|
## Summary (the simple offer)
|
||||||
|
|
||||||
- License delivered as an on‑prem entitlement (offline-friendly where required)
|
- One platform for non-Kubernetes container releases: orchestration + evidence-grade security gating.
|
||||||
- Includes product updates during the subscription term
|
- All features included at all tiers.
|
||||||
- Customer is responsible for compute/storage required for scanning and evidence retention
|
- Unlimited deployment targets.
|
||||||
- Support channel access depends on tier and ticket entitlements
|
- Predictable pricing based on environments and new digests per month.
|
||||||
|
|
||||||
---
|
Start on **Free**. Upgrade when your environment count or new-digest velocity demands more evidence capacity.
|
||||||
|
|
||||||
_This document is intended as a customer-facing offer summary. Final terms and definitions may be refined in the Stella Ops subscription agreement._
|
|
||||||
|
|||||||
Reference in New Issue
Block a user