Aller au contenu
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉModéré
MÉTIEROptimiser les coûts
POURDevOps et infra
SERVICESFiles
SERVICESConteneurs
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉModéré
MÉTIEROptimiser les coûts
POURDevOps et infra
SERVICESFiles
SERVICESConteneurs
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉModéré
MÉTIEROptimiser les coûts
POURDevOps et infra
SERVICESFiles
SERVICESConteneurs
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉModéré
MÉTIEROptimiser les coûts
POURDevOps et infra
SERVICESFiles
SERVICESConteneurs
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYHTTP-natif
Retour aux cas d'usage
FILES · CACHE · COST-OPTIMIZE

Le cache CI qui n'est pas une ligne de facture S3

La plupart des pipelines CI gaspillent de l'argent en trafic de cache — envoi des artefacts vers S3, récupération au job suivant, paiement du stockage, paiement du trafic sortant, nouveau paiement quand les runners changent de région. Sur Hoody, le cache est un dossier sur le même serveur bare-metal qui exécute votre conteneur de build. Envoyez une archive tar avec curl. Récupérez-la avec curl. Les octets ne quittent jamais la machine.

Lire l'API Files

Trois curls et un cron

Tout le cache CI tient en trois commandes et un job de nettoyage. PUT pour écrire un tarball. GET pour le lire. find -atime pour purger. Pas de quatrième pièce — pas de policy IAM, pas de lifecycle de bucket, pas de cérémonie d'URL signée.

WRITE

Compresse et PUT

Après l'install, le runner streame node_modules à travers tar | zstd dans un seul PUT vers /files/cache. Hoody écrit le body sur disque comme un blob binaire unique. Pas de multipart, pas de part-uploader, pas de SDK.

# Après yarn install, push l'artefacttar c node_modules | zstd -T0 | curl -T - https://files.containers.hoody.com/cache/$KEY.tar.zst
READ

GET et untar

La première étape du job suivant est un curl. Le body sort du NVMe à pleine vitesse parce que le cache vit sur la même machine physique que le runner — pas de saut d'egress, pas de pull cross-AZ, pas d'edge CloudFront.

# Job suivant : pull et untar en une lignecurl -fsS https://files.containers.hoody.com/cache/$KEY.tar.zst | tar x -I zstd
PRUNE

find -atime · nocturne

Hoody Cron tire une fois par nuit. find /files/cache -atime +30 -delete jette tout ce qu'aucun job n'a lu depuis un mois. Pas de policy de rétention, pas de tier Glacier, pas de JSON lifecycle à maintenir.

# Cron nocturne — tout ce qui n'a pas été lu en 30j disparaîtfind /files/cache -atime +30 -delete

PUT écrit. GET lit. find purge. L'API Hoody Files est le serveur de cache, le moteur de nettoyage et le log d'audit — tout derrière la même URL /files/[path].

Trois pouvoirs du cache-comme-dossier

Pousser le cache vers un fournisseur séparé avait du sens quand le storage était rare. Sur un conteneur bare-metal, ça ajoute juste un fournisseur.

ÉCONOMIE

Pas de GB-mois, pas d'egress, pas de requêtes

S3 facture trois compteurs : storage, egress, par requête. Hoody Files est inclus dans le prix forfaitaire du serveur — le disque que vous louez déjà est le disque où le cache se pose. Les octets ne traversent jamais une frontière de facturation.

LATENCE

NVMe à la place de cross-region

Les lectures sortent de la même machine physique qui fait tourner le build. Aucun endpoint S3 à résoudre, aucun handshake TLS vers une région, aucun rate limit sur le débit par préfixe. Une cible Rust de 1.4 GB se décompresse en quelques secondes.

OWNERSHIP

Une relation fournisseur, pas deux

votre runner et votre cache vivent sur la même instance, facturés sur la même facture, débogués avec la même session SSH. Quand vous éteignez le conteneur, le cache c'est l'image disque — de retour en ligne dès que vous le boot.

Ce qui s'évapore de la facture

Un footprint CI mid-size typique déplace environ 1.4 TB de trafic de cache par mois. Voici la ligne qu'il construit sur AWS ; sur Hoody le cache tourne dans le serveur forfaitaire que vous payez déjà.

