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 plan-gated: Free and Licensed include every capability.

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 →

One managed workload in one environment of your installation: a container service, or a digest-addressed artifact deployed to a host over SSH or WinRM; both count the same. A workload–environment relationship can count when Stella Ops deploys, gates or promotes its releases, scans its installed image or artifact, or applies an earlier scan result to that installed workload. Applying an earlier result does not require a new scan to run. Each qualifying relationship counts once, even when several of these activities apply.

Placements are counted per installation — one logical control-plane deployment of Stella Ops: cluster nodes, database replicas and failover components of the same deployment count together, and independently operated installations are separate. Stella Ops' own infrastructure is never counted. A placement ends when all management of that workload in that environment actually ends, or when the workload is removed and no other management activity keeps it active; finishing a scan does not end it, and keeping historical evidence or reports does not, by itself, create, reactivate or keep a placement.

The current release shows no placement total. Count each workload in each environment once if Stella Ops deploys, gates or promotes its releases, scans its installed image or artifact, or applies an earlier scan result to it. The Estate view lists the deployments Stella Ops ran; you must also count every other qualifying workload, including those other tools deploy and any the automatic inventory does not show.

What counts as a managed placement →

No. Five replicas of a workload in one environment are one placement. Restarting it, redeploying it, or rolling out a new image version or digest of the same workload in the same environment adds nothing.

Three. A placement is one workload in one environment, so a workload running in dev, staging and production is 3 placements, and ten workloads across three environments are 30. Environments themselves are never limited or priced.

No. There is no fee per scan, re-scan, vulnerability report, promotion or deployment. Scanning an installed workload's image or artifact, or applying an earlier scan result to it, can bring that workload into the placement count for each applicable environment. Each workload–environment relationship counts only once, regardless of the number of scans or reports.

Merely retaining or viewing a report solely as historical evidence does not create a placement. Presenting an earlier result as applicable scan information for an installed workload counts as applying that result. Scanning an image or artifact installed in none of your environments does not create a placement.

Production use above 20 placements per installation needs a Licensed plan: a licence for a placement capacity at least equal to the placements you manage. It costs $100 a month for a capacity of up to 100 placements and $1 per placement of capacity per month above that; above 20, every placement counts — the free 20 are not deducted — so a capacity of 30 costs $100 a month and 200 costs $200.

Capacity increases take effect when you order them and are prorated from that date; decreases take effect at renewal.

If you notice you have gone over your capacity, or over the free 20, by accident, you may keep going for 14 days from noticing while you reduce usage or order capacity. That allowance is for accidents, not for deliberate or repeated excess.

You can subscribe today: email sales@stella-ops.org, and the order is placed through an authorised merchant of record. Online checkout is coming soon.

What will it cost? →

Licensed has a $100 monthly minimum, and the minimum covers up to 100 placements: 21 placements and 100 placements both cost $100 a month. From 101 placements the price is $1 per placement — 101 cost $101, 150 cost $150.

Nothing is switched off. The current release does not enforce the placement limit or check a licence, so your software, workloads, scans and deployments keep running, and every evidence record stays verifiable with your own trust root.

Paid capacity is licensed for the subscription term, though. Once the term ends, production use above 20 placements needs a renewal or a reduction to 20 placements or fewer.

No. There is no licence server, no activation and no phone-home: the current release does not check a licence, so an air-gapped installation is licensed exactly as a connected one is. Your free use is set by the licence terms, and paid capacity by your order — not by a connection to us.

Vulnerability-intelligence updates reach an offline installation through the Offline Kit, and feed age is reported per source, on screen.

By your order. A Licensed plan is bought through an authorised merchant of record for a placement capacity at least equal to the placements you manage, and the accepted order states that capacity and the term under the Stella Ops Customer Agreement.

The current release does not import or check that record, so keeping the installation within it is your responsibility. When the term ends nothing in the software is switched off, but production use above 20 placements then needs a renewal or a reduction to 20.

Customer Agreement →

Evidence your installation generates is signed with your installation's own keys, not ours. Verify a portable evidence bundle fully offline against the trust root you declare: stella evidence verify-offline <bundle.tgz> --trust-root <keys.jwks.json|key.pem>. It checks the checksums, the manifest bindings and the signature, and fails closed.

Stella Ops releases are signed separately: the release bundle and the images are signed with Cosign, and the public key is on the verification keys page. A release signature shows that a bundle came from us; an evidence signature shows that a record came from your installation.

Verification keys →

Yes, through the same interfaces a person uses. A CI job, a script or an AI agent you run authenticates as an OAuth client-credentials service client and drives releases through the release API or stella release approve|reject|promote|deploy|rollback. Approvals and policy gates are evaluated by the server, so an automated caller is held to the same policy as a person.

Other scanners feed in as well: stella sbom upload imports 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 SBOM and records which tool produced it, and stella gate score batch --sarif puts another tool's SARIF findings through the same release gate.

One review covers one defined issue. An engineer analyses the information you send and replies with a written engineering response: the likely cause, and the corrective or diagnostic steps we recommend.

It does not include unlimited engineering hours, custom development, guaranteed remediation or ongoing consultancy, and there is no ongoing service level. Before you buy, we give you an estimated delivery window; once we have the information we need, we reply in writing within a reasonable time. Before we ask for logs, we tell you how to send diagnostic data securely. To buy one, email support@stella-ops.org with a short description of the issue.

If the review shows that the main issue is a reproducible defect in a supported, correctly configured release, the fee is refunded — or credited, if you prefer.

Documentation, Doctor diagnostics and self-service troubleshooting are free for everyone, and reporting a product defect or a security vulnerability never requires a paid review.

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

• Now: v1.0.0-RC1-20261029 — 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
• v1.0 is expected on 1 January 2027
• The code is source-available under BUSL-1.1
• Unchanged either way: backwards-compatible evidence formats and deterministic replay

How to get started →

Directory sign-in is not on by default. The LDAP, OIDC and SAML plugins ship signed with v1.0.0-RC1-20261029 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, and nothing in the current release checks a licence, so nothing is switched off when a subscription ends — production use above 20 placements then needs a renewal or a reduction to 20.

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 help is available on top of that as a paid review of one defined issue, not as 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. You can order today by email: a Licensed plan at sales@stella-ops.org, a support review at support@stella-ops.org. Online checkout is coming soon.

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. Documentation, Doctor and self-service troubleshooting are free on every plan. When you want an engineer, a support review costs $75 for one defined issue: you get an estimated delivery window before you buy and a written engineering response, and the fee is refunded if the main issue turns out to be a reproducible defect in a supported, correctly configured release. No plan carries an ongoing service level. 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 free production use for up to 20 managed placements per installation. Above that, production use needs a Licensed plan, a licence for your placement count. 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. Neither tenants nor environments are priced: pricing counts managed placements across the whole installation.

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 →