Frequently Asked Questions

No, and that is the point rather than a limitation. Docker Compose, Swarm, SSH/WinRM hosts and scripted targets are first-class, not fallbacks for people who have not adopted Kubernetes yet.

Supported targets: Docker Compose projects, SSH/WinRM hosts. SSH/WinRM deployments are agentless — the Docker image does the work.

The reverse also holds: if everything you run is on Kubernetes, Stella Ops is not your tool. It is built for the other half of the estate — VMs, Compose projects, plain servers — and most teams run both.

It is shown as Missing. Not passed, not assumed healthy, not quietly skipped.

Every stage of the custody spine carries one of three states — Missing, Recorded, or Signed. A gate that cannot find the evidence it needs does not fall back to a pass; NOT EVALUATED is never counted as a pass. Most tools treat absence as absence of a problem. This is the opposite of that, and it is the reason the rest of the evidence is worth anything.

Yes. The example capsule is a real signed archive you can check with stock tooling — cosign verify-blob plus sha256sum, no Stella Ops anywhere.

That download is a sanitized sample signed with a demo key, so it carries no trust beyond itself. stella evidence card verify and deterministic replay need an installation and a product-exported capsule — they will not succeed against the sample.

Yes, and offline. A verdict replays deterministically from the frozen inputs that produced it: the same SBOM, the same advisory snapshot, the same policy version.

This is the difference between a tool that tells you an answer and one that can be made to show its working months later, on a machine with no network, in front of someone who does not trust you.

After deploy, Stella keeps watching. Watch is the last stage of the custody spine (Source → Build → Scan → Verdict → Decision → Deploy → Watch): it compares the digest actually running in each environment against the digest that was approved for it.

When they differ, the service is flagged: running digest is not an approved/deployed digest (unapproved or altered image). You see exactly which service, in which environment, drifted from its approved state.

A service Watch has no evidence for reports Missing — it is never shown as matching on the assumption that nothing changed.

See the estate view →

Yes, and it is enforced in the product rather than left to your network. Sealed mode (EgressPolicyMode.Sealed) blocks egress; stella offline import --bundle brings in a signed kit; stella evidence verify-offline checks checksums, the manifest, DSSE binding and Rekor tile coverage with no network at all, and fails closed on any tamper.

The Offline Kit bundles vulnerability feeds, container images, and provenance data. You get identical scan results whether online or in a sovereign network.

See the Offline Kit →

Call graphs are built through the scan pipeline for nine languages: compiler-grade for Go, Java and .NET, and from source text for Python, JavaScript, TypeScript, Rust, PHP and Ruby. Every edge carries the tier that produced it.

The narrower case matters more: building a call graph from a source tree in the CLI supports Go and Rust only. Everything else arrives as a pre-extracted graph from the pipeline. Findings outside covered languages are not silently dropped — they stay in the working set as unknowns, scored rather than skipped.

The target record never holds the secret — only a reference to it. The secret itself is sealed with AES-256-GCM under a per-tenant key derived from a master key, and the encryption is bound to the tenant, owner and credential identity, so one row's ciphertext cannot be replayed as another's. The whole target connection record is then sealed again in its own crypto domain before it reaches the database.

You supply the master key, and we never generate one. It comes from an environment variable, a mounted file whose permissions are checked, HashiCorp Vault or OpenBao, or an HSM. If no durable store is configured, every seal and resolve fails rather than quietly falling back to memory.

Scoping and rotation are enforced, not advisory: every lookup is filtered by tenant, so a cross-tenant read returns nothing and leaks not even the existence of a credential. Rotation keeps the previous secret resolvable for a grace window and then fails closed, and revoking one scrubs the stored ciphertext so a later key compromise cannot recover it.

A gated release is blocked, not waved through. If the scanner or the policy engine cannot be reached, the gate treats the timeout as a failure by design — the code comments say so in as many words, and there is no fail-open flag anywhere in the CLI. The same applies at deploy time: an artifact whose scan result cannot be retrieved does not deploy.

