Un ordinateur. Pas une image.
De vraies machines Debian 13 qui démarrent en quelques secondes, persistent par défaut et parlent HTTP nativement. Toutes les capacités de Linux, adressables par URL.
Pas un artefact de packaging. Une machine dans laquelle vous travaillez.
Un POST. Dix-huit URLs en ligne.
Chaque conteneur Hoody arrive avec 18 services HTTP intégrés. Dès que le conteneur démarre, vous avez 18 endpoints actifs — pas de setup, pas de déploiement, pas de glue code.
LES CONTENEURS VIVENT DANS DES PROJETS · UN POST → 18 URL HTTP + UN HÔTE SSH
Même pas le même outil.
Docker et les VMs résolvaient des problèmes différents. Hoody est une troisième chose — un ordinateur que vous adressez avec une URL.
Docker package. Hoody compute.
Les conteneurs Docker livrent du logiciel. Les conteneurs Hoody exécutent le logiciel et conservent la machine sur laquelle il tourne — systemd, système de fichiers, stack réseau, 18 services HTTP.
Les VM sont des pets. Les conteneurs sont des URL.
Les VM supposent SSH et de la config manuelle. Les conteneurs Hoody exposent chaque capacité en HTTPS — une URL que votre équipe, votre curl et votre IA parlent tous nativement.
Un seul noyau, des centaines de machines.
VM avec hyperviseur : 5 à 20 par serveur. Conteneurs Hoody : des centaines. Isolation au niveau du noyau avec des frontières dignes d'une VM, sans la surcharge d'une VM.
Docker a résolu le packaging. Hoody a résolu le computing.
(Vous pouvez toujours faire tourner Docker dans un conteneur Hoody.)
Imposée par le noyau. Pas au niveau applicatif.
Chaque conteneur est une frontière de sécurité, pas une frontière de processus. S'en échapper exige un exploit noyau, pas un bug applicatif.
Système de fichiers propre
Les conteneurs ne voient pas les fichiers les uns des autres. Pas de volumes partagés par défaut. Chacun a sa propre racine, son propre /home, son propre /etc.
Réseau propre
Adresse IP propre, table de routage propre, DNS propre. Les conteneurs se parlent via des URL HTTP — le même protocole que deux ordinateurs quelconques sur internet.
Processus propres
Les namespaces PID garantissent qu'un conteneur compromis ne peut ni voir ni envoyer de signal à ses voisins. Pas de kill -9 par-dessus la frontière.
Noyau durci 7.1-hoody
Filtres seccomp et syscalls restreints. Isolation de niveau VM au niveau noyau. Micro-VM Firecracker disponibles quand il vous en faut encore plus.
Du bare-metal qui vous appartient vraiment.
Chaque conteneur tourne sur du matériel que vous louez sur la marketplace — pas sur l'infrastructure mutualisée d'un fournisseur cloud. Pas d'hyperviseur partagé, pas de voisin bruyant, pas de locataire d'un locataire. Le modèle d'isolation ne fonctionne que si la machine en dessous est la vôtre.
Ingress + egress. Par container.
Chaque conteneur arrive avec son propre firewall. Autorisez ou rejetez par port, protocole, IP et plage source. Pas de pont partagé, pas de voisin bruyant, pas de surprise.
Pilotez-les comme du code.
Les conteneurs passent d'un état à l'autre via HTTP. Démarrer, mettre en pause, reprendre, snapshot, copier, synchroniser — chaque verbe est un POST.
En cours de provisioning
Tous les services disponibles
Figé en RAM, reprise en ~1s
Arrêté, système de fichiers préservé
Duplication, nouvel ID, nouvelles URLs
Diagnostiquez ou supprimez
POST/api/v1/containers/CONTAINER_ID/start
POST/api/v1/containers/CONTAINER_ID/stop
POST/api/v1/containers/CONTAINER_ID/force-stop
POST/api/v1/containers/CONTAINER_ID/restart
POST/api/v1/containers/CONTAINER_ID/pause
POST/api/v1/containers/CONTAINER_ID/resume
POST/api/v1/containers/CONTAINER_ID/copy
POST/api/v1/containers/CONTAINER_ID/sync
POST/api/v1/containers/CONTAINER_ID/snapshots
Relancé après n'importe quel reboot.
Les conteneurs redémarrent automatiquement au boot du serveur, après une maintenance ou après une reprise d'alimentation. Activé par défaut — votre machine revient toute seule.
Clonez-le. Synchronisez-le.
Copy crée un duplicata indépendant — nouvel ID, nouvelle clé SSH, nouvelles URL, tous les snapshots précédents inclus. Sync récupère les changements depuis la source. La reprise après sinistre cross-region reste efficace en CoW. Clonez un environnement de dev pour un nouveau coéquipier en un seul POST.
Des conteneurs à l'infini.
KSM et BTRFS partagent les blocs identiques. Vous ne payez que ce qui diffère.
Les VM traditionnelles consomment des ressources fixes, que vous les utilisiez ou non. Une VM 2 cœurs, 4 Go coûte la même chose au repos qu'en charge.
Les conteneurs Hoody utilisent KSM (Kernel Samepage Merging) et la déduplication BTRFS pour partager les pages mémoire et blocs de stockage identiques entre conteneurs. Cent conteneurs qui font tourner le même Debian de base ne consomment pas 100x la mémoire. Ils partagent ce qui est identique et ne paient que ce qui diffère.
Les conteneurs de développement coûtent presque rien au repos.
Les test runners partagent la mémoire de l'OS de base avec la production.
Les environnements ne sont plus une question de budget.
Un conteneur par branche devient pratique, pas extravagant.
Vous ne rationnez plus les ordinateurs. Vous les lancez.
Git a donné le contrôle de version au code. Hoody le donne à des ordinateurs entiers.
1 à 5 secondes pour capturer, quelle que soit la taille du container. Copy-on-write au niveau du système de fichiers — dix snapshots d'un conteneur de 50 Go coûtent 50 Go plus les changements, pas 500 Go. Branchez comme avec git. Sans limite.
IMAGES DE BASE
Uniquement des modèles de système d'exploitation de base — l'image vous donne la distribution. hoody_kit ajoute les 18 services HTTP par-dessus (true par défaut) ; dev_kit ajoute des outils de développement au-dessus (true par défaut quand hoody_kit vaut true). Mettez hoody_kit: false pour un conteneur Linux basique en SSH uniquement.
Lancez-en un pour n'importe quoi.
Quand un Linux tout frais coûte quelques secondes et des ressources marginales quasi nulles, la question n'est plus « faut-il en utiliser un ? » — c'est « pourquoi ne pas en lancer un autre ? »
Environnements de dev
Un Debian tout frais en quelques secondes avec 18 URL et un hôte SSH. Il persiste après les reboots. Le setup laptop de votre équipe, standardisé et accessible de partout.
Sandboxes IA
Chaque agent a le sien. Rayon d'impact isolé pour le code généré par l'IA. Snapshot avant chaque run, retour en arrière en 1s si l'agent saccage tout.
Branches par feature
Lancez un conteneur par PR. Partagez l'URL. Laissez les reviewers tester en direct. KSM garde le coût stable, quel que soit le nombre de branches ouvertes.
Clones de staging
Copie la production en staging en un POST — nouvel ID, nouvelles URLs, même état. La reprise après sinistre cross-region est efficace en CoW par défaut.
Tests E2E
Test runners en parallèle, chacun dans son propre Linux. Vrai navigateur, vrai filesystem, vrai réseau. Pas de mocks, pas de pont partagé, pas d'instabilité.
Enseignement et démos
Partagez une URL — les étudiants sont dans le même terminal. Multijoueur par architecture, pas de VPN, pas de clés SSH à distribuer.
Votre IA parle déjà HTTP.
Les conteneurs Hoody parlent HTTP. L'intégration, c'est le protocole — pas de SDK à installer, pas d'adaptateur, pas de wrapper. Donnez une URL à l'agent et il pilote une machine Linux.
L'intégration, c'est le protocole. N'importe quel agent qui parle HTTP peut faire du SSH, lire des fichiers, exécuter des commandes, requêter SQLite, piloter le navigateur — chaque capacité est un endpoint.
Isolé de votre hôte. Snapshot avant chaque appel d'outil. Retour en arrière en 1 seconde si l'agent écrit n'importe quoi. Pas besoin du root de votre laptop.
Le service agent expose toute la surface de capacités du container. @hoody.com est une Skill que n'importe quelle IA avec un navigateur peut adopter — zéro travail d'intégration.
Chaque sous-agent a son propre container. Branchez comme avec git, mergez ce qui marche, jetez ce qui ne marche pas. Travail parallèle, zéro état partagé, piste d'audit par agent.
L'IA n'a pas besoin d'apprendre votre API. Elle parle déjà HTTP.
Arrêtez de louer des VM. Commencez à lancer des ordinateurs.
Une abstraction. Un modèle mental. Un schéma d'URL.
Tarification transparente à l'usage — voir /pricing.