Operations and Deployment
Operate heterogeneous targets with one release model
Deploy across Docker, Compose, SSH, and WinRM using digest identified artifacts. Agentless runtime and offline capable workflows keep control in your environment.
What this means for your business
Run one release process across Linux and Windows targets without forcing Kubernetes adoption. Stella links deployment actions to policy evidence so operations and audit stay aligned.
What this operating model covers
SBOM generation, vulnerability matching, and VEX handling for each releasable artifact.
Static, manifest, and runtime context filters findings down to exploitable risk.
Move artifacts through environments only after policy and approval requirements are met.
Canary, blue green, and rollback workflows with traceable change history.
Decision Capsules preserve policy inputs, approvals, and verdicts for later verification.
Air-gapped sites receive signed update kits and keep release control without internet access.
Non-Kubernetes first
Most release platforms prioritize Kubernetes paths. Stella treats non-Kubernetes targets as first class and keeps the same promotion model across each runtime.
Direct container deployment to Docker hosts.
Multi-container application deployment.
and Fargate task deployments.
job deployments and updates.
Linux/Unix targets over SSH.
Windows targets over WinRM.
Scripted (.NET 10) targets are also supported: custom deployment logic runs through the.NET scripting engine when a rollout does not fit the built-in target types.
Deployment target count is not restricted by pricing tier.
Digest-first release identity
Releases are tracked by immutable digests rather than mutable tags, ensuring the artifact scanned and approved is the artifact deployed.
Digest pinning prevents drift between security analysis, approval, and runtime deployment.
Each promotion records source digest, policy inputs, and approval events in signed evidence.
Deployment patterns
Route controlled traffic percentages to compare behavior before full rollout.
Promote to a small subset first and expand only when health criteria remain stable.
Run previous and candidate versions in parallel and switch traffic in a controlled cutover.
Return to a prior digest quickly while preserving full evidence of forward and rollback actions.
Offline operation without control loss
Policy decisions and verification remain available without external network access. Feed and artifact updates arrive through signed transfer bundles.
Signed package containing everything needed to refresh disconnected environments.
- → Vulnerability feeds from 38 sources
- → Container images for all components
- → Provenance data and SBOMs
- → Delta updates for efficient transfer
Core release and evidence workflows execute within sovereign networks.
- → Local vulnerability database
- → Offline signature verification
- → Deterministic replay without network
- → No mandatory telemetry (opt-in only, disabled by default)
$ stella offline import --bundle stella-ouk-2026-01-20.tar.zst --verify-dsse --verify-rekor
Configurable crypto profiles
Select cryptographic profiles to match regional requirements while preserving one release workflow.
FIPSFederal Information Processing Standards - U.S. government cryptographic standards for secure systems · SM2Chinese national public key cryptography standard (part of ShangMi suite) required for regulated industries · eIDASElectronic IDentification, Authentication and trust Services - EU regulation for electronic signatures and trust services · PQCPost-Quantum Cryptography - cryptographic algorithms designed to be secure against quantum computer attacks
| Profile | Algorithms | Use Case |
|---|---|---|
| Default | Ed25519, ECDSA P-256, SHA-256 | Standard deployments |
FIPSFederal Information Processing Standards - U.S. government cryptographic standards for secure systems 140-2/3 (aligned) | ECDSA P-384, SHA-384 | US federal / FedRAMP |
SM2Chinese national public key cryptography standard (part of ShangMi suite) required for regulated industries/SM3 | SM2Chinese national public key cryptography standard (part of ShangMi suite) required for regulated industries, SM3 | Chinese national standards |
eIDASElectronic IDentification, Authentication and trust Services - EU regulation for electronic signatures and trust services | RSA-PSS, ECDSA (QES) | eIDASElectronic IDentification, Authentication and trust Services - EU regulation for electronic signatures and trust services-compatible signatures |
| Post-quantum readiness assessment (inventory, not signing) | See CBOM analysis → | |
Use hardware backed keys for signing and verification operations.
Apply multiple signature profiles to a single artifact for cross jurisdiction acceptance.
Infrastructure integration
Use external secret stores for deployment and signing workflows.
Integrate service discovery and environment metadata where needed.
Connect to standard OCI registries in cloud or on premises deployments.
Trigger workflows from repository events across common SCM platforms.
Route release and policy events to operational channels and on call systems.
Extend workflows with custom connectors and execution steps.
Platform requirements
- → Ubuntu 20.04, 22.04, 24.04 LTS
- → RHEL/CentOS 8, 9
- → Debian 11, 12
- → Amazon Linux 2, 2023
- → Windows Server 2019, 2022
- → Alpine 3.18+ (containers)
- → Docker Hub
- → AWS ECR (incl. ECR Public)
- → Google Artifact Registry / GCR
- → Azure Container Registry
- → GitHub Container Registry
- → Harbor, Nexus, JFrog Artifactory
- → Any
OCIOpen Container Initiative — the industry standard for container image formats and registries-compliant registry
- → Up to 100 environments per instance
- → Up to 1,000 targets per environment
- → 50 concurrent deployments
- → 10,000+ scans/month supported
Contact the team for sizing beyond listed guidance.
Recommended production baseline
4 vCPU, 16 GB RAM, 50 GB storage. Docker Engine 23.0+ with Compose v2. This is the starting point for production, not the smallest configuration that runs — headroom above it grows with environments and scan volume.
Headroom for larger estates
8 vCPU, 16 GB RAM and 200 GB SSD give headroom above the measured 4 vCPU / 16 GiB baseline. This is guidance for a larger single instance, not a clustered configuration.
Deployment architecture
Compose based topology for evaluation and smaller production footprints.
- 4 vCPU, 16 GiB RAM — runs the full suite
- PostgreSQL 16+, Valkey 8.0+
- 50 GiB SSD for cache and evidence
Inputs from CI, registries, and advisory feeds are normalized into one decision path. Each gate adds signed evidence tied to the artifact digest.
Production operations due diligence
Use this checklist to scope operational effort before production rollout. Start at the topology that matches your estate and harden from there.
| Topology | Control Plane | Data Plane | Typical Use |
|---|---|---|---|
| Shipped bundle | Single-node services with one worker pool | Single Postgres, single object store, single queue/cache | Evaluation and policy tuning |
Define RPO/RTO for Postgres and evidence object storage. Validate restore with signed capsule replay, not only service health checks.
Promote platform updates by digest between non-production and production. Keep last-known-good digests and runbooks for fast rollback.
Track change windows, approvers, and exported evidence packs per upgrade so procurement and audit teams can verify operating discipline.
Self-serve diagnostics are built in. stella doctor runs 110+ checks across 16 domains: connectivity, permissions, registry access, configuration, and license status. Most problems are resolved from its output without a support ticket, and Doctor is available on every tier including Free.
Ready to run this in your environment
Start with installation guidance or evaluate the offline kit workflow.