Releasing during an outage is a deliberate, accountable act rather than a workaround. A gate exception requires a permission granted to nobody by default, a written justification, an explicit risk acknowledgement, an expiry between one and 365 days — open-ended exceptions are refused — a signature from the operator taking responsibility, and re-authentication within the last five minutes. It is recorded against the release. Note that it needs configuring before you can use it: on an unmodified install the signing path is not wired up, so the request is refused until you enrol an operator key.

The gate does not need the whole platform. A deploy decision depends on roughly ten services — the database, release orchestrator, scanner, policy engine, identity and the gateway — not the whole suite; evidence sealing, notifications and timeline audit are off the decision path.

Deploying to a bare VM is first-class: over SSH, WinRM or Ansible, Stella Ops can place a file, restart a service, or run an operator-supplied executable on the host, and it captures the command, its output and exit code as evidence — no container required.

Continuous Watch is narrower, and it is worth being exact about it. Watch and reachability observe running containers by image digest — that is how drift detection knows the running artifact still matches the approved one. A host it cannot read a container from is shown as unobserved, never assumed healthy. So a raw process on a Docker-less host is deployed and its run recorded, but it is not continuously watched for drift the way a containerised workload is. "Plain servers" means servers running containers outside Kubernetes — not arbitrary non-containerised processes.

No. An authorised operator clears it themselves. You raise a time-boxed policy exception that runs through an approval workflow you configure: named approver roles, a minimum number of approvers, a reason code, supporting evidence and any compensating controls, with a maximum lifetime. Self-approval is a toggle you set, not a default we impose.

The granted exception flips that specific finding — suppress, defer, downgrade, or require-a-control — and is written into the decision's audit trail with who approved it and when. It can be DSSE-signed, so a clearance is accountable and replayable, not a silent override that vanishes from the record.

One floor stays un-waivable by design: every deployed artifact must carry a real scanner pass. An exception clears a specific policy finding; it never clears the requirement that the artifact was scanned in the first place.

Out of the box, Stella Ops holds its own local users and hashes passwords with Argon2id. SAML, OIDC and LDAP/Active Directory connectors ship signed with the platform, and enabling one is an operator configuration step rather than a default. The install bundle carries a configuration file for each connector.

Access is tenant-scoped and permission-based, not role-shaped guesswork. The platform ships over 200 named permissions, so the things that matter are separate grants: approving a policy exception, bypassing a release gate and rotating a key-encryption key are each their own permission. You can give someone the ability to read findings without the ability to clear a block.

Mutating actions are recorded in the product's own audit trail, with its own read permission — separate from, and in addition to, the signed evidence chain a release carries. None of this is tier-gated: every capability ships in every tier, including Free.

It is the right question, and we will not pretend it away: a signature proves your installation produced the verdict, so a compromised control plane can sign a record that looks valid. What the design does is make that record hard to trust blindly and easy to catch.

Verification runs against a trust root you configure and fails closed without one — it never phones a Stella Ops service to decide what to trust. Each verdict is timestamped against a timestamp authority you point it at, and transparency-log inclusion is available against a log you operate, so "when" and "was this ever recorded" are anchored outside the box being audited.

The strongest check is replay: every verdict recomputes from its sealed inputs, and a record that does not recompute to the same answer fails. Re-run replay on infrastructure the suspect control plane does not control and a forged verdict does not survive the recomputation. None of this makes a compromised plane harmless — it moves the trust anchor off that plane and gives you an independent way to detect a lie.

Nothing was removed. Reachability changes whether a finding blocks a promotion, not whether it exists: the finding stays on the record with the state it was given, and the gate’s evidence records the full finding count next to the subset that actually blocked. There is no suppression step to reconstruct afterwards.

The capsule says why, and when. It binds each input that produced the verdict by digest — the SBOM, the advisory snapshots, the reachability evidence the state came from, and the identifier and version of the policy that acted on it. The approval that promoted the release is recorded against the release itself, at the Decision stage of the custody spine.

And it re-computes. Replay re-runs the verdict from those sealed inputs in an offline context and compares the result with the recorded one, reporting a divergence when they differ; a replay that cannot genuinely re-compute fails rather than echoing the stored verdict back. After an incident, what was known at decision time is a matter of record rather than of argument.

