v1.1 · GitHub Enterprise Server & GitLab Self-Managed
Previewd construit la version exacte proposée par une demande de fusion, l'exécute dans un conteneur isolé sur votre serveur, lui attribue une adresse web, puis supprime l'ensemble à la fermeture. Un binaire statique, aucun compte cloud, aucun octet transmis à un tiers.
Tarifs Open Source 0€ Pro 19€ / mois Agence 79€ / mois.deb / .rpmLe problème
Une demande de fusion affirme que le code fonctionne. Le vérifier suppose aujourd'hui soit un environnement de test partagé, que les équipes dégradent progressivement, soit un service de prévisualisation hébergé — c'est-à-dire transmettre votre code, et souvent vos secrets, à un tiers.
Banques, hôpitaux, opérateurs d'importance vitale : le code source constitue fréquemment l'actif le plus sensible de l'organisation. Le confier à un service cloud externe n'est pas envisageable, et un réseau isolé ne dispose d'aucun accès à Internet.
Un environnement de recette commun, un seul jeu de données, un seul jeu de secrets. Deux branches testées simultanément s'interfèrent, et l'identification de la version réellement exécutée devient impossible lorsqu'une anomalie survient.
« Qui a autorisé le déploiement de cette branche, à quelle heure, sur quel commit ? » Sans journal infalsifiable, la réponse repose sur la mémoire des intervenants. Un auditeur exige une preuve.
Fonctionnement
Un seul chemin d'exécution, sans exception. Chaque étape est couverte par un test et chaque refus est journalisé.
Votre forge transmet un événement sur TLS. Previewd vérifie la signature HMAC du corps brut et l'origine réseau, puis refuse tout corps supérieur à 1 Mio. Une livraison rejouée n'est jamais traitée deux fois.
422 → 202 → job durable en base
Une branche du dépôt poussée par un utilisateur disposant du droit d'écriture déclenche le déploiement. Pour une fourche ou un contributeur externe, Previewd exige la validation de ce commit précis par un approbateur nommé. Le statut est relu auprès de la forge, jamais déduit de l'événement.
Chaque décision entre dans la piste d'audit
Le code est récupéré sous forme d'archive avec un jeton limité au dépôt, révoqué après
usage. Le Dockerfile est soumis à un contrôle strict qui n'accepte que les instructions
reconnues : toute instruction inconnue entraîne un refus. BuildKit construit ensuite avec networkmode=none
dans un cgroup borné.
Au démarrage, une sonde de construction doit échouer à joindre le réseau, sinon le démon refuse de démarrer
Chaque environnement dispose de son propre réseau interne, sans route par défaut. Les
capacités sont retirées, no-new-privileges est activé et le système de
fichiers racine est monté en lecture seule. Les secrets sont fournis sous forme de
fichiers en mémoire, en lecture seule, jamais par variable d'environnement.
Aucun label Docker, aucun socket Traefik : une image ne peut pas s'ajouter une route
Une route atomique est écrite pour Traefik ; le lien est publié en commentaire et en statut de commit sur la demande de fusion. À la fermeture, au retrait de l'approbation ou à l'expiration du TTL, Previewd supprime conteneur, réseau, image, route et secrets — dans cet ordre, chaque étape s'exécutant même si la précédente échoue.
TTL par défaut : 7 jours, sans nouvelle poussée
Éléments de preuve
Chaque affirmation ci-dessous est adossée à un contrôle exécuté à chaque intégration. Un binaire liant un SDK de télémétrie ne se compile pas. Une construction atteignant le réseau fait échouer la sonde de démarrage. Une route orpheline empêche le démon de démarrer.
Une sonde exécute une construction réelle : elle vérifie qu'aucune interface hors boucle locale n'existe, qu'aucune route ne mène ailleurs et que la connexion TCP échoue. Si la sonde réussit à sortir, le démon refuse de démarrer.
Les clés de Previewd sont des identifiants systemd. Les secrets applicatifs vivent en
mémoire verrouillée et n'atteignent le conteneur que comme fichiers d'un ramfs
en lecture seule. Ni variable d'environnement, ni docker inspect, ni couche d'image.
Chaque décision d'autorisation est écrite dans un journal append-only où chaque entrée
scelle la précédente. Previewd audit verify rejoue la chaîne ;
audit export produit une preuve lisible par un tiers.
Traefik lit un unique dossier de fichiers de routes, en lecture seule, sans API ni fournisseur Docker. Une image compromise ne peut pas fabriquer une route : elle n'a aucun moyen d'en écrire une.
Le contrôle du Dockerfile ne bloque pas une liste de choses dangereuses : il n'autorise qu'une liste de choses comprises. Une directive ajoutée par une future version de Docker devient un refus, pas une faille silencieuse.
Un contrôle sur le binaire lié échoue si OpenTelemetry, gRPC ou un SDK cloud apparaît dans les dépendances. Un second contrôle analyse le code et les fichiers de déploiement. L'absence de fuite est mesurée, pas déclarée.
La suite de bout en bout fait exécuter à une demande de fusion une connexion TCP et une requête DNS vers un écouteur de l'hôte : aucune ne doit aboutir. Une construction témoin, elle, doit l'atteindre — à défaut, le test ne démontrerait rien et échouerait.
Onze configurations TLA+ couvrent la file, les approbations, le redémarrage, le TTL et les workers. En parallèle, des tests par propriétés génèrent des millions de séquences d'événements pour chercher une violation d'invariant — pas un exemple choisi à la main.
Au démarrage, un balayage inventorie ce qui tourne, détruit ce qui n'est plus gardé, vérifie qu'aucune route n'oriente vers un environnement non gardé — et refuse de servir si ce n'est pas le cas.
Pour qui
Le confort obtenu par l'équipe de développement constitue, pour le responsable de la sécurité, un élément de preuve. Le mécanisme est identique.
Développement
Sécurité & conformité
Exploitation
.deb et .rpm signables, installables sans dépôt distantPreviewd doctor vérifie l'hôte et rend un code de sortie exploitablebackup / restore à chaud, avec vérification de la chaîne d'auditDéploiement
Le paquet installe le binaire, l'unité systemd, la tranche de construction et la configuration Docker. Il crée un utilisateur système sans shell ni répertoire personnel. Avant le premier démarrage, Previewd vérifie les prérequis et refuse de s'exécuter tant qu'ils ne sont pas satisfaits.
Aucune image n'est téléchargée à l'exécution : Previewd refuse une image de base absente du démon. Le comportement est le même sur un hôte connecté — c'est ce qui rend le déploiement prévisible.
# 1. installer, sans dépôt ni réseau
sudo apt install ./Previewd_1.1.0_amd64.deb
# 2. configurer les chemins et identifiants (jamais un secret)
sudo editor /etc/Previewd/Previewd.conf
# 3. sceller les identifiants, vérifier l'hôte, démarrer
sudo Previewd doctor
sudo systemctl enable --now PreviewdTarifs
Le logiciel est identique dans les trois offres. Seule diffère la personne qui l'administre : votre organisation, nos équipes ou votre direction des systèmes d'information. Aucune option ne crée de dépendance : le binaire reste exportable et vos secrets demeurent dans l'infrastructure que vous avez choisie.
01 · Communauté
Pour les organisations qui souhaitent auditer, vérifier et héberger l'ensemble de la solution. L'infrastructure reste sous votre contrôle.
0€ pour toujours
Paquet .deb / .rpm · aucun compte
02 · Freelance & agences
Pour présenter des aperçus à vos clients sans leur communiquer de code, et sans administrer un serveur par projet.
19€ / mois
Pour les indépendants qui doivent présenter leurs réalisations sans les héberger.
Paiement par carte · résiliable en un clic
0€ / mois
Pour une première évaluation sur un projet réel, sans carte bancaire.
Aucune carte demandée
79€ / mois
Pour les équipes qui font valider chaque écran par leurs clients.
Paiement par carte · résiliable en un clic
03 · Enterprise & souveraineté
Pour les organisations dont le code ne peut pas sortir et dont les auditeurs exigent des preuves.
À partir de 1 000+ € / an
Facturation annuelle · bon de commande accepté
| Fonctionnalité | Communauté | Hobby | Pro | Agence | Enterprise |
|---|---|---|---|---|---|
| Environnements actifs | Illimités | 3 | Illimités | Illimités | Illimités |
| Durée de vie (TTL) | Configurable | 24 heures | 7 jours | 7 jours | Configurable |
| Domaines personnalisés | Oui | — | Oui | Oui | Oui |
| Sidecars compose | Oui | — | Oui | Oui | Oui |
| Journaux de construction | Sur l'hôte | — | Dans le navigateur | Dans le navigateur | Avec export |
| Chaîne d'audit vérifiable | Oui | Oui | Oui | Oui | Oui |
| Liens de revue pour vos clients | — | — | — | Oui | Oui |
| Déploiement isolé, sans Internet | Oui | — | — | — | Oui |
| Rapports de conformité | — | — | — | — | Oui |
| Support | Communauté | Communauté | Prioritaire | Prioritaire | SLA contractuel |
| Facturation | Aucune | Aucune | 19 €/mois | 79 €/mois | 1 500 – 25 000 €+/an |
Prix hors taxes ; la TVA est ajoutée au paiement selon votre pays. Les abonnements Cloud sont payés par carte bancaire via Stripe et résiliables à tout moment, sans frais. Les offres Enterprise sont facturées annuellement, sur bon de commande, avec un devis chiffré après un échange technique.
Questions fréquentes
Pour l'usage — consulter une demande de fusion en exécution — oui. Pour l'administration, non : il n'existe ni tableau de bord web ni gestion des utilisateurs. Previewd s'appuie sur la forge déjà en place : les droits, les approbations et les commentaires y demeurent. Ce choix réduit la surface exposée et le nombre de comptes à administrer.
Non. L'installation se fait depuis un paquet, les images de base doivent être présentes localement, les dépendances de compilation sont figées dans le dépôt, et le binaire n'embarque aucun client de télémétrie — un contrôle de CI échoue s'il en apparaît un. La seule sortie réseau est celle que vous configurez vers votre forge.
Au démarrage, Previewd inventorie les conteneurs, les réseaux et les routes existants, détruit ce qu'aucun environnement gardé ne réclame, puis vérifie une condition finale : aucune route publiée ne doit pointer vers un environnement non gardé. Si la condition est fausse, le démon refuse de servir plutôt que de servir un état incohérent.
Non. Une demande de fusion issue d'une fourche reste en attente, sans construction, jusqu'à ce qu'une personne nommée dans la configuration approuve ce commit précis. Une nouvelle poussée annule l'approbation et replace l'environnement en attente. Le retrait de l'approbation entraîne sa suppression.
Ils ne sont jamais écrits sur disque : ils vivent dans un ramfs, en fichiers 0444, montés en lecture seule dans le conteneur. Ils ne passent ni par une variable d'environnement, ni par l'API Docker, ni par une couche d'image. Au redémarrage, ils disparaissent — et doivent être restagés, ce qui est le comportement voulu.
Non, et ce choix est assumé. Previewd est un agent mono-nœud : il en résulte un état vérifiable, un modèle formel complet et une exploitation maîtrisable sur un réseau isolé. Un cluster réparti exigerait un consensus, donc une mécanique que ce produit ne fournit pas.
Elles doivent construire une image à partir d'une image de base autorisée et ne pas avoir besoin d'écrire hors de leur répertoire de travail. Les applications qui écrivent au démarrage peuvent s'appuyer sur les services annexes de la composition, qui disposent de systèmes de fichiers temporaires bornés.
Évaluation
L'évaluation se déroule dans votre infrastructure : un hôte, un paquet, votre forge. Nous accompagnons l'installation et la revue du modèle de menace ; la décision vous revient, sur la base de preuves.