Soixante conteneurs sur un seul serveur
Une seule machine bare-metal fait tourner des dizaines à des centaines de conteneurs Hoody. La déduplication KSM et BTRFS rend le coût marginal quasi nul.
Hoody Cron porte la planification. Hoody Exec porte la logique de renouvellement. Dimanche 04:00 un curl part, certbot tourne, le nouveau bundle est PATCHé dans le proxy, et le reload est confirmé. Aucune session shell, aucune clé dans ~/.ssh, aucun jump host entre vous et le cert.
# weekly · Sunday 04:00 0 4 * * 0 bash /scripts/renew.shhebdo · POSTé une fois · s'auto-exécute pour toujours
aucune clé SSH · aucun jump host · la planification est une ligne dans une API JSON
Toute la pipeline de renouvellement tient en deux endpoints et une planification en 5 champs. Cron déclenche Exec. Exec appelle ACME et PATCH le proxy. La confirmation revient en 200.
POST /users/me/entries avec schedule "0 4 * * 0" et command "curl /scripts/certs/renew". Le service cron l'écrit dans le crontab utilisateur et démarre le tic-tac. vous l'as fait une fois, depuis n'importe où en HTTPS.
Dimanche 04:00, cron curl l'URL exec. Exec démarre le script, parle à l'endpoint ACME de Levous s Encrypt, valide le challenge http-01, et écrit le bundle renouvelé dans /files. Aucun nœud connecté, aucune session requise.
Le script PATCH le nouveau cert et la clé dans l'endpoint bundle du proxy Hoody. Le proxy hot-reload — sans redémarrage — et le prochain handshake TLS sert le nouveau certificat. Tout le cycle dure moins d'une minute.
Chaque étape est un appel HTTP que vous pouvez rejouer depuis un terminal — `curl --dry-run` pour debug, `curl -i` pour voir les headers. La pipeline ne dépend d'aucune session connectée.
À gauche, l'entrée cron qui planifie le job. À droite, le script exec qui fait le travail. Les deux sont adressables en HTTP — les deux sont auditables, les deux sont rejouables depuis n'importe quel laptop ou téléphone.
# register the weekly renewal curl -X POST \ https://cron.containers.hoody.com/users/me/entries \ -H "Content-Type: application/json" \ -d '[ "schedule":"0 4 * * 0", "command":"curl -fsS https://exec.containers.hoody.com/scripts/certs/renew", "comment":"weekly TLS renewal", "enabled":true ]' # response HTTP/1.1 201 Created { "id":"7a92", "schedule":"0 4 * * 0", "enabled":true }
// scripts/certs/renew.ts // @mode serverless // @timeout 120000 const domains = ["your-app.com", "api.your-app.com", ...]; for (const d of domains) { const cert = await acme.order(d); await fetch("/api/v1/proxy/cert/bundle", { method: "PATCH", body: JSON.stringify({ d, cert }) }); } return { "renewed": domains.length };
Deux URL, un dimanche matin, zéro SSH. L'entrée cron est de la donnée — POST-la une fois et elle est là jusqu'à ce que vous la DELETE. Le script exec est un fichier — modifie-le via l'API et le run suivant prend la nouvelle logique. Rien dans cette boucle n'exige qu'une personne soit sur une machine.
Même résultat — un certificat renouvelé chaque semaine — avec trois propriétés que le setup legacy n'a jamais eues.
L'auth est un token URL, pas une clé SSH. Rotate-le via l'API et l'ancien token ne fonctionne plus nulle part d'un coup. Pas d'agent forwarding, pas de bastion, pas de fichier de clé que vous avez oublié d'avoir copié sur une box CI il y a trois ans.
Chaque run est une ligne dans le log cron et une ligne de requête dans le log exec. Grep pour qui a déclenché, quand, quel cert, quel code de réponse. Le 200 du proxy est la preuve que le reload a atterri.
Rejoue le renouvellement depuis votre laptop avec `curl /scripts/certs/renew?dry_run=true`. Regarde la réponse, corrige le script via l'API d'écriture exec, retente. Toute la boucle passe par HTTPS — le même tuyau que la planification de prod utilise.
Chiffres tirés du déploiement, pas des benchmarks. La forme compte : très peu de pièces mobiles, toutes parlent HTTP.
Le setup est un POST. Le renouvellement est un GET planifié. Le debug est un curl. Aucune session shell dans la pipeline à aucun moment — votre clé privée n'a jamais à être sur la box.
Une entrée cron pour planifier le run. Une route exec qui lance le script. La troisième URL — le PATCH du bundle proxy — vit dans le script et recharge le cert.
Expression standard à 5 champs "0 4 * * 0" — dimanche 04:00. Ou `@weekly` si le jour vous êtest égal. Le service cron accepte les deux, plus l'auto-expiration pour les renouvellements one-shot.
Service cron : expressions à 5 champs et macros (`@hourly`, `@daily`, `@weekly`, `@monthly`, `@yearly`), isolation par utilisateur, `expires_at` optionnel. Exec : isolates V8, runtime Bun, magic comments pour mode/timeout/CORS. Le flow ACME est géré dans votre script — Hoody ne lance pas certbot pour vous, il lance votre code à intervalle planifié.
Le renouvellement est un curl planifié — aucune session shell, aucune clé, aucun jump host.
Les façons standard de garder TLS valide en production. Chacune veut soit une session shell, soit un service de control-plane, soit les deux. Le couple cron-plus-exec ne veut ni l'un ni l'autre.
Arrête de te connecter pour renouveler des certs. POST la planification une fois. Regarde le proxy se recharger tout seul chaque dimanche matin.