TYPEDébloqué

ÉTAPEFlotte

DIFFICULTÉModéré

MÉTIERPartager un flux

POURÉquipes de devs

POURDevOps et infra

SERVICESPipe

POURQUOI HOODYHTTP-natif

POURQUOI HOODYÉconomie des conteneurs

TYPEDébloqué

ÉTAPEFlotte

DIFFICULTÉModéré

MÉTIERPartager un flux

POURÉquipes de devs

POURDevOps et infra

SERVICESPipe

POURQUOI HOODYHTTP-natif

POURQUOI HOODYÉconomie des conteneurs

TYPEDébloqué

ÉTAPEFlotte

DIFFICULTÉModéré

MÉTIERPartager un flux

POURÉquipes de devs

POURDevOps et infra

SERVICESPipe

POURQUOI HOODYHTTP-natif

POURQUOI HOODYÉconomie des conteneurs

TYPEDébloqué

ÉTAPEFlotte

DIFFICULTÉModéré

MÉTIERPartager un flux

POURÉquipes de devs

POURDevOps et infra

SERVICESPipe

POURQUOI HOODYHTTP-natif

POURQUOI HOODYÉconomie des conteneurs

Retour aux cas d'usage

use-cases / push-one-build-to-thirty-ci-workers / hero

PIPE · FAN-OUT CI

Push un build vers trente workers CI d'un coup

votre CI matrix fan-out sur trente test runners. Chacun a besoin de la même image de 800 MB. Stream le tarball dans un chemin pipe avec ?n=30. Les trente workers curl la même URL. Les octets passent une fois, le serveur ne tient rien, et aucun credential de registry n'est rotaté.

Lire la doc pipe

builder.ci

1 envoyeur

# stream l'image une foistar c ./image.tar | curl -T - https://pipe.hoody.com/build-12af?n=30

PUT /pipe1× egress

?n=30un stream

ci-fleet

30 récepteurs

tous connectés

GET /pipe

UN ENVOYEUR À GAUCHE. TRENTE RÉCEPTEURS GET À DROITE. LE PIPE ATTEND QUE TOUT LE MONDE ÉCOUTE, PUIS LES OCTETS PASSENT UNE FOIS.

use-cases / push-one-build-to-thirty-ci-workers / mechanism

Comment trente curls deviennent un stream

Le pipe est un routeur fan-out sans disque. Le POST de l'envoyeur sur /api/v1/pipe/[path]?n=30 bloque jusqu'à ce que trente récepteurs se connectent à la même URL avec le même n. Puis les octets coulent du conteneur build directement à travers chaque runner, simultanément, à la vitesse du récepteur le plus lent.

Trois étapes. Pas de registry, pas de S3, pas de cache action.PIPE · ?n=30

Le build stream une fois

tar c | curl -T - https://pipe/.../build?n=30

Le conteneur build pipe le tarball direct dans curl. Pas de fichier écrit, pas de registry pushé.

Le pipe attend la flotte

POST /api/v1/pipe/[path]?n=30

Le serveur tient l'envoyeur jusqu'à ce que les trente récepteurs se connectent. Un n incohérent renvoie 400. Les récepteurs pré-connectés sont OK.

Les trente pull la même URL

curl https://pipe/.../build?n=30 | tar x

Chaque runner reçoit des octets identiques. La backpressure flue depuis le récepteur le plus lent, pas depuis la bande passante de l'envoyeur.

Rien ne persiste. Rien n'est mis en cache. Le pipe brokere la connexion, puis se met de côté. Quand le runner le plus lent finit, le transfert finit — et l'URL disparaît.

use-cases / push-one-build-to-thirty-ci-workers / numbers

Ce que ça coûte à la matrix

Naïf : trente pulls registry du même tarball de 800 MB, trente caches froids, trente aller-retour réseau. Pipe : un egress, un transfert, le récepteur le plus lent donne le rythme.

