Ir al contenido
TipoDesbloqueadoEtapaProducciónDificultadModeradoTrabajoOptimizar costesParaDevOps e infraServiciosFilesServiciosContainersPor qué HoodyEconomía de contenedoresPor qué HoodyHTTP nativo
TipoDesbloqueadoEtapaProducciónDificultadModeradoTrabajoOptimizar costesParaDevOps e infraServiciosFilesServiciosContainersPor qué HoodyEconomía de contenedoresPor qué HoodyHTTP nativo
TipoDesbloqueadoEtapaProducciónDificultadModeradoTrabajoOptimizar costesParaDevOps e infraServiciosFilesServiciosContainersPor qué HoodyEconomía de contenedoresPor qué HoodyHTTP nativo
TipoDesbloqueadoEtapaProducciónDificultadModeradoTrabajoOptimizar costesParaDevOps e infraServiciosFilesServiciosContainersPor qué HoodyEconomía de contenedoresPor qué HoodyHTTP nativo
Volver a casos de uso
use-cases / ci-cache-without-s3 / hero
FILES · CACHE · COST-OPTIMIZE

La caché de CI que no es una línea en la factura de S3

La mayoría de pipelines de CI queman dinero en tráfico de caché — pushean artefactos a S3, los descargan en el siguiente job, pagan almacenamiento, pagan egress, pagan otra vez cuando los runners cambian de región. En Hoody la caché es una carpeta en el mismo bare metal que ejecuta tu contenedor de build. Pushea un tarball con curl. Descárgalo con curl. Los bytes nunca salen de la máquina.

Leer la API de Files
use-cases / ci-cache-without-s3 / mechanism

Tres curls y un cron

Toda la caché de CI son tres comandos y un job de limpieza. PUT para escribir un tarball. GET para leerlo. find -atime para podar. No hay una cuarta pieza — sin política IAM, sin lifecycle de bucket, sin ceremonia de URL firmada.

WRITE

Comprimir y PUT

Tras la instalación, el runner pasa node_modules por tar | zstd a un único PUT contra /files/cache. Hoody escribe el cuerpo en disco como un único blob binario. Sin multipart, sin part-uploader, sin SDK.

# Tras yarn install, pushea el artefactotar c node_modules | zstd -T0 | curl -T - https://files.containers.hoody.com/cache/$KEY.tar.zst
READ

GET y untar

El primer paso del siguiente job es un solo curl. El cuerpo sale del NVMe a tasa de línea porque la caché vive en la misma máquina física que el runner — sin salto de egress, sin descarga entre AZ, sin edge de CloudFront.

# Siguiente job: descarga y untar en una líneacurl -fsS https://files.containers.hoody.com/cache/$KEY.tar.zst | tar x -I zstd
PRUNE

find -atime · cada noche

Hoody Cron dispara una vez por noche. find /files/cache -atime +30 -delete tira cualquier cosa que ningún job haya leído en un mes. Sin política de retención, sin nivel Glacier, sin JSON de lifecycle que mantener.

# Cron nocturno — cualquier cosa no leída en 30d se vafind /files/cache -atime +30 -delete

PUT escribe. GET lee. find poda. La API de Hoody Files es el servidor de caché, el motor de limpieza y el log de auditoría — todo detrás de la misma URL /files/[path].

use-cases / ci-cache-without-s3 / powers

Tres poderes de la caché-como-carpeta

Empujar la caché a un proveedor aparte tenía sentido cuando el almacenamiento era escaso. En un contenedor bare metal, solo añade un proveedor.

ECONOMÍA

Sin GB-mes, sin egress, sin requests

S3 cobra tres contadores: almacenamiento, egress y por petición. Hoody Files está incluido con el contenedor — el disco que ya pagas es el disco donde se asienta la caché. Los bytes nunca cruzan una frontera de facturación.

LATENCIA

NVMe en lugar de cross-region

Las lecturas salen de la misma máquina física que ejecuta el build. No hay endpoint de S3 que resolver, sin handshake TLS hacia una región, sin rate limit en el throughput por prefijo. Un target de Rust de 1,4 GB se desempaqueta en segundos.

PROPIEDAD

Una relación de proveedor, no dos

Tu runner y tu caché viven en la misma instancia, facturados en la misma factura, depurados con la misma sesión SSH. Cuando apagas el contenedor, la caché es la imagen del disco — vuelve online en cuanto lo arrancas.

use-cases / ci-cache-without-s3 / invoice

