Aller au contenu
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERAutomatiser une tâche
POURDevOps et infra
POURÉquipes de devs
SERVICESCron
SERVICESExec
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERAutomatiser une tâche
POURDevOps et infra
POURÉquipes de devs
SERVICESCron
SERVICESExec
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERAutomatiser une tâche
POURDevOps et infra
POURÉquipes de devs
SERVICESCron
SERVICESExec
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERAutomatiser une tâche
POURDevOps et infra
POURÉquipes de devs
SERVICESCron
SERVICESExec
POURQUOI HOODYHTTP-natif
CRON · EXEC · SANS SSH

Renouvelle vos certificats TLS sans ouvrir une session SSH

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.

Lire la doc cron

Trois URL, aucun shell

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.

CYCLE DE RENOUVELLEMENTPOSTÉ UNE FOIS · TOURNE CHAQUE SEMAINE
01 · PLANIFIER

POST une seule entrée cron

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.

02 · EXÉCUTER

Exec lance le script

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.

03 · RECHARGER

PATCH le bundle du proxy

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.

À quoi ressemblent les deux endpoints

À 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.

cron · enregistrer la planification
POST · une fois
# 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 }
exec · scripts/certs/renew.ts
GET · tourne chaque semaine
// 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.

Pourquoi ça bat le crontab SSH

Même résultat — un certificat renouvelé chaque semaine — avec trois propriétés que le setup legacy n'a jamais eues.

AUTH · TOKEN URL

Aucune clé privée dans ~/.ssh

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.

AUDIT · TRACE HTTP

Chaque renouvellement est un log de requête

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.

DEBUG · DRY-RUN UN CURL

vous ne faites pas de SSH pour debug

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.

Ce que vous avez zappé

Chiffres tirés du déploiement, pas des benchmarks. La forme compte : très peu de pièces mobiles, toutes parlent HTTP.

  1. SESSIONS SSH0

    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.

  2. ENDPOINTS UTILISÉS2

    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.

  3. CHAMPS · PLANIFICATION CRON5

    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.

avant · le samedi avant l'expiration des certsmaintenant · le cron tourne depuis neuf mois
À QUOI RESSEMBLAIT L'ANCIENNE STACKssh prod && certbot renew && systemctl reload nginxclé dans ~/.ssh · bastion devant · prière pour que la ligne cron ait survécu au dernier reboot
À QUOI ÇA RESSEMBLE MAINTENANT
Lire la doc exec

Ce que ça remplace

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.

  • SSH + certbot manuelUne session shell, une clé, une étape de renew que vous oubliez en vacances
  • ssh-bastion + scriptUn jump host que vous maintenez juste pour lancer un script d'une ligne
  • AWS Certificate Manager (boucle fermée)Gratuit, mais uniquement sur AWS — et le cert ne quitte jamais leur proxy
  • HashiCorp Vault PKIUn daemon de secrets entier pour émettre des certs renouvelés une fois par semaine
  • cert-manager sur KubernetesUn controller, une CRD, un webhook — pour ce qui tient en deux appels HTTP
  • pipeline cron de renouvellement custom + jump hostScripts collés sur un bastion, une clé par runner CI, aucune piste d'audit

Arrête de te connecter pour renouveler des certs. POST la planification une fois. Regarde le proxy se recharger tout seul chaque dimanche matin.

Lire la doc kit

Lis les autres