Llega a producción en minutos
Si staging ya probó y construyó un cambio, producción no debería empezar de cero. hushrun encuentra la evidencia firmada de esos mismos archivos y despliega el artefacto de staging por digest: sin repetir las pruebas ni el build.
Gratis para empezar, con GitHub o Google. En un piloto, lo configuramos contigo en una sesión.
O corre esto en la raíz de tu repositorio:
npx hushrun initEncuentra tus checks, inicia sesión en esta terminal y te muestra cada cambio antes de hacerlo.
sha256:bad90344…28f80e5399f- planfull
- lintcorrió
- unitcorrió
- integrationcorrió
- buildcorrió
- deploycorrió
imagensha256:3cae5d5c…b157
6083e16- planpromote
- lintreutilizado
- unitreutilizado
- integrationreutilizado
- buildcopiado
- deploycorrió
imagensha256:3cae5d5c…b157la de staging, por digest
Lo que ya es cierto hoy
- Corre en producción en
Kobranzapp/back, como ci-promote - CLI gratis, para macOS, Linux y Windows
- Cada evento firmado y verificado por la CLI
- GitHub Actions hoy, GitLab después
Cada despliegue espera un pipeline que ya pasó
Los agentes suben cada cambio a staging y después el mismo cambio a producción. Los archivos son idénticos, pero producción vuelve a esperar el pipeline completo antes de poder desplegar.
sha256:bad90344…28f80e5399f- lintcorrió
- unitcorrió
- integrationcorrió
- buildcorrió
- deploycorrió
imagensha256:3cae5d5c…b157
6083e16- lintotra vez
- unitotra vez
- integrationotra vez
- buildotra vez
- deploycorrió
imagenreconstruida: otro digest
Esperando trabajo terminado
Producción vuelve a correr pruebas que pasaron en staging hace minutos, y reconstruye una imagen que staging ya construyó.
Las colas crecen con los agentes
Entre más suben tus agentes, más espera cada cambio por un runner, y espera dos veces.
Los arreglos también esperan
Un arreglo urgente que ya pasó staging sigue detrás de un pipeline completo de producción.
Construye y valida una vez. Promueve el artefacto exacto.
hushrun es un solo binario estático que corre dentro del CI que ya tienes. Le agrega tres cosas a tus pipelines:
Un digest del contenido
Calcula un hash de los archivos de cada scope desplegable: el source digest, independiente de commits, ramas y del VCS. Un merge commit con los mismos archivos tiene el mismo digest.
acme/api
staging develop 0e5399fsha256:bad90344…28f8producción main 6083e16sha256:bad90344…28f8mismos archivos, mismo digest
Evidencia firmada en un registro append-only
Cada pipeline registra lo que hizo (checks, artefactos construidos, despliegues) como eventos firmados, en un registro append-only que alojamos nosotros.
evidence · acme/api
sha256:bad90344…28f801M63WSKM1…started staging ci 01M63WSKS5…check staging ci 01M63WSKX1…check staging ci 01M63WSM0P…check staging ci 01M63WSM60…artifact staging ci 01M63WSMB5…deployed staging ci 01M63WSMMM…passed staging ci Un plan antes de trabajar
Antes de correr nada, cada etapa le pregunta al planner qué falta para este digest. Si staging ya lo validó, producción copia el artefacto de staging por digest y lo despliega.
producción · push a main $ hushrun plan --stage production default promote: every requirement of `production` is met: deploying image us-docker.pkg.dev/acme-staging/api/server@sha256:3cae5d5c…b157 by digest image: us-docker.pkg.dev/acme-staging/api/server@sha256:3cae5d5c…b157 requirement lint satisfied requirement unit satisfied requirement integration satisfied
Salida real de hushrun planen un repositorio de demostración. Los digests van abreviados; pasa el cursor para ver el valor completo.
En la demo, develop en 0e5399f y main en 6083e16 son commits distintos con los mismos archivos, así que los dos tienen el source digest sha256:bad90344…28f8.
Seis modos de plan, y nada en medio
Cada plan termina en un solo modo. Elige uno para ver lo que imprimió hushrun plan en el repositorio de demostración.
$ hushrun plan --stage production default promote: every requirement of `production` is met: deploying image us-docker.pkg.dev/acme-staging/api/server@sha256:3cae5d5c…b157 by digest image: us-docker.pkg.dev/acme-staging/api/server@sha256:3cae5d5c…b157 requirement lint satisfied requirement unit satisfied requirement integration satisfied
hushrun plan: production
| Scope | Mode | Reason |
|---|---|---|
| default | promote | every requirement of production is met: deploying image us-docker.pkg.dev/acme-staging/api/server@sha256:3cae5d5c…b157 by digest |
$ hushrun plan --stage production default refresh: the artifacts are reusable: deploying image us-docker.pkg.dev/acme-staging/api/server@sha256:3cae5d5c…b157 by digest; running integration (expired) first checks to run: integration image: us-docker.pkg.dev/acme-staging/api/server@sha256:3cae5d5c…b157 requirement lint satisfied requirement unit satisfied requirement integration expired
hushrun plan: production
| Scope | Mode | Reason |
|---|---|---|
| default | refresh | the artifacts are reusable: deploying image us-docker.pkg.dev/acme-staging/api/server@sha256:3cae5d5c…b157 by digest; running integration (expired) first |
$ hushrun plan --stage staging default full: no reusable `image` (none was recorded): building and running lint (missing), unit (missing), integration (missing) checks to run: lint unit integration requirement lint missing requirement unit missing requirement integration missing
hushrun plan: staging
| Scope | Mode | Reason |
|---|---|---|
| default | full | no reusable image (none was recorded): building and running lint (missing), unit (missing), integration (missing) |
$ hushrun plan --stage production default wait: `staging` is still running sha256:bad90344f9e5 in github run 201 attempt 1 (https://github.com/acme/api/actions/runs/201/attempts/1); its completion triggers a new plan here requirement lint missing requirement unit missing requirement integration missing
hushrun plan: production
| Scope | Mode | Reason |
|---|---|---|
| default | wait | staging is still running sha256:bad90344f9e5 in github run 201 attempt 1 (https://github.com/acme/api/actions/runs/201/attempts/1); its completion triggers a new plan here |
$ hushrun plan --stage production default skip: `production` already runs sha256:bad90344f9e5 (deployed at 2026-10-29T13:15:17.142Z); re-run, or run manually, to deploy it again requirement lint satisfied requirement unit satisfied requirement integration satisfied
hushrun plan: production
| Scope | Mode | Reason |
|---|---|---|
| default | skip | production already runs sha256:bad90344f9e5 (deployed at 2026-10-29T13:15:17.142Z); re-run, or run manually, to deploy it again |
$ hushrun plan --stage production default blocked: `staging` failed sha256:bad90344f9e5 in github run 201 attempt 1 (https://github.com/acme/api/actions/runs/201/attempts/1); fix forward, or force requirement lint satisfied requirement unit failed requirement integration missing
hushrun plan: production
| Scope | Mode | Reason |
|---|---|---|
| default | blocked | staging failed sha256:bad90344f9e5 in github run 201 attempt 1 (https://github.com/acme/api/actions/runs/201/attempts/1); fix forward, or force |
Ya corre en producción, en nuestro propio CI
hushrun generaliza ci-promote, una herramienta en bash que hace lo mismo para un repositorio de GitHub. ci-promote corre en producción en Kobranzapp/back, el backend de nuestra propia empresa, Kobranzapp.
Desde junio, cada commit a main en Kobranzapp/back tuvo archivos que staging ya había probado y construido. Sus corridas de producción se saltan las pruebas y el build, y copian la imagen exacta de staging.
Es un solo equipo, y es el nuestro. Los pilotos son la forma de saber si el tuyo se ve igual.
version: 1 repository: github.com/acme/api checks: lint: { kind: source, run: pnpm lint } unit: { kind: source, run: pnpm test, timeout: 20m } integration: { kind: source, run: pnpm test:integration, timeout: 30m } artifacts: image: type: oci locations: staging: us-docker.pkg.dev/acme-staging/api/server production: us-docker.pkg.dev/acme-prod/api/server stages: staging: branch: develop require: [lint, unit, integration] production: branch: main after: staging require: [lint, unit, integration]
hushrun.yaml completo de un setup con dos etapas. La CLI lo valida.- id: plan run: hushrun plan --stage production --start # later jobs carry the plan out instead of deciding again deploy: if: contains(fromJSON('["promote","refresh","full"]'), needs.plan.outputs.mode)
Minutos más baratos. Muchas más corridas.
El precio del minuto de CI bajó este año. La cantidad de minutos, no.
- −39%
GitHub bajó hasta 39% el precio de sus runners alojados el 1 de enero de 2026.
- +130%
Tian Pan describe una línea de CI que subió 130% en seis semanas cuando los agentes de código empezaron a correr CI en cada iteración.
- 1 jun
Desde el 1 de junio de 2026, el code review de Copilot consume minutos de GitHub Actions en repositorios privados.
Los agentes no solo escriben más código: también corren más CI. hushrun hace que cada corrida cuente una sola vez.
Nada se salta sin evidencia firmada
hushrun decide con evidencia que puede verificar, y si no puede, falla de forma segura.
Eventos firmados
Cada resultado de check, artefacto y despliegue es un sobre DSSE firmado. En GitHub Actions, CI firma como el workflow del propio repositorio, sin claves que guardar; un laptop con sesión iniciada firma con la clave que registró al iniciar sesión.
Verificados en cada lectura
La membresía es la política: un evento cuenta cuando lo firmó la máquina de un miembro con sesión iniciada, uno de los agentes de tu organización o el CI del propio repositorio. Si quitas a alguien, lo que firme desde entonces deja de contar. En el dashboard, una etapa puede aceptar evidencia solo del CI. Un evento que la CLI no puede verificar cuenta como faltante.
Falla de forma segura
Si la evidencia falta, venció o falló, se corren los checks (
refresh) o la etapa construye (full). Las aprobaciones nunca se omiten, y siempre puedes forzar una corrida completa.Append-only, en formatos estándar
El registro deja que CI agregue eventos, pero nunca que los reescriba o los borre, y registra cada escritura. Sus checkpoints son notas firmadas, el formato de la base de datos de checksums de Go: el paquete
notede Go las verifica. Sus pruebas siguen el RFC 6962. El servicio alojado dice quiénes son tus miembros; la decisión de desplegar siempre es de la CLI, en tu CI.
$ hushrun verify --scope default --digest sha256:bad90344…28f8 ok v1/events/default/bad90344f9e5f7d8a3f4a46a99b40eede644f97d1dc93de3ce59c7cbb9ee28f8/01M63WSKM1RC1PA3Y6HHBTFNFC.started.staging.json: started at staging signed by ci (custody ci) for sha256:bad90344…28f8, with identity https://github.com/acme/api/.github/workflows/deploy-staging.yml@refs/heads/develop, timestamped at 2026-10-29T13:15:08.802Z ok v1/events/default/bad90344f9e5f7d8a3f4a46a99b40eede644f97d1dc93de3ce59c7cbb9ee28f8/01M63WSKS5VZAK8574WJTKDWS8.check.staging.json: check at staging signed by ci (custody ci) for sha256:bad90344…28f8, with identity https://github.com/acme/api/.github/workflows/deploy-staging.yml@refs/heads/develop, timestamped at 2026-10-29T13:15:08.966Z ok v1/events/default/bad90344f9e5f7d8a3f4a46a99b40eede644f97d1dc93de3ce59c7cbb9ee28f8/01M63WSKX146X9HF9E43DHN0WK.check.staging.json: check at staging signed by ci (custody ci) for sha256:bad90344…28f8, with identity https://github.com/acme/api/.github/workflows/deploy-staging.yml@refs/heads/develop, timestamped at 2026-10-29T13:15:09.089Z ok v1/events/default/bad90344f9e5f7d8a3f4a46a99b40eede644f97d1dc93de3ce59c7cbb9ee28f8/01M63WSM0PNGDC8NSK7J079SWY.check.staging.json: check at staging signed by ci (custody ci) for sha256:bad90344…28f8, with identity https://github.com/acme/api/.github/workflows/deploy-staging.yml@refs/heads/develop, timestamped at 2026-10-29T13:15:09.206Z ok v1/events/default/bad90344f9e5f7d8a3f4a46a99b40eede644f97d1dc93de3ce59c7cbb9ee28f8/01M63WSM60NR3SEF83MRHGNN0H.artifact.staging.json: artifact at staging signed by ci (custody ci) for sha256:bad90344…28f8, with identity https://github.com/acme/api/.github/workflows/deploy-staging.yml@refs/heads/develop, timestamped at 2026-10-29T13:15:09.377Z ok v1/events/default/bad90344f9e5f7d8a3f4a46a99b40eede644f97d1dc93de3ce59c7cbb9ee28f8/01M63WSMB5412BRQPQC8HX8GR3.deployed.staging.json: deployed at staging signed by ci (custody ci) for sha256:bad90344…28f8, with identity https://github.com/acme/api/.github/workflows/deploy-staging.yml@refs/heads/develop, timestamped at 2026-10-29T13:15:09.542Z ok v1/events/default/bad90344f9e5f7d8a3f4a46a99b40eede644f97d1dc93de3ce59c7cbb9ee28f8/01M63WSMMMD5NS6JX3DZJMT0AJ.passed.staging.json: passed at staging signed by ci (custody ci) for sha256:bad90344…28f8, with identity https://github.com/acme/api/.github/workflows/deploy-staging.yml@refs/heads/develop, timestamped at 2026-10-29T13:15:09.845Z
hushrun verify sobre la corrida de producción de la demo: quién firmó qué, y para qué digest.Encaja en el CI que ya tienes
- CI
- GitHub Actions
- Una action de instalación
- Workflows listos
- Resúmenes de pasos y anotaciones
- GitLab CI, después
- Evidencia
- Alojado, por HTTPS
- GitHub OIDC para CI
- Tokens para cualquier otro CI
- Un registro de transparencia de cada escritura
- Artefactos
- Imágenes OCI, por digest
- Índices multiplataforma
- Archivos
- Código
- Cualquier lenguaje
- Cualquier VCS
- Cualquier directorio
- Un solo binario estático
Un solo requisito: un build que pueda correr en todos los ambientes, con los valores de cada ambiente entregados al desplegar en vez de quedar dentro del build.
La CLI es gratis. El plan para equipos tiene costo.
CLI
Gratis
Todo lo que decide un despliegue, en tu CI.
- Source digests para cualquier lenguaje y cualquier VCS
- Eventos firmados, verificados en cada lectura
- El planner y sus seis modos
- Imágenes OCI promovidas por digest
- Las decisiones se toman en tu CI, nunca en nuestros servidores
Plan para equipos
Gratis para empezar
Lo que un equipo comparte alrededor de la CLI. Nunca toma una decisión de despliegue.
- Un registro alojado, con tokens y GitHub OIDC para CI
- Un dashboard con cada etapa, digest y despliegue
- Un registro de auditoría de quién firmó qué, verificado con el mismo código de la CLI
Los precios están en la página de precios: gratis hasta 2,000 checks registrados al mes. Los equipos piloto tienen precio fundador, y la CLI sigue siendo gratis.
Lo primero que preguntan los equipos
hushrun se salta un check solo cuando tiene evidencia válida para exactamente los mismos archivos: un resultado exitoso, firmado por la máquina de un miembro o por el CI de tu repositorio (o solo por CI, en una etapa configurada así en el dashboard), y más reciente que el
max_agedel check. Un repositorio también puede hacer que CI reutilice solo resultados de CI. Los checks de despliegue, como las pruebas de humo contra producción, se siguen corriendo después de desplegar. Las aprobaciones nunca se omiten, y siempre puedes forzar una corrida completa.Promover mueve un mismo artefacto por todos los ambientes, así que encaja con builds que leen su configuración al desplegar o al correr: variables de entorno, secretos, archivos de configuración. Si tu build incluye valores de cada ambiente, producción construye su propio artefacto (modo
full) y aun así reutiliza la evidencia de checks que tu política acepta. Los pilotos empiezan revisando esto juntos.La CLI es gratis. El plan alojado para equipos (un registro de evidencia compartido, políticas, un registro de auditoría y un dashboard) es gratis hasta 2,000 checks registrados al mes; Team cuesta US$49 al mes y Growth US$99, y saltarse un check siempre es gratis. La página de precios tiene el resto. Los equipos piloto tienen precio fundador, y los pilotos son gratis mientras duran.
Los cachés como Nx, Turborepo o Bazel reutilizan resultados de tareas, y los filtros por ruta se saltan jobs según los archivos que cambiaron; producción igual termina con un artefacto propio. hushrun despliega el artefacto que staging validó, identificado por digest, con un registro firmado de los checks que pasó. Funciona junto con tus cachés.
Eventos: digests, nombres y resultados de checks, referencias de artefactos y enlaces a las corridas. No ve tu código fuente ni tus secretos. Y la CLI funciona sin él.
Si hay agentes de código que suben a tus repositorios y tu CI cuesta US$300 o más al mes, Camilo, quien construye hushrun, te va a invitar a una llamada de 30 minutos y, si encaja, a un piloto gratis de cuatro semanas en un repositorio, configurado juntos. Si no, te escribimos cuando un piloto encaje con tu equipo. En cualquier caso, puedes empezar gratis hoy.
hushrun se salta un check solo cuando tiene evidencia válida para exactamente los mismos archivos: un resultado exitoso, firmado por la máquina de un miembro o por el CI de tu repositorio (o solo por CI, en una etapa configurada así en el dashboard), y más reciente que el max_age del check. Un repositorio también puede hacer que CI reutilice solo resultados de CI. Los checks de despliegue, como las pruebas de humo contra producción, se siguen corriendo después de desplegar. Las aprobaciones nunca se omiten, y siempre puedes forzar una corrida completa.
Pruébalo en un repositorio
Crea tu cuenta con GitHub o Google y corre un solo comando en la raíz de tu repositorio.
O configúralo con nosotros
También trabajamos con pocos equipos piloto, en un repositorio cada uno.
Configuración juntos, en una sesión. Gratis durante un piloto de cuatro semanas. Después, precio fundador.