Lo que se evapora de la factura

Una huella de CI mediana típica mueve unos 1,4 TB de tráfico de caché al mes. Aquí está la línea que construye en AWS, y la línea que construye en Hoody.

ANTES · FACTURA DE S3este mes, en AWS
  • Almacenamiento · GB-mes$1,0947,2 GB × $0,023
  • Egress · GB de salida$127,801,42 TB × $0,090
  • Peticiones PUT$2,06412k × $5/M
  • Peticiones GET$4,5611,4M × $0,40/M
  • CloudFront / NAT−$57,71descarga cross-AZ
total mensual$78
cinco líneas · cinco tarifas · un bucket
DESPUÉS · HOODY FILESeste mes, en Hoody
  • Disco en el contenedorno extra chargeya pagado en el plan del contenedor
  • Egress entre jobsno extra chargeloopback · se queda en la máquina
  • Peticiones PUT / GETno per-request or per-GB metersin contador por petición
  • Relación de proveedorno extra chargeel runner y la caché son una sola factura
  • 47,2 GB usadosdel planmargen del mismo disco que ejecuta el contenedor
total mensualincluded in server price
un disco · una factura · cero proveedor nuevo

Cuando la caché vive en la máquina que ejecuta el build, el contador que S3 ejecutaba no tiene nada que leer. La línea no se mueve porque no hay transacción que facturar.

use-cases / ci-cache-without-s3 / capacity

Lo que el endpoint de Files garantiza

Hoody Files no es un wrapper fino — es un backend persistente real con hashing, historial, lecturas por rango y un journal de auditoría. La caché de CI usa una rebanada fina de lo que está realmente expuesto.

  1. UNA URL · CUALQUIER ARTEFACTO/files/[path]

    PUT para escribir, GET para leer, HEAD para ETag y Content-Length, ?hash para SHA256, ?stat para metadatos. La caché es la misma familia de endpoints que alimenta logs, builds y artefactos compartidos.

  2. LECTURAS CON VIAJE EN EL TIEMPO?at · ?revision

    Cada escritura pasa por el journal de archivos. Descarga la caché de ayer por timestamp o por número de revisión por path — depurar un flake deja de requerir una herramienta de snapshot aparte.

  3. MONTA CUANDO LO SUPERES60+ backends

    Si la caché de verdad necesita vivir en S3, B2 o una carpeta de Drive, móntala como backend y mantén la misma URL /files/[path]. El código del runner nunca cambia — la caché solo se mueve.

Los números reflejan la superficie publicada de la API de Hoody Files — `GET/PUT/HEAD/PATCH /api/v1/files/[path]`, los parámetros de query `?hash`/`?stat`/`?at`/`?revision`/`?history` y los endpoints del journal de archivos bajo `/api/v1/journal`.

use-cases / ci-cache-without-s3 / punchline

Tu caché de CI deja de ser un proveedor aparte. Es una carpeta en la máquina que ya alquilas.

ayer · cinco tarifashoy · un disco
LO QUE TENÍA LA FACTURA ANTIGUABucket de S3 + egress + peticiones + lifecyclecinco líneas · IAM aparte · proveedor aparte
LO QUE ES AHORAPUT /files/cache/$KEY · GET /files/cache/$KEYdos curls — y la caché es el propio disco del runner
Leer la especificación de Files
use-cases / ci-cache-without-s3 / replaces

A qué reemplaza esto

Los backends de caché estándar a los que sueles recurrir cobran cada uno una relación de proveedor, una factura de egress o una tarifa por build. /files no te cobra nada de eso.

  • Bucket de S3 como cachéAlmacenamiento, egress, peticiones — tres contadores para un tarball que mantienes dos días
  • Caché de GitHub Actions10 GB gratis, luego tarifas por GB y un desalojo a 7 días que no puedes ajustar
  • Caché de BuildJetPrecio por runner para almacenamiento que vive fuera del runner de todos modos
  • Servicios de caché remota BazelUn demonio entero adicional y un protocolo de caché que cuidar
  • Turborepo Remote CachePrecio por build para un tarball que tu monorepo ya producía
  • Caché de Earthly CloudUn backend remoto gestionado para lo que es solo curl + tar
use-cases / ci-cache-without-s3 / cta

Deja de alquilar una caché en una segunda nube. Escribe el tarball en el disco que ya pagas y descárgalo con curl.

Leer la API de Files
use-cases / ci-cache-without-s3 / related

Lee los otros