Secrets no GitHub Actions sem copiar e colar em cada repo.
Os Secrets nativos do GitHub funcionam até você ter dez repos e a mesma DATABASE_URL em cada um. O Envshed traz o padrão de service token: o workflow puxa os secrets em tempo de execução, todo repo lê do mesmo cofre, e rotacionar vira um clique.
Assim que você tem mais de um repo e mais de um ambiente, os repository secrets do GitHub começam a doer. Você atualiza uma chave e esquece quais workflows dependem dela. Organization secrets ajudam, mas só dentro de uma org do GitHub. O Envshed roda um cofre por organização, os workflows do Actions buscam os valores atuais no início do job, e o secret que você acabou de rotacionar já vale no próximo run — sem redeploy, sem clicar na UI de cada repo.
Onde secrets no GitHub Actions começam a sangrar
Uma chave Stripe mora em 12 abas de Secrets
Rotacionar vira 12 PRs ou 12 abas de navegador clicadas em sequência. Na terceira chave, você já parou de conferir duas vezes.
Ambientes viram nomes com prefixo
STAGING_DATABASE_URL e PROD_DATABASE_URL dividem a mesma aba Secrets. Um dia alguém copia o valor de prod no slot de staging, e staging escreve em produção por seis horas.
Mascarar secret no log não é fronteira de segurança
O GitHub mascara valores conhecidos no log, mas screenshot, serviço downstream e artefato cacheado não são protegidos por filtro de log.
Um service token no GitHub. O resto no Envshed
O Envshed emite service tokens escopados para um ambiente. Seu workflow autentica com esse token, puxa os secrets que precisa no início do job, e eles são injetados no processo. O service token mora no GitHub Secrets uma única vez. Todos os outros valores rotacionam no Envshed e se propagam para cada workflow no próximo run.
Um job mínimo do Actions
Um token no GitHub. Todo resto no 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 deployO que muda quando você adota isso
Um token por ambiente
Token de staging não lê produção. Revoga o token no Envshed e todo workflow que usava para de puxar em segundos.
Rotação sem PR
Muda o valor no painel do Envshed. O próximo run pega. Sem mexer no repo, sem redeploy do workflow.
Somente leitura na CI, por padrão
Service token puxa, não escreve. Só operador humano muda valor no Envshed. CI nunca escreve de volta.
O que você ganha
- Service tokens escopados por organização, projeto e ambiente
- envshed run --env production -- <cmd> injeta valores num processo filho, sem arquivo temporário
- Trilha de auditoria mostrando qual token puxou o quê, em qual workflow run, em qual horário
- Token curto via OIDC do GitHub se você preferir não guardar credencial de longa duração
- Plano grátis com 2 usuários e leituras ilimitadas — suficiente pra rodar CI de side project
GitHub Actions, respondido
Isso substitui os Actions Secrets por completo?
Quase. O service token do Envshed continua no GitHub Secrets — esse valor único destrava todo o resto. Dezenas de secrets individuais saem do GitHub e vão pro Envshed, onde você versiona, rotaciona e audita.
E se meu workflow roda em runner self-hosted?
Mesma CLI, mesmo fluxo de token. O runner precisa de saída para api.envshed.com na porta 443 pra puxar os valores.
O envshed run vaza valor no log?
Não. O envshed run injeta os valores só no processo filho. Ele não imprime os valores, e o mascaramento do próprio GitHub continua valendo pro que eventualmente aparecer.
Dá pra usar OIDC do GitHub em vez de token de longa duração?
Dá. Você emite um token curto do Envshed a partir de uma claim OIDC, assim o workflow nunca guarda credencial estática. A doc mostra o formato da claim.
Dê aos seus workflows do Actions um cofre pra ler
Guarda o service token no GitHub Secrets. O resto mora no Envshed.
Começar grátisParte do Envshed.