TEMPS WALL

12s

Un egress à pleine vitesse. Le récepteur le plus lent donne le rythme, mais personne ne re-télécharge.

EGRESS

1× / build

Les octets quittent le builder une fois, fan-out au pipe. Pas de frais GET S3, pas de pulls Docker Hub.

STORAGE

0 octet

Le pipe ne tient rien sur disque. Pas de registry à nettoyer, pas de clé de cache à invalider.

Le chiffre du temps wall suppose une matrix de 30 sur le même réseau régional que le conteneur build ; les transferts cross-region sont limités par la bande passante inter-région, pas par le pipe.

use-cases / push-one-build-to-thirty-ci-workers / powers

Ce que le fan-out débloque

Une fois que le build est une URL et trente curls, une pile de scaffolding CI disparaît. Pas de stockage d'artefacts à faire vieillir. Pas de credentials de registry à rotater. Pas de cache action à debugger.

Le récepteur le plus lent donne le rythme

La backpressure est intégrée au pipe. Les workers rapides ne perdent pas un aller-retour registry à attendre le lent — ils attendent au pipe, puis boivent au même rythme. Personne ne re-télécharge.

Pas de credentials de registry à rotater

Rien n'est pushé vers un registry, donc rien n'a besoin de s'authentifier. L'URL elle-même est le credential — courte durée, scoped à un transfert, évincée quand le build finit.

Pas de facture S3, pas de surprise egress

Les octets quittent le builder une fois. Le pipe diffuse. vous payez un egress par build au lieu de trente pulls registry par run de matrix.

Pas de clé de cache à invalider

Le pipe est par-build, pas par-clé. Pas de cache GitHub Actions à mal-hit, pas de mystère de couches buildx, pas de tarball obsolète de la main de la semaine dernière.

Marche pour n'importe quel tarball, pas que les images

Le même pattern gère node_modules, .pnpm-store, target/, le cache des wheels, le shard de dataset. Si ça stream, ça fan-out.

use-cases / push-one-build-to-thirty-ci-workers / punchline

Un envoyeur. Trente récepteurs. Zéro facture S3.

Un push 30 voies qui auparavant s'étranglait sur un aller-retour S3 circule maintenant par un seul tube et une seule sortie. Personne n'est obligé de re-télécharger. Aucune rotation de credentials de registry. L'URL s'efface d'elle-même à la fin de la matrice.

1 EGRESS
30 RÉCEPTEURS
0 STORAGE
0 CREDENTIALS

Ouvrir l'API pipe

use-cases / push-one-build-to-thirty-ci-workers / replaces

Ce que ça remplace

Les pièces qu'un flux matrix-CI doit normalement assembler — registry, cache action, miroir, étape d'upload maison. Le pipe les plie en une URL.

AWS S3 (stockage registry + egress)30× frais GET par build, politique d'éviction, rôle IAM
GitHub Actions cachePlafond 10 GB, collisions de clés, scope par branche
Pulls Docker HubLimité en taux, miroir payant pour éviter le throttling
miroir registry npm / pnpmVerdaccio self-hosted juste pour sauter le registry public
Cache action CI maisonGlue bash, SDK S3, logique d'expiration, d'astreinte quand ça casse
Export de cache de couches BuildxQuirks de format de couche, cache miss cross-runner

use-cases / push-one-build-to-thirty-ci-workers / cta

Arrêtez de pusher le même tarball trente fois. Pushez-le une fois. Laissez trente curls partager le stream.

Lire l'API pipe

use-cases / push-one-build-to-thirty-ci-workers / related

Lis les autres

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.

Conteneurs·Snapshots

Onboarder un développeur avec un seul lien

Un nouvel ingé arrive lundi. vous envoyez une URL. Il l'ouvre depuis le laptop qu'il a sous la main et il est dans un conteneur neuf cloné depuis votre snapshot developer-baseline — code, deps, env, données seed, VSCode dans le navigateur. Il code en cinq minutes, pas en config.

