Faites tourner des dizaines de conteneurs sur un seul serveur sans sacrifier l'isolation.
Le partage de mémoire KSM maximise la densité sur le bare metal. Firecracker + LXC appliquent l'isolation par conteneur. L'imprévisibilité des URLs, la ségrégation par realm et le firewall au niveau hôte s'ajoutent — chacun peut échouer et les autres stoppent encore la propagation.
KSM · LXC + Firecracker · AES-256 · Espace de clés URL 2^192 · défense en profondeur
Pages partagées, mémoire séparée.
Kernel Samepage Merging regroupe les pages mémoire identiques entre conteneurs en copies physiques uniques. Une image Debian de base, un runtime Node, une installation Postgres — tous les octets que partage chaque conteneur du serveur sont comptés une seule fois en RAM.
Pages identiques dédupliquées
Les pages RAM au contenu identique (bibliothèques communes, OS de base, runtimes partagés) sont fusionnées. 30 conteneurs Node sur un serveur consomment bien moins de mémoire que 30× un conteneur.
Isolation préservée
Les conteneurs ne peuvent pas lire la RAM des autres. KSM est une optimisation de stockage — les pages fusionnées deviennent copy-on-write. Toute écriture crée une copie privée instantanément.
Aucun travail côté conteneur
KSM est au niveau noyau. Les applications n'ont pas besoin de le savoir. Le conteneur voit une mémoire Linux normale ; l'hôte voit la déduplication physique.
Bénéfice dépendant de la charge
Le bénéfice évolue avec la quantité de partage entre conteneurs. Stacks similaires = déduplication massive. Apps très différentes = moins de déduplication, mais les pages OS de base se fusionnent quand même.
LXC + Firecracker. Namespaces noyau + micro-VMs.
Hoody utilise un modèle d'isolation à double couche. LXC fournit une isolation de conteneur Linux légère via les namespaces. Firecracker ajoute des frontières de micro-VM assistées par le hardware là où une séparation plus forte est importante. Le noyau hôte est durci (base Linux 7.0.2-hoody) avec le filtrage syscall seccomp par-dessus.
Namespaces LXC
Processus, réseau, montage, utilisateur, PID, IPC — chaque conteneur a sa propre vue du noyau. Mécanisme Linux standard, éprouvé à grande échelle.
Micro-VMs Firecracker
Frontières virtualisées par le hardware. La technologie d'isolation d'AWS Lambda. Appliquée là où un conteneur a besoin d'un mur encore plus dur que les namespaces seuls.
Noyau durci
Base Linux 7.0.2-hoody avec durcissement de sécurité. Les filtres seccomp limitent les syscalls qu'un conteneur peut faire.
Base bare metal
Les conteneurs s'exécutent sur le hardware appartenant à l'utilisateur. Pas d'hyperviseur partagé avec d'autres tenants. Pas de canaux secondaires bruit-voisin depuis le fournisseur cloud au-dessus de vous.
AES-256 partout où les données touchent le disque.
Chiffrement du système de fichiers, swap chiffré, fichiers temporaires chiffrés. Déverrouillage distant via sous-partition. Le disque est du texte chiffré ; le déchiffrement se produit en RAM au démarrage.
Système de fichiers AES-256
Chaque octet écrit sur le disque est chiffré. Perdez le disque, ne perdez rien de lisible.
Swap + temp chiffrés
Les pages de swap et les fichiers temporaires n'atteignent jamais le disque en clair. Les dumps mémoire noyau sont aussi chiffrés.
Déverrouillage distant via sous-partition
Le flux de démarrage supporte le déchiffrement distant via SSH dans l'initramfs. Pas de clés disque stockées physiquement avec les données.
2^192 combinaisons. La force brute n'est pas l'attaque.
Les IDs de projet sont 24 caractères hex. Les IDs de conteneur sont 24 caractères hex. Une URL valide nécessite les deux. L'espace de clés est 2^192 — à un trillion de tentatives par seconde, l'énumération prend plus de temps que l'âge de l'univers. L'imprévisibilité est une valeur par défaut de départ, pas la seule couche.
Espace de clés des paires
2^192
Pour énumérer à 1T/s
plus long que l'âge de l'univers
Couches supplémentaires disponibles
JWT · Mot de passe · IP · Token
Ouvert par URL est le mode de départ. Verrouillez n'importe quelle URL avec JWT, HTTP Basic, IP CIDR, ou bearer token via /platform/proxy — pas de code d'application requis.
Six couches indépendantes. La défaillance d'une laisse cinq autres.
La sécurité est une pile, pas une porte. Chaque couche est indépendamment efficace ; ensemble elles rendent une défaillance unique survivable.
Imprévisibilité des URLs
Espace de clés 2^192 sur les combos projet+conteneur. L'URL elle-même est le premier secret.
Isolation des conteneurs
Namespaces LXC + micro-VMs Firecracker. Séparation au niveau noyau.
Firewall au niveau hôte
Règles d'ingress + d'égress appliquées au niveau hôte, pas dans le conteneur. Inviolable.
Permissions proxy
Groupes d'auth JWT / Mot de passe / IP / Token superposés au-dessus des URLs.
Ségrégation par realm
Isolation des tenants au niveau API. Tokens scopés à des realms spécifiques.
Chiffrement du disque
AES-256 au repos. Swap chiffré. Démarrage déverrouillé à distance.
Tout est une requête HTTP inspectable.
Pistes d'audit unifiées. Chaque action contre un conteneur est une entrée de log proxy. Tout service peut être MITM'd via hoody-exec ou hoody-curl pour ajouter des vérifications de sécurité IA, des logs ou des limites de débit sans modifier le service.
Logs d'audit unifiés
Les logs proxy couvrent chaque service. Requête, export (NDJSON), agrégation de stats — tout via l'API log /platform/proxy.
MITM par conception
Insérez du middleware entre n'importe quel service et ses clients. Utilisé pour les portes de sécurité IA, la journalisation de conformité, la limitation de débit — aucune modification de service requise.
Fork de plateforme
Chaque utilisateur peut MITM l'API Hoody elle-même pour personnaliser le comportement de la plateforme — sans forker la codebase.
Suspectez une brèche ? Supprimez le conteneur.
Chaque URL de conteneur meurt au moment où le conteneur est supprimé. Pas de propagation DNS. Pas d'invalidation de cache. Pas de tokens périmés à faire tourner. L'URL était la surface ; supprimer le conteneur supprime entièrement la surface.
DELETE /api/v1/containers/ID
Un seul appel API. Authentifié avec votre JWT ou token control-plane.
L'URL arrête de router
Le proxy supprime l'entrée de routage. Le nom d'hôte retourne 404 immédiatement — pas 60 secondes plus tard.
Relancer en quelques minutes
Créez un nouveau conteneur avec un nouvel ID. Nouvelle URL. L'ancienne URL est morte pour toujours. Pas de credentials résiduels à faire tourner.
Densité et isolation ne sont pas des compromis ici.
Bare metal. Noyau durci. Disque chiffré. Défense à six couches. Chaque propriété est déjà vraie sur votre premier conteneur.
Voir aussi — /platform/proxy pour les permissions URL et les groupes d'auth, /platform/control-plane pour la gestion des realms/tokens, /methods/access-network pour firewall + égress.