Operations and Deployment

Operate heterogeneous targets with one release model

Deploy across Docker, Compose, ECS, Nomad, SSH, and WinRM using digest identified artifacts. Agentless runtime and offline capable workflows keep control in your environment.

Start verified trial See offline kit

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

Image and artifact analysis

SBOM generation, vulnerability matching, and VEX handling for each releasable artifact.

Reachability based prioritization

Static, manifest, and runtime context filters findings down to exploitable risk.

Promotion control

Move artifacts through environments only after policy and approval requirements are met.

Progressive delivery

Canary, blue green, and rollback workflows with traceable change history.

Evidence retention

Decision Capsules preserve policy inputs, approvals, and verdicts for later verification.

Offline continuity

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.

Docker Host

Direct container deployment to Docker hosts.

Docker Compose

Multi-container application deployment.

AWS ECS

ECS and Fargate task deployments.

HashiCorp Nomad

Nomad job deployments and updates.

SSH Targets

Linux/Unix targets over SSH.

WinRM Targets

Windows targets over WinRM.

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.

Immutable artifact identity

Digest pinning prevents drift between security analysis, approval, and runtime deployment.

Promotion provenance

Each promotion records source digest, policy inputs, and approval events in signed evidence.

Deployment patterns

A/B testing

Route controlled traffic percentages to compare behavior before full rollout.

Canary release

Promote to a small subset first and expand only when health criteria remain stable.

Blue/Green

Run previous and candidate versions in parallel and switch traffic in a controlled cutover.

Instant rollback

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.

Offline Update Kit

Signed package containing everything needed to refresh disconnected environments.

→ Vulnerability feeds from 33+ sources
→ Container images for all components
→ Provenance data and SBOMs
→ Delta updates for efficient transfer

No mandatory external egress

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)

Terminal

$ stella offline-kit import stella-ouk-2026-01-20.tar.gz --verify
Verifying bundle signature... OK
Importing vulnerability feeds... 33 sources updated
Importing container images... 12 images loaded
Importing provenance data... OK

Offline Kit imported successfully
Knowledge snapshot: 2026-01-20T00:00:00Z
Next update recommended: 2026-01-27

Configurable crypto profiles

Select cryptographic profiles to match regional requirements while preserving one release workflow.

FIPS?Federal Information Processing Standards - U.S. government cryptographic standards for secure systems · GOST?Russian national cryptographic standards (GOST R 34.10/34.11) required for government systems · SM2?Chinese national public key cryptography standard (part of ShangMi suite) required for regulated industries · eIDAS?Electronic IDentification, Authentication and trust Services - EU regulation for electronic signatures and trust services · PQC?Post-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
`FIPS?Federal Information Processing Standards - U.S. government cryptographic standards for secure systems` 140-2/3 (aligned)	ECDSA P-384, SHA-384	US federal / FedRAMP
`GOST?Russian national cryptographic standards (GOST R 34.10/34.11) required for government systems` R 34.10	`GOST?Russian national cryptographic standards (GOST R 34.10/34.11) required for government systems` R 34.10-2012, Streebog	CIS region compliance
`SM2?Chinese national public key cryptography standard (part of ShangMi suite) required for regulated industries`/SM3	`SM2?Chinese national public key cryptography standard (part of ShangMi suite) required for regulated industries`, SM3	Chinese national standards
`eIDAS?Electronic IDentification, Authentication and trust Services - EU regulation for electronic signatures and trust services`	RSA-PSS, ECDSA (QES)	`eIDAS?Electronic IDentification, Authentication and trust Services - EU regulation for electronic signatures and trust services`-compatible signatures
Dilithium	ML-DSA (Dilithium)	Post-quantum future-proofing

HSM and PKCS#11 integration

Use hardware backed keys for signing and verification operations.

Multi profile signing

Apply multiple signature profiles to a single artifact for cross jurisdiction acceptance.

Infrastructure integration

HashiCorp Vault

Use external secret stores for deployment and signing workflows.

HashiCorp Consul

Integrate service discovery and environment metadata where needed.

Container registries

Connect to standard OCI registries in cloud or on premises deployments.

SCM webhooks

Trigger workflows from repository events across common SCM platforms.

Notifications

Route release and policy events to operational channels and on call systems.

Plugin system

Extend workflows with custom connectors and execution steps.

Platform requirements

Supported Operating Systems

→ 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)

Container Registries

→ Docker Hub
→ AWS ECR (incl. ECR Public)
→ Google Artifact Registry / GCR
→ Azure Container Registry
→ GitHub Container Registry
→ Harbor, Nexus, JFrog Artifactory
→ Any OCI?Open Container Initiative — the industry standard for container image formats and registries-compliant registry

Scale Guidance

→ Up to 100 environments per instance
→ Up to 1,000 targets per environment
→ 50 concurrent deployments
→ 10,000+ scans/month supported
→ Horizontal scaling via HA mode
→ Federated multi-region available

Contact the team for sizing beyond listed guidance.

Minimum Requirements

4 vCPU, 8 GB RAM, 50 GB storage. Docker 20.10+ or Podman 4.0+.

Recommended Production

8 vCPU, 16 GB RAM, 200 GB SSD. PostgreSQL 14+ for HA deployments.

Deployment architecture

Single-node deployment

Compose based topology for evaluation and smaller production footprints.

2 vCPU, 2 GiB RAM minimum
PostgreSQL 16+, Valkey 8.0+
10 GiB SSD for cache and evidence

High-availability deployment

Multi replica topology for production scale and availability.

Multi-replica API and workers
Kubernetes Helm charts available
Dedicated capacity for enterprise

Production operations due diligence

Use this checklist to scope operational effort before production rollout. Stella Ops Suite is currently in closed alpha, so most teams run pilot-first and then harden to HA.

Topology	Control Plane	Data Plane	Typical Use
Pilot	Single-node services with one worker pool	Single Postgres, single object store, single queue/cache	Evaluation and policy tuning
Production baseline	Redundant API/control-plane nodes behind LB	Managed Postgres with backups, durable object store, replicated queue/cache	Steady-state release governance
HA and regulated	Multi-node control plane across failure domains	HA database, immutable evidence storage, tested restore drills	Critical environments and audit-heavy workloads

Backup and restore

Define RPO/RTO for Postgres and evidence object storage. Validate restore with signed capsule replay, not only service health checks.

Upgrade and rollback

Promote platform updates by digest between non-production and production. Keep last-known-good digests and runbooks for fast rollback.

Ops evidence

Track change windows, approvers, and exported evidence packs per upgrade so procurement and audit teams can verify operating discipline.

Ready to run this in your environment

Start with installation guidance or evaluate the offline kit workflow.

Start verified trial Offline Kit guide

Sovereign & Air-Gap · Release Orchestration · All features