You own the residual risk. Your policy decided which states block and which do not, and a gate is only as good as the policy behind it. Stella Ops claims that the decision was evidenced and replayable; it has never claimed that the decision was correct. Worth knowing before you write that policy: only a proven reachable path can block a release, because “no path observed” is not proof that no path exists, and is not recorded as one.

Evidence & Audit → How reachability works →

The verdict re-opens. Advisory freshness is not a report you read later — new advisory data re-evaluates decisions that were already made, and the affected release is flagged.

The decision that was correct on Tuesday can stop being correct on Thursday without anything in your estate changing. Systems that only evaluate at promotion time cannot see that.

Feed age is reported per source, on screen. Staleness is visible, never hidden.

An air-gapped install that quietly serves month-old advisory data while looking healthy is worse than one that refuses to start. Stella Ops shows you the age of what it is deciding with, and an offline kit import records the snapshot digest so a replay months later uses the same data you decided on.

Something they can check themselves, without trusting us or installing anything. The published example capsule verifies with cosign verify-blob and sha256sum in about thirty seconds.

• What was scanned (exact artifact digest)
• What was found (SBOM?Software Bill of Materials - a complete list of all packages and dependencies in your software + reachability)
• Why it was approved (policy verdict)
• Who approved it (signed approvals)

Auditors can independently verify signatures and replay the decision offline using stella replay.

Commands as shown in the product console (v1.0-RC1).

No. Evidence comes from the CLI inside your existing build job. stella ci init scaffolds the pipeline steps; the CLI signs the build evidence inside the job (stella attest sign).

No connector is required — any CI that can run a binary works. Stella consumes signed digests and evidence, not repository access.

Commands as shown in the product console (v1.0-RC1).

Compliance packs map custody evidence to NIS2, DORA, and CRA obligations. Enabling starts evidence collection in conservative evidence-only mode; it does not claim regulatory compliance.

The operator always remains the regulated decision-maker. Stella helps you assemble and sign the artefacts a regulator expects — it never files and never certifies.

Some write paths are still in progress — for example, ENISA auto-submit transport is pending the official schema (operator filesystem drop today). Each pack's current status is stated on the compliance page.

Compliance packs in detail →

More than the tier you pay for — for now. Pre-order Plus and you are provisioned as Pro: 100 environments instead of 20, no scan ceiling instead of 50,000 a month, continuous vulnerability data instead of daily, and Pro's support — 30 tickets a year with a 1-business-day response target, instead of Plus's 10 tickets and 3 business days — at the Plus price. This early-adopter rate ends at v1.0; order before then to keep it. Otherwise a pre-order buys the plan exactly as this page lists it, and RC1 is public today so you can run the software before you commit. Ordering, payment and invoicing are handled by an authorised merchant of record; confirm the term of the upgrade with sales when you order.

Full pricing details →

The Free tier is $0: 3 environments and 100 new-digest scans per rolling 24 h, with all capabilities included. Paid tiers add environments and scan volume:

• Plus — $499 per month: 20 environments
• Pro — $1,299 per month: 100 environments
• Enterprise — custom: environments, scan volume, and SLA negotiated

Add-on for Plus: +10,000 new-digest deep scans for $399.

All capabilities are in every tier — compliance packs are not tier-gated. Annual billing: pay for 11 months, get 12.

Prices are shown excluding VAT. Any applicable VAT or sales tax is determined and charged at checkout by the merchant of record handling your order, based on your location and tax status.

Full pricing details →

Stella Ops is in release candidate (v1.0-RC1).

• Now: v1.0.0-RC1 — the signed bundle and the images are public and fetch anonymously from get.stella-ops.org and registry.stella-ops.org
• Before v1.0 ships: at least two customers running it in production, and the public API surface frozen
• At v1.0, expected 1 January 2027: the early-adopter pre-order rate ends. Pre-orders are open until then
• The code is source-available under BUSL-1.1
• Unchanged either way: backwards-compatible evidence formats and deterministic replay

Request early access →

Directory sign-in is not on by default. The LDAP, OIDC and SAML plugins ship signed with v1.0.0-RC1 and the install bundle carries a configuration file for each, but Stella Ops does not offer zero-configuration directory sign-in: you point a plugin at your directory and enable it.