AVANT · FACTURE S3ce mois-ci, sur AWS
  • Storage · GB-mois$1.0947.2 GB × $0.023
  • Egress · GB sortant$127.801.42 TB × $0.090
  • Requêtes PUT$2.06412k × $5/M
  • Requêtes GET$4.5611.4M × $0.40/M
  • CloudFront / NAT−$57.71pull cross-AZ
total mensuel$78
cinq lignes · cinq tarifs · un bucket
APRÈS · HOODY FILESce mois-ci, sur Hoody
  • Disque sur le serveurno extra chargecouvert par le prix mensuel forfaitaire du serveur
  • Egress entre jobsno extra chargeloopback · reste sur la box
  • Requêtes PUT / GETno per-request or per-GB meteraucun compteur par requête
  • Relation fournisseurno extra chargele runner et le cache sont une seule facture
  • 47.2 GB utilisésdu planmarge sur le même disque serveur que vous louez déjà
total mensuelincluded in server price
un disque · une facture · zéro nouveau fournisseur

Quand le cache vit sur la box qui fait tourner le build, le compteur que S3 faisait tourner n'a rien à lire. La ligne ne bouge pas parce qu'il n'y a aucune transaction à facturer.

Ce que l'endpoint Files garantit

Hoody Files n'est pas un wrapper léger — c'est un vrai backend persistant avec hashing, historique, range reads et journal d'audit. Le cache CI utilise une fine tranche de ce qui est réellement exposé.

  1. UNE URL · N'IMPORTE QUEL ARTEFACT/files/[path]

    PUT pour écrire, GET pour lire, HEAD pour ETag et Content-Length, ?hash pour SHA256, ?stat pour les métadonnées. Le cache est la même famille d'endpoints qui alimente les logs, les builds et les artefacts partagés.

  2. LECTURES TIME-TRAVEL?at · ?revision

    Chaque écriture passe par le journal de fichiers. Pull le cache d'hier par timestamp ou par numéro de révision par chemin — déboguer un flake n'exige plus un outil de snapshot séparé.

  3. MOUNT QUAND VOUS EN AVEZ BESOIN60+ backends

    Si le cache doit vraiment vivre dans S3, B2 ou un dossier Drive, montez-le comme backend et gardez la même URL /files/[path]. Le code du runner ne change jamais — le cache déménage, c'est tout.

Les chiffres reflètent la surface publique de l'API Hoody Files — `GET/PUT/HEAD/PATCH /api/v1/files/[path]`, les query parameters `?hash`/`?at`/`?revision`/`?history` query parameters and the dedicated `GET /api/v1/files/stat/[path]`, et les endpoints du journal de fichiers sous `/api/v1/journal`.

votre cache CI cesse d'être un fournisseur séparé. C'est un dossier sur la box que vous louez déjà.

hier · cinq tarifsaujourd'hui · un disque
CE QUE L'ANCIENNE FACTURE AVAITbucket S3 + egress + requêtes + lifecyclecinq lignes · IAM séparé · fournisseur séparé
CE QUE C'EST MAINTENANTPUT /files/cache/$KEY · GET /files/cache/$KEYdeux curls — et le cache c'est le disque du runner
Lire la spec Files

Ce que ça remplace

Les backends de cache standard vous facturent chacun une relation fournisseur, une facture d'egress, ou un coût par build. /files ne vous facture rien de tout ça.

  • Bucket AWS S3 comme cacheStorage, egress, requêtes — trois compteurs pour un tarball que vous gardez deux jours
  • Cache GitHub Actions10 GB gratuits, puis frais par GB et éviction à 7 jours non réglable
  • Cache BuildJetPricing par runner pour du storage qui vit hors du runner de toute façon
  • Services de remote cache BazelUn second daemon entier et un protocole de cache à babysitter
  • Turborepo Remote CachePricing par build pour un tarball que votre monorepo a déjà produit
  • Cache Earthly CloudUn backend remote managé pour ce qui n'est que curl + tar

Arrête de louer un cache à un second cloud. Écris le tarball sur le disque que vous payez déjà, et curl-le pour le récupérer.

Lire l'API Files

Lis les autres