Un vault, cada workflow

Secrets de GitHub Actions, sin copiar y pegar en cada repo.

Los Secrets nativos de GitHub están bien hasta que tienes diez repos y el mismo DATABASE_URL en cada uno. Envshed trae el patrón de service token: tu workflow trae los secrets actuales en tiempo de ejecución, cada repo lee del mismo vault, y rotar es un clic.

En cuanto tienes más de un repo y más de un entorno, los repository secrets de GitHub empiezan a doler. Actualizas una clave y olvidas qué workflows la necesitan. Los secrets a nivel de organización ayudan, pero solo dentro de una misma org de GitHub. Envshed corre un vault por organización, tus workflows de Actions traen los valores actuales al inicio del job, y el secret que acabas de rotar ya está vigente en el siguiente run — sin redeploys, sin clics por repo.

Dónde los secrets de GitHub Actions empiezan a sangrar

Una clave de Stripe vive en 12 pestañas Secrets

Rotarla son 12 PRs, o 12 pestañas de navegador clickeadas en secuencia. Para la tercera clave, dejaste de verificar dos veces.

Los entornos colapsan en nombres con prefijo

STAGING_DATABASE_URL y PROD_DATABASE_URL comparten la misma pestaña Secrets. Un día alguien copia el valor de prod al espacio de staging, y staging escribe en producción por seis horas.

El enmascarado de logs no es una frontera de seguridad

GitHub enmascara valores conocidos en logs, pero los screenshots, servicios downstream y artefactos cacheados no están protegidos por un filtro de log.

Un service token en GitHub. Todo lo demás en Envshed

Envshed emite service tokens con alcance a un solo entorno. Tu workflow autentica con ese token, trae los secrets que necesita al inicio del job y los inyecta en el proceso. El service token vive en GitHub Secrets una sola vez. Todos los demás valores rotan en Envshed y se propagan a cada workflow en el siguiente run.

Un job mínimo de Actions

Un token en GitHub. Todo lo demás en Envshed.

# .github/workflows/deploy.yml
- name: Install Envshed CLI
  run: npm install -g envshed
- name: Deploy with production secrets
  env:
    ENVSHED_TOKEN: ${{ secrets.ENVSHED_PRODUCTION_TOKEN }}
  run: envshed run --env production -- pnpm deploy

Qué cambia cuando lo adoptas

Un token por entorno

Un token de staging no puede leer producción. Revocas el token en Envshed y cada workflow que lo usa deja de traer valores en segundos.

Rotación sin PRs

Cambias un valor en el panel de Envshed. El siguiente run lo toma. Sin cambios en el repo, sin redeploys del archivo de workflow.

Solo lectura por defecto en CI

Los service tokens pueden traer, no empujar. Solo operadores humanos cambian valores en Envshed. La CI nunca escribe de vuelta.

Lo que obtienes

  • Service tokens con alcance por organización, proyecto y entorno
  • envshed run --env production -- <cmd> inyecta valores a un proceso hijo, sin archivos temporales
  • Registro de auditoría que muestra qué token trajo qué, desde qué run, a qué hora
  • Tokens de corta vida vía OIDC de GitHub si prefieres no guardar credenciales de larga duración
  • Plan gratis con 2 usuarios y lecturas ilimitadas — suficiente para correr la CI de un proyecto personal

GitHub Actions, respondido

¿Esto reemplaza los Actions Secrets por completo?

Casi. Sigues guardando el service token de Envshed en GitHub Secrets — ese valor único destraba todo lo demás. Las decenas de secrets individuales salen de GitHub y entran a Envshed, donde los versionas, rotas y auditas.

¿Y si mi workflow corre en self-hosted runners?

El mismo CLI, el mismo flujo de token. El runner necesita acceso de red saliente a api.envshed.com en el puerto 443 para traer los valores.

¿envshed run filtra valores en los logs?

No. envshed run inyecta los valores solo en el proceso hijo. No los imprime, y el enmascarado de GitHub sigue funcionando en cualquier valor que llegue a aparecer.

¿Puedo usar OIDC de GitHub en vez de un token de larga duración?

Sí. Puedes emitir un token de corta vida de Envshed desde un claim OIDC, así el workflow nunca guarda una credencial estática. Mira la documentación para el formato exacto del claim.

Dale a tus workflows de Actions un vault del que leer

Guarda el service token en GitHub Secrets. Todo lo demás vive en Envshed.

Empezar gratis

Parte de Envshed.