It is also not a Kubernetes tool — that is a deliberate position, not a gap. It does not scan for malware, and it does not ship US federal compliance packs. If any of those is your deciding requirement, something else fits better today.

Stella models releases as a promotion graph (Dev → Stage → Prod). At each gate:

• Policy is evaluated against the artifact's evidence
• Approvals are recorded with cryptographic signatures
• A Decision Capsule?A signed, exportable evidence bundle that seals every input and output of a release decision for offline audit and deterministic replay is generated for audit

Promotions are tied to artifact digests, not tags. Same digest = same evidence reused.

Stella Ops is developed in Europe and operated by a company registered in Bulgaria; our own infrastructure — this site, the registry, and the update channels — is hosted in Switzerland, which holds an EU data-protection adequacy decision. No US-headquartered vendor sits in your supply chain. Full operator details are in our legal notice.

The platform is self-hosted, so your artifacts, SBOMs, and evidence stay on your own infrastructure — air-gapped if you need it. European jurisdiction plus self-hosting means the only party holding your release evidence is you.

A fair question for anything sitting in a release path. The design answer: day-to-day operation never depends on reaching us. The product is self-hosted and runs air-gapped; there is no licence server and no cloud dependency on us.

Your evidence does not need us either. Verdicts and capsules verify offline — stella replay re-computes a decision from its sealed inputs with no Stella Ops service or account involved.

The code is source-available under BUSL-1.1: you can read, build, and patch the version you run. The licence also has an expiry built in — each version converts to an open licence on its Change Date, no later than 20 January 2030 for the current version. You are not dependent on us for day-to-day operation either: stella doctor runs the installation's diagnostic checks, stella doctor export packages a bundle for support, and stella doctor fix applies non-destructive repairs. The source is at git.stella-ops.org.

Day to day, the product supports itself. Doctor health-checks the stack and returns the remediation steps for whatever it finds; inside a maintenance window it applies non-destructive fixes on its own, and destructive ones only behind an approval gate with a dry-run preview and a durable audit record — otherwise it hands you the manual steps. Human support is a paid add-on on top of that, not the thing that keeps your installation running. If your procurement needs contractual continuity terms, scope them with sales@stella-ops.org during evaluation.

Verification keys, a signed evidence example, and architecture and hardening documentation are public, collected on the vendor security review page, which also states our certification posture. Customer references are coming soon — results from our internal beta. Due-diligence discussions can be scoped during evaluation.

Vendor security review →

Ordering, payment, taxes, and invoicing are handled by an authorised merchant of record — see the checkout notice. Anything beyond that is a conversation with sales@stella-ops.org during evaluation.

The product is built to keep running without a ticket: Doctor health-checks the stack and applies non-destructive fixes itself inside a maintenance window, handing you the exact steps for anything it will not do unattended. On top of that: Free and Plus are self-serve — documentation, community discussions and Doctor diagnostics, with no contractual response target. Pro adds an email support channel with a 1-business-day response target. Enterprise support, response and onboarding terms are agreed per contract, scoped with sales@stella-ops.org during evaluation. Whoever answers, it is the engineering team that builds the product — support is not outsourced.

Stella Ops Suite is source-available under BUSL-1.1. You can read, build, and audit the code. The verification layer (capsule validation, signature checks) is licensed under Apache-2.0. The source is at git.stella-ops.org.

BUSL-1.1 permits production use within the free limits (3 environments, 100 new-digest scans per rolling 24 hours). Beyond them, a paid plan is required. After the change date — four years from each release — the code converts to Apache-2.0.

This model funds sustainable development while keeping the evidence chain fully auditable.

A tenant is an isolated workspace with its own users, roles, policies, and evidence history. Suspending a tenant freezes all of its access.

Tenants share an installation; evidence and access are separated per tenant. The two words answer different questions:

• An Environment?A logical deployment target (e.g. dev, staging, prod) that tracks its own release history, promotion rules, and policy gates is a deployment target — where a release runs, and what policy gates its promotion.
• A tenant is an access and evidence boundary — who can see and act, and whose evidence history it lands in.

One tenant normally holds several environments. Tenants are not metered: tiers meter environments and new-digest scans.

A new-digest deep scan is consumed when Stella analyses a container digest for the first time and produces SBOM?Software Bill of Materials - a complete list of all packages and dependencies in your software, vulnerability, and reachability evidence. Only unique digests count.

Consumes one deep scan:

• The first scan of a new artifact digest

Does not consume a deep scan:

• Re-deploying an already-scanned digest
• Promoting an already-scanned digest
• Re-evaluation when CVE?Common Vulnerabilities and Exposures - a unique identifier for a publicly known security vulnerability or advisory intelligence updates
• Querying existing Decision Capsules

Plus meters per calendar month: the quota resets on the first of the month, so bursting within a month is fine. Pro has no scan limit to meter. The Free tier has no reset moment at all — the licence allows 100 new-digest deep scans in any rolling 24-hour window, so a scan stops counting 24 hours after it ran. There is no monthly pool on the Free tier.

If a release spike, migration, or intake window exceeds the monthly quota, a capacity add-on of +10,000 new-digest deep scans is available on Plus for $399.

Tier limits and pricing →

The Free tier permits limited production use: all capabilities, up to 3 environments, and 100 new-digest scans per rolling 24 h.

Production beyond the free limits requires a paid plan — Plus (20 environments), Pro (100), or Enterprise beyond that.

Pricing details →

Yes. Stella is the control layer over whatever scanner you run, and its output has somewhere to land: stella sbom upload takes an external CycloneDX?An open standard format for software bill of materials (SBOM) used across the industry or SPDX?Software Package Data Exchange - another open standard format for SBOMs, widely used in open source document and records which tool produced it, and stella gate score batch --sarif puts any producer's SARIF through the same release gate as Stella's own scans.

On top of that finding list Stella adds reachability analysis, multi-issuer VEX?Vulnerability Exploitability eXchange - machine-readable statements about whether vulnerabilities are actually exploitable in your context, environment-aware policy gates, and signed evidence export. Your scanner finds CVEs; Stella decides which ones matter and proves the decision.

Reachability is computed by Stella's own scan of the digest. An imported SARIF carries whatever reachability its producer recorded — Stella reads that field, it does not re-derive it.

Commands as shown in the product console (v1.0-RC1).

vs Trivy · vs Snyk · Full comparison →

Stella is not a layer on top of your deployment tool — it is a release orchestrator. Docker, Compose, SSH, WinRM, ECS, Nomad and Ansible ship as built-in execution plugins. On the targets those cover, Stella performs the deploy itself; it does not wrap a tool that already does.

Your CI stays exactly where it is, because the gate is just a binary. Any CI that can run one calls stella gate evaluate and acts on the exit code. stella ci init writes ready-made workflows for GitHub Actions, GitLab CI and Gitea Actions; every other CI wires up by hand in a few lines.

Connectors ship for Gitea, GitHub App, GitLab, Jenkins, Harbor, Nexus, OCI?Open Container Initiative — the industry standard for container image formats and registries registries, Vault and Consul. So the practical split is: keep the CI you have, and decide per environment whether Stella performs the deploy or gates one your existing tool performs.

Commands as shown in the product console (v1.0-RC1).

vs Octopus Deploy · What connects, and what needs no connector →

Yes. Stella supplies the artifact-level proof a compliance programme points to but cannot produce for itself: for any release, what is deployed, under which digest, gated by which policy, approved by whom, and on which day. That record is read from the deployment itself, and it re-runs deterministically from the same evidence — the answer a reviewer gets next year is the answer they got today.

That record exports as eight signed regulator profiles: NIS2 Statement of Applicability and effectiveness report; DORA Register of Information, major ICT incident report, Article 45 information sharing and TLPT evidence pack; CRA technical file and conformity dossier. Each one is sealed, signed, and verifiable offline against published trust roots — a reviewer checks the signature with no access to your Stella instance at all.

Nothing about the programme you already run has to change. Each export is a portable signed file: attach it to the control it evidences, hand it to an auditor, or pull it from the assurance export API. And before you export, a readiness check names per profile exactly what is still missing — so a gap surfaces while you can still close it, not during the review.

The compliance field, sourced · Compliance packs in detail →