Snapshots·Conteneurs·Terminal·Files

Des endpoints API qui se matérialisent à la demande

Un script exec wildcard intercepte l'appel, demande à un LLM d'écrire le handler, l'exécute dans un sandbox V8 et sauvegarde la route. L'appel suivant est natif.

Exec·Agent·Code·Files

Brancher des ordinateurs comme avec Git

Snapshot un conteneur en cours d'exécution — fichiers, processus, mémoire. Restaurez en quelques secondes. Forkez via /copy. Du branching, mais pour la machine entière.

Snapshots·Conteneurs

Du vrai VS Code sur votre téléphone

Le Code Orchestrator lance une instance VS Code sur le conteneur et sert l'éditeur via une URL HTTPS classique. N'importe quel appareil avec un navigateur peut l'ouvrir. Le travail vit dans le conteneur, pas sur l'appareil.

Display·Terminal·Files·Conteneurs+1

Des agents IA qui lancent d'autres agents IA

Un agent de recherche poste sur /api/v1/projects/$PID/containers pour démarrer un conteneur enfant, puis appelle l'URL agent de l'enfant comme n'importe quel autre service HTTP. Les sous-agents lancent leurs propres sous-agents de la même manière. Pas de framework d'orchestration, juste des URLs.

Agent·Exec·Conteneurs

Un sandbox par client, automatiquement

Un script exec intercepte votre webhook d'inscription, copie un conteneur fresh-customer et remet au nouveau tenant son URL dédiée. L'isolation, c'est l'OS, pas une colonne tenant_id.

Conteneurs·Snapshots·Exec·Files

Vous réveiller avec un prototype terminé

Donnez un paragraphe à l'agent à minuit. Il lance ses propres conteneurs, snapshot avant les étapes risquées et poste sur votre webhook de notifications au lever du jour.

Agent·Snapshots·Conteneurs·Browser+2

Un fix prod en urgence depuis votre téléphone

PagerDuty vous réveille. Ouvrez l'URL terminal sur votre téléphone. PATCH le snapshot d'avant le mauvais déploiement. La prod est de retour. Pas de bastion, pas de VPN, pas de laptop.

Terminal·Snapshots·Réseau

Streamer les logs prod vers une URL que tout le monde peut curl

Une seule URL pipe. Jusqu'à 256 lecteurs. Trois ingés tail le même incident en même temps, sans bastion, sans siège Datadog, sans log forwarder.

Pipe

Regarder votre agent réfléchir depuis le café

votre agent tourne à la maison. vous êtes au café. Stream chaque événement de la boucle dans Hoody Pipe et curl le même chemin depuis votre téléphone — la trace arrive caractère par caractère. Pas de SSH, pas de dashboard, pas d'upload.

Pipe·Agent

Déplacer 200 Go entre clouds avec deux curls

pg_dump | gzip | curl depuis Francfort. curl | gunzip | psql à Singapour. Les octets passent par le pipe sans toucher disque au milieu.

Pipe

Envoyer un état de base à un coéquipier en une ligne

pg_dump streame directement dans son psql. Aucun fichier uploadé, aucun lien partagé, aucun téléchargement. Le pipe achemine les octets.

Pipe

Streamer des tokens LLM vers tout ce qui lit du HTTP

L'étape 3 streame les tokens avec curl -T -. L'étape 4 curl le même chemin. Les tokens vont du générateur au consommateur à pleine vitesse. Pas de plomberie SSE, pas de broker.

Pipe·Agent

Une barre de progression que votre boss peut regarder sans se connecter

Ajoutez ?progress à l'URL pipe. Quiconque l'ouvre voit un dashboard HTML live — octets, vitesse, ETA, état. Jusqu'à cinquante spectateurs, aucun n'occupe un slot de récepteur, aucun ne touche au stream.

Pipe

Le fanout de webhooks que vous n'avez pas eu à coder

Stripe POST sur une URL pipe avec ?n=12. Douze abonnés curl l'URL réceptrice avec ?n=12. Le pipe garde l'événement jusqu'à ce que tout le monde soit connecté.

Pipe·Exec

Un cache CI qui n'est que deux commandes curl

tar | zstd | curl met node_modules dans un pipe. Vingt jobs en aval font curl | zstd -d | tar x. Pas de bucket S3, pas d'action de cache, pas de facture d'egress.

Pipe·Conteneurs

Glisser-déposer des uploads dans votre script

hoody-pipe sert un formulaire d'upload web sur chaque chemin. Glissez un fichier sur la page, votre script lit les octets depuis stdin. Zéro code d'upload, pas de bucket S3, pas d'URL pré-signée.

Pipe·Exec

Diffuser un atelier à 200 spectateurs depuis votre laptop

ffmpeg streame votre écran vers une URL pipe avec ?n=200. Chaque participant curl l'URL dans un onglet de navigateur. Pas de plateforme, pas de logins, pas d'upload.

Pipe

IPC inter-conteneur sans message broker

Le conteneur A écrit sur une URL pipe. Le conteneur B lit depuis le même chemin. La backpressure, c'est la connexion. Pas de Redis, pas de file, pas de broker.

Pipe·Conteneurs

Suivre votre agent dans le train, recevoir un ping à l'arrivée

L'agent streame sa trace vers une URL pipe que vous pouvez curl depuis votre téléphone. Quand il termine, son dernier acte tape hoody-notifications et votre téléphone vibre. Deux URLs et un buzz — pas de SDK, pas d'app cliente, pas de dashboard.

Pipe·Agent·Notifications

Un micro sur HTTP, dans deux terminaux

ffmpeg capture le micro, pipe vers une URL. L'autre bout curl et joue l'audio. Pas de Zoom, pas de SDK, pas de serveur de signaling.

Pipe

Cinq agents, cinq pipes, un verdict

Un panel de cinq modèles examine la même entrée. Chacun tourne dans son propre conteneur et streame son verdict vers son propre chemin pipe. Un processus juge curl les cinq en parallèle et compile le résultat.

Pipe·Agent·Conteneurs

Rejouer l'incident de ce matin pour toute l'équipe

Snapshot les logs de l'incident dans hoody-files. Rejoue-les via une URL Hoody Pipe avec ?n=8. Huit ingés curl le même chemin et regardent la cascade se déclencher en synchro — le post-mortem est un stream synchronisé, pas un doc Confluence.

Pipe·Files

Le « envoie-moi ce fichier » le plus rapide que vous ayez tapé

Un coéquipier demande un dump de 4 Go. Slack le rejette, Drive demande un partage. vous tapez curl -T file …; il tape curl … > file. Les octets vont de disque à disque — pas de barre d'upload, pas de lien à partager.

Pipe

Faire tourner un LLM local et le servir à toute votre flotte

Un GPU fait tourner llama.cpp. Ses tokens streament vers une URL pipe avec ?n=50. Cinquante conteneurs curl la même URL et se partagent le stream.

Pipe·Daemon

Un dashboard de métriques live sans backend de métriques

La boucle de monitoring de chaque conteneur curl une métrique vers une URL pipe. Le dashboard curl la même URL avec ?progress et rend le stream SSE.

Pipe

Le job cron qui se supprime quand vous avez fini

POST une entrée cron managée avec expires_at à 48 heures. Le job tourne aux heures prévues, puis se retire — pas de rappel, pas de PR de cleanup, pas d'entrée orpheline.

Cron

Snapshot le conteneur juste avant la migration nocturne

Une entrée hoody-cron qui se déclenche à 02h55 UTC, curl l'URL snapshots et nomme l'artefact pre-migration-2026-05-04. Cinq minutes plus tard, la migration tourne. Si elle réussit, le snapshot reste là et coûte zéro. Si elle échoue, vous restaurez en 30 secondes avec un seul PATCH.

Cron·Snapshots

Une crontab séparée pour chaque client, automatiquement

Chaque tenant a son propre conteneur et son propre service hoody-cron. Le digest 9h du client A part à l'heure même quand le job du client B reste bloqué 40 minutes, parce qu'ils ne sont pas sur la même crontab.

Cron·Conteneurs

Réveille un agent à 3h, retire-le à 4h

Un cron nocturne POST une demande de spawn, l'agent fait son heure de boulot, puis un second cron démolit le container. L'agent n'existe que quand il y a du travail.

Cron·Agent·Conteneurs

Des rollups quotidiens sans orchestrateur

Les événements bruts s'accumulent dans une URL sqlite. Chaque nuit, une entrée cron curl un endpoint exec, le script fait tourner le SQL de rollup et réécrit la table quotidienne. Pas de DAG, pas de Postgres Airflow, pas de dashboard de scheduler.

Cron·SQLite·Exec

Une crontab par branche, déployée avec le code

votre repo commit `.hoody/crontab`. Le script de déploiement PUT ce fichier vers l'API Cron du nouveau container. Chaque branche a son conteneur, son filesystem, son planning.

Cron·Conteneurs

Une escalade on-call qui expire avec le shift

POST une entrée cron avec expires_at = fin du shift. Quand le shift se termine, l'entrée se supprime. Le prochain on-call poste la sienne.

Cron·Notifications

Scrape horaire, digest quotidien, archive hebdomadaire — un seul conteneur

Trois lignes dans un seul crontab : scrape navigateur horaire vers SQLite, digest exec quotidien, archive hebdomadaire vers les fichiers. Serveur à tarif fixe, trois rythmes, aucun service de planification.

Cron·Browser·SQLite·Files

Laissez vos clients amener leur propre cron

Les clients POST leurs propres expressions à 5 champs ; leur crontab vit dans leur conteneur, isolée. vous ne validez pas contre une queue globale.

Cron·Conteneurs

Planifie l'agent, pas le script

Une entrée cron à 5 champs curl hoody-agent avec un prompt au lieu de faire tourner un script figé. C'est le dernier jour du mois — l'agent s'en rend compte. Le format des données a changé — l'agent s'en rend compte.

Cron·Agent

Un heartbeat pour les jobs silencieux

Chaque exécution cron POST un heartbeat sur un endpoint notifications. Un second cron vérifie le dernier heartbeat et alerte sur le silence. Le silence, c'est l'alerte.

Cron·Notifications

Gardez les 24 dernières heures sous forme de 24 snapshots

Un cron horaire POST un snapshot nommé avec l'heure. Au bout de 24 heures, chaque nouveau snapshot écrase celui d'hier à la même heure. La machine à remonter le temps sur 24 paliers.

Cron·Snapshots

Rejouer les webhooks de ce matin demain à la même heure

vous avez capturé 30 minutes de vrai trafic Stripe dans un dossier hoody-files. Une entrée cron le rejoue contre staging à 9h tous les jours ouvrés — même volume, même payload, même pression à la même heure.

Cron·Files·Exec

Éditer votre crontab depuis un téléphone, à l'aéroport

Ouvrez l'URL cron sur votre téléphone à la porte d'embarquement. Tapez une ligne, modifiez un seul champ de l'expression cron, appuyez sur Save. Le PATCH atterrit. Le job se déclenche ce soir avec le nouveau planning. Pas de session SSH, pas de jump box, pas de laptop.

Cron·Terminal

Un digest planifié qui se diffuse à 200 boîtes mail

Cron à 9h POST sur un script exec qui construit le digest et curl une URL pipe avec ?n=200. Deux cents destinataires tapent la même URL une fois.

Cron·Exec·Pipe

Couper le son d'un job instable sans le perdre

PATCH /entries/[id] [ enabled: false ]. Le job reste dans votre crontab à attendre d'être réparé. Pas de suppression, pas de réécriture, pas de contexte perdu.

Cron

Un agent qui note les agents d'hier

Un cron nocturne POST sur l'agent superviseur avec les traces d'agents d'hier depuis SQLite. Le superviseur note chacun. Cron est le superviseur.

Cron·Agent·SQLite

Des jobs de cleanup qui planifient leur propre retraite

Le script de cleanup vérifie s'il reste quelque chose à nettoyer. Quand le dossier est vide, il DELETE sa propre entrée cron. Job fini, job parti.

Cron·Files

Renouveler vos certificats TLS sans session SSH

Cron hebdo : POST sur un script exec qui fait tourner certbot, poste le nouveau cert au proxy via PATCH. Pas de session shell, pas de clé, pas de jump host.

Cron·Exec

Un canari hebdo qui essaie de casser la prod

Cron dimanche 7h réveille un Hoody Agent dans un conteneur neuf contre un snapshot de prod. Il fait tourner l'OWASP top vingt, fuzze l'API et écrit un rapport de findings vers une URL avant 9h. Conteneur retiré.

Cron·Agent·Browser·Snapshots

Le cimetière de side-projects que vous pouvez vous permettre de garder vivant

Onze side-projects à moitié finis sur Heroku, c'est onze dynos à 5–7 $ chacun. Sur Hoody, c'est onze conteneurs sur une seule machine bare-metal à 29 $. L'idle coûte zéro, l'URL réveille le conteneur en quelques millisecondes, et le moteur d'échecs que personne n'utilise tourne quand même.

Conteneurs

Un environnement de preview par pull request, tout le mois

Chaque PR ouverte a son propre clone d'un snapshot. Le conteneur se réveille quand un reviewer clique sur le lien ; les PR idle ne coûtent rien.

Conteneurs·Snapshots

Faire tourner un portfolio de 12 produits depuis une seule machine bare-metal

Douze conteneurs isolés, chacun son SaaS, partagent un seul serveur bare-metal à 49 $ — un cran au-dessus du tier d'entrée à 29 $, choisi ici pour la marge RAM que veulent cinquante conteneurs. Les marges par produit passent du négatif au confortable.

Conteneurs

Tuer la taxe du serveur de staging

Arrêtez de payer un duplicata de la prod. Snapshot le conteneur prod, branchez le staging à la demande, regelez-le sur disque quand personne ne teste. Trois environnements, une machine, une facture.

Conteneurs·Snapshots

Remplacer la facture E2B par le bare-metal que vous louez déjà

vos agents arrêtent de louer du compute à la seconde chez E2B/Modal/Daytona. Ils utilisent des conteneurs sur la machine que vous avez déjà.

Conteneurs·Agent·Exec

Le staging idle ne coûte rien, donc on arrête de le supprimer

Le staging mourait parce qu'il coûtait cher à garder. Quand l'idle est gratuit, le staging a le droit de vivre — même celui qu'un coéquipier a touché il y a 90 jours.

Conteneurs·Snapshots

Des sandboxes par client à l'échelle d'une flotte

Huit cents clients isolés sur trois serveurs bare-metal — une seule facture mensuelle à tarif fixe, pas de compteur par tenant. Chaque tenant a un vrai conteneur avec son propre namespace kernel, son filesystem et son URL. Les conteneurs idle ne coûtent rien en plus du serveur que vous payez déjà.

Conteneurs·Snapshots·Exec

Le cache CI qui n'est pas une ligne S3

Les fichiers de cache vivent dans /files sur la machine que vous louez déjà. Les workers PUT et GET les tarballs sur HTTP. Pas de bucket S3, pas d'egress, pas de troisième vendor — les octets ne quittent jamais la machine.

Files·Conteneurs

Cinquante environnements de démo pour cinquante appels commerciaux

Chaque prospect a une copie réelle et isolée de votre produit, seedée avec ses données. Cloné depuis un snapshot. À lui de garder pendant une semaine.

Conteneurs·Snapshots

Push un build vers trente workers CI d'un coup

Comment trente curls deviennent un stream

Le build stream une fois

Le pipe attend la flotte

Les trente pull la même URL

Ce que ça coûte à la matrix

Ce que le fan-out débloque

Le récepteur le plus lent donne le rythme

Pas de credentials de registry à rotater

Pas de facture S3, pas de surprise egress

Pas de clé de cache à invalider

Marche pour n'importe quel tarball, pas que les images

Ce que ça remplace

Lis les autres

Soixante conteneurs sur un seul serveur

Onboarder un développeur avec un seul lien

Des endpoints API qui se matérialisent à la demande

Brancher des ordinateurs comme avec Git

Du vrai VS Code sur votre téléphone

Des agents IA qui lancent d'autres agents IA

Un sandbox par client, automatiquement

Vous réveiller avec un prototype terminé

Un fix prod en urgence depuis votre téléphone

Streamer les logs prod vers une URL que tout le monde peut curl

Regarder votre agent réfléchir depuis le café

Partager votre écran avec une URL, pas une invitation à une réunion

Déplacer 200 Go entre clouds avec deux curls

Envoyer un état de base à un coéquipier en une ligne

Streamer des tokens LLM vers tout ce qui lit du HTTP

Une barre de progression que votre boss peut regarder sans se connecter

Le fanout de webhooks que vous n'avez pas eu à coder

Un cache CI qui n'est que deux commandes curl

Glisser-déposer des uploads dans votre script

Diffuser un atelier à 200 spectateurs depuis votre laptop

IPC inter-conteneur sans message broker

Suivre votre agent dans le train, recevoir un ping à l'arrivée

Un micro sur HTTP, dans deux terminaux

Cinq agents, cinq pipes, un verdict

Rejouer l'incident de ce matin pour toute l'équipe

Le « envoie-moi ce fichier » le plus rapide que vous ayez tapé

Faire tourner un LLM local et le servir à toute votre flotte

Un dashboard de métriques live sans backend de métriques

Le job cron qui se supprime quand vous avez fini

Snapshot le conteneur juste avant la migration nocturne

Une crontab séparée pour chaque client, automatiquement

Réveille un agent à 3h, retire-le à 4h

Des rollups quotidiens sans orchestrateur

Une crontab par branche, déployée avec le code

Une escalade on-call qui expire avec le shift

Scrape horaire, digest quotidien, archive hebdomadaire — un seul conteneur

Laissez vos clients amener leur propre cron

Planifie l'agent, pas le script

Un heartbeat pour les jobs silencieux

Gardez les 24 dernières heures sous forme de 24 snapshots

Rejouer les webhooks de ce matin demain à la même heure

Éditer votre crontab depuis un téléphone, à l'aéroport

Un digest planifié qui se diffuse à 200 boîtes mail

Couper le son d'un job instable sans le perdre

Un agent qui note les agents d'hier

Des jobs de cleanup qui planifient leur propre retraite

Renouveler vos certificats TLS sans session SSH

Un canari hebdo qui essaie de casser la prod

Le cimetière de side-projects que vous pouvez vous permettre de garder vivant

Un environnement de preview par pull request, tout le mois

Faire tourner un portfolio de 12 produits depuis une seule machine bare-metal

Tuer la taxe du serveur de staging

Remplacer la facture E2B par le bare-metal que vous louez déjà

Le staging idle ne coûte rien, donc on arrête de le supprimer

Des sandboxes par client à l'échelle d'une flotte

Le cache CI qui n'est pas une ligne S3

Cinquante environnements de démo pour cinquante appels commerciaux