Opérations et déploiement
Déployez partout. Prouvez tout.
Déployez sur Docker, Compose, SSH et WinRM à l'aide d'artefacts identifiés par digest. L'exécution sans agent et les workflows compatibles hors ligne maintiennent le contrôle dans votre environnement.
Ce que cela signifie pour votre entreprise
Déployez sur n'importe quel serveur Linux ou Windows sans Kubernetes, agents ni dépendances cloud. Stella gère les rollbacks, la promotion canary et l'export de preuves pour chaque cible.
Ce que vous opérez ici
génération SBOMSoftware Bill of Materials – une liste complète de tous les packages et dépendances de votre logiciel, correspondance CVECommon Vulnerabilities and Exposures – un identifiant unique pour une vulnérabilité de sécurité publiquement connue, gestion des instructions VEXVulnerability Exploitability eXchange – déclarations lisibles par machine indiquant si les vulnérabilités sont réellement exploitables dans votre contexte pour chaque image de conteneur.
Analyse statique, manifeste et d’exécution pour séparer les risques exploitables des risques théoriques.
Déplacez les images entre les environnements via des portes de stratégie avec une traçabilité complète.
Tests A/B, canary, déploiements blue/green et rollback instantané sur les cibles.
Les Decision Capsules regroupent toutes les entrées, politiques et verdicts pour l'audit et la conformité.
Les sites air-gapped recoivent des kits de mise a jour signes et conservent le controle des releases sans acces Internet.
Non-Kubernetes en priorité
La plupart des outils CD traitent le non-Kubernetes comme une arrière-pensée. Stella le traite comme cas d'utilisation principal — et toutes les cibles sont sans agent par conception.
Déploiement direct de conteneurs vers les hôtes Docker.
Déploiement d'applications multi-conteneurs.
Déploiements de tâches et Fargate.
Déploiements et mises à jour de jobs.
Cibles Linux/Unix via SSH.
Cibles Windows via 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.
Cibles de déploiement illimitées à tous les niveaux tarifaires
Identite de release digest-first
Chaque version est identifiée par son digest de contenu, et non par une balise mutable. Cela garantit que ce qui a été analysé est ce qui est déployé, et ce qui est audité est ce qui a réellement été exécuté.
L'épinglage des digests empêche toute dérive entre l'analyse de sécurité, l'approbation et le déploiement à l'exécution.
Chaque promotion enregistre le digest de la source, la version de la politique et la preuve d'approbation dans une attestation signée.
Modèles de déploiement
Acheminez un pourcentage du trafic vers la nouvelle version. Comparez les métriques avant de vous engager.
Déployez d'abord sur un petit sous-ensemble de cibles. Annulation automatique en cas d'échec du contrôle d'état.
Exécutez les anciennes et les nouvelles versions en parallèle. Basculez le trafic de manière atomique lorsque vous êtes prêt.
Revenir à toute version précédente vérifiée par digest. Piste de preuves préservée pour l'avant et l'arrière.
Fonctionnement hors ligne sans perte de contrôle
Les décisions principales fonctionnent sans dépendances externes. Les flux de vulnérabilités et la vérification des preuves fonctionnent entièrement dans votre périmètre.
Bundle signé avec tout le nécessaire pour le fonctionnement en air-gap.
- → Flux de vulnérabilités depuis 33+ sources
- → Images de conteneurs pour tous les composants
- → Données de provenance et SBOMs
- → Mises à jour delta pour transfert efficace
Chaque opération fonctionne dans les réseaux souverains.
- → Base de données de vulnérabilités locale
- → Vérification de signature hors ligne
- → Rejeu déterministe sans réseau
- → Aucune télémétrie obligatoire (opt-in uniquement)
$ stella offline import --bundle stella-ouk-2026-01-20.tar.zst --verify-dsse --verify-rekor
Profils crypto souverains
Profils cryptographiques modulables pour la conformité régionale. Choisissez vos algorithmes sans changer votre workflow.
FIPSFederal Information Processing Standards – normes cryptographiques du gouvernement américain pour les systèmes sécurisés · SM2Norme nationale chinoise de cryptographie à clé publique (suite ShangMi) requise pour les industries réglementées · eIDASElectronic IDentification, Authentication and trust Services – règlement européen pour les signatures électroniques et les services de confiance · PQCCryptographie Post-Quantique – algorithmes cryptographiques conçus pour résister aux attaques des ordinateurs quantiques
| Profil | Algorithmes | Cas d'usage |
|---|---|---|
| Par défaut | Ed25519, ECDSA P-256, SHA-256 | Déploiements standards |
FIPSFederal Information Processing Standards – normes cryptographiques du gouvernement américain pour les systèmes sécurisés 140-2/3 (aligné) | ECDSA P-384, SHA-384 | Fédéral US / FedRAMP |
SM2Norme nationale chinoise de cryptographie à clé publique (suite ShangMi) requise pour les industries réglementées/SM3 | SM2Norme nationale chinoise de cryptographie à clé publique (suite ShangMi) requise pour les industries réglementées, SM3 | Standards nationaux chinois |
eIDASElectronic IDentification, Authentication and trust Services – règlement européen pour les signatures électroniques et les services de confiance | RSA-PSS, ECDSA (QES) | Signatures compatibles eIDASElectronic IDentification, Authentication and trust Services – règlement européen pour les signatures électroniques et les services de confiance |
| Évaluation de l'état de préparation post-quantique (inventaire, pas de signature) | Voir l'analyse CBOM → | |
Modules de sécurité matériels pour le stockage des clés et les opérations de signature.
Signez le même artefact avec plusieurs algorithmes pour la conformité multi-juridictionnelle.
Intégration d'infrastructure
Injection de secrets pour les déploiements.
Intégration du registre de services.
Connectez des registres OCI standard pour les déploiements cloud ou sur site.
Déclencheurs GitHub, GitLab, Bitbucket.
Slack, Teams, e-mail, PagerDuty, OpsGenie.
Connecteurs personnalisés et étapes de workflow.
Exigences de plateforme
- → Ubuntu 20.04, 22.04, 24.04 LTS
- → RHEL/CentOS 8, 9
- → Debian 11, 12
- → Amazon Linux 2, 2023
- → Serveur Windows 2019, 2022
- → Alpine 3.18+ (conteneurs)
- → Docker Hub
- → AWS ECR (incl. ECR Public)
- → Google Artifact Registry / GCR
- → Azure Container Registry
- → GitHub Container Registry
- → Harbor, Nexus, JFrog Artifactory
- → Tout registre compatible
OCIOpen Container Initiative — le standard industriel pour les formats d'images de conteneurs et les registres
- → Jusqu’à 100 environnements par instance
- → Jusqu’à 1 000 cibles par environnement
- → 50 déploiements simultanés
- → 10 000+ scans/mois pris en charge
Contactez les ventes pour des déploiements plus importants
Exigences minimales
4 vCPU, 16 Go de RAM, 50 Go de stockage. Docker Engine 23.0+ avec Compose v2. C'est le point de départ pour la production, pas la plus petite configuration qui fonctionne : la marge au-dessus croît avec les environnements et le volume d'analyse.
Marge pour les parcs plus grands
8 vCPU, 16 Go de RAM et 200 Go de SSD offrent de la marge au-dessus de la base mesurée de 4 vCPU / 16 Gio. C'est une recommandation pour une instance unique plus grande, pas une configuration en cluster.
Architecture de déploiement
Docker Compose pour évaluation et petites équipes.
- 4 vCPU, 16 Gio de RAM — fait tourner toute la suite
- PostgreSQL 16+, Valkey 8.0+
- 50 GiB SSD for cache and evidence
Le plan de contrôle Stella Ops se situe entre vos entrées (CI/CD, registres, feeds) et vos sorties (cibles de déploiement, systèmes d’audit). Les preuves transitent et sont scellées à chaque étape.
Due Diligence des opérations de production
Utilisez cette liste de contrôle pour définir l'effort opérationnel avant le déploiement en production. Commencez par la topologie qui correspond à votre parc, puis renforcez-la à partir de là.
| Topologie | Plan de contrôle | Plan de données | Utilisation typique |
|---|---|---|---|
| Bundle livré | Services à nœud unique avec un pool de nœuds de calcul | Postgres unique, magasin d'objets unique, file d'attente/cache unique | Évaluation et réglage des politiques |
Définissez le RPO/RTO pour Postgres et le stockage d'objets de preuves. Validez la restauration avec une relecture de capsule signée, et pas seulement avec des vérifications de l'état du service.
Promouvoir les mises à jour de la plateforme par synthèse entre la non-production et la production. Conservez les derniers résumés et runbooks connus pour une restauration rapide.
Suivez les fenêtres de modification, les approbateurs et les ensembles de preuves exportés par mise à niveau afin que les équipes d'approvisionnement et d'audit puissent vérifier la discipline opérationnelle.
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.
Prêt pour un déploiement souverain ?
Commencez par le guide d'installation ou le Offline Kit.
Souveraineté et Air-Gap · Orchestration des releases · Toutes les fonctionnalités