O que é o Infisical
O Infisical é uma plataforma open source de gerenciamento de segredos. Na prática, ele é um cofre central onde você guarda API keys, senhas de banco, tokens e certificados, e de onde a sua aplicação busca esses valores em tempo de execução, sem precisar de um arquivo .env espalhado por cada máquina.
O projeto nasceu em 2022, foi acelerado pela Y Combinator e hoje é mantido pela empresa de mesmo nome. O código fica no GitHub sob licença MIT e o repositório passou de 20 mil estrelas, com uma comunidade ativa que contribui integrações novas com frequência.
Ele resolve um problema que todo time conhece: segredo copiado no Slack, .env commitado sem querer, senha de produção que só uma pessoa sabe. O Infisical coloca tudo isso em um lugar só, com controle de acesso, histórico de versões e sincronização automática para os ambientes onde a aplicação roda.
O interesse cresceu de novo nos últimos meses porque o projeto expandiu para além de segredos: agora também gerência certificados internos (PKI), chaves de criptografia (KMS) e acesso privilegiado a servidores, tudo dentro da mesma interface.
Como funciona
A arquitetura tem três partes. O servidor (backend em Node.js com banco PostgreSQL e Redis) guarda os segredos criptografados. O painel web é onde o time cria projetos, ambientes e permissões. E os clientes (CLI, SDKs, agente, operador de Kubernetes) buscam os segredos e entregam para a aplicação.
Cada projeto tem ambientes separados, como development, staging e production. Dentro de cada ambiente você organiza os segredos em pastas, e cada valor tem histórico: dá para ver quem alterou, quando e voltar para uma versão anterior. Pense nisso como um Git para variáveis de ambiente.
A autenticação das máquinas usa o que eles chamam de machine identities. Em vez de um token estático, a aplicação se identifica com Universal Auth (client id e client secret), ou nativamente com a identidade da nuvem (AWS IAM, GCP, Azure) ou do cluster (Kubernetes service account). O token gerado é curto e renovado automaticamente.
Na hora de usar, a forma mais comum é a CLI: você roda infisical run -- seu-comando e ela injeta os segredos como variáveis de ambiente no processo filho. A aplicação nem sabe que o Infisical existe. Ela só lê process.env ou os.environ como sempre fez.
Principais recursos
O conjunto de funções é bem mais amplo do que um simples cofre de chave e valor. Os principais são:
- Segredos por ambiente e pasta: organização por projeto, ambiente e caminho, com referências entre segredos (um valor pode ser montado a partir de outros).
- Versionamento e rollback: cada alteração vira uma versão, com ponto de restauração e log de auditoria completo.
- Sincronização (Secret Syncs): envia os segredos automaticamente para AWS Parameter Store, AWS Secrets Manager, GitHub Actions, GitLab, Vercel, Cloudflare, Azure Key Vault, entre outros.
- Segredos dinâmicos: gera credenciais temporárias de banco (PostgreSQL, MySQL, Redis, MongoDB, entre outros) e de nuvem que expiram sozinhas.
- Operador Kubernetes: transforma segredos do Infisical em Secrets nativos do cluster e reinicia o deployment quando o valor muda.
- Scanner de segredos: a CLI varre o repositório em busca de chaves vazadas, útil como pre-commit hook.
- PKI e KMS: emissão de certificados internos e criptografia de dados com chaves gerenciadas.
O diferencial em relação ao mercado é juntar a experiência simples (painel bonito, CLI que funciona em segundos) com integrações prontas para o fluxo de DevOps. Ferramentas mais antigas costumam ser poderosas mas exigem muita configuração antes de entregar valor.
Outro ponto forte é o modelo de acesso. Dá para dar permissão por ambiente, por pasta e até por segredo específico, com aprovação de mudança em produção (change requests) para times que precisam disso por compliance.
Como começar: instalação ou acesso passo a passo
Você tem dois caminhos: usar a nuvem oficial em app.infisical.com (plano gratuito generoso para times pequenos) ou hospedar você mesmo. Para testar, a nuvem é o mais rápido. Para produção com dados sensíveis, muita gente prefere self-hosted.
Passo 1: suba o servidor com Docker Compose. O repositório oficial traz um arquivo pronto que inclui PostgreSQL e Redis.
curl -o Docker-compose.prod.yml https://raw.githubusercontent.com/Infisical/infisical/main/Docker-compose.prod.yml
curl -o .env https://raw.githubusercontent.com/Infisical/infisical/main/.env.example
# edite o .env e gere valores novos para ENCRYPTION_KEY e AUTH_SECRET
Docker compose -f Docker-compose.prod.yml up -dPasso 2: acesse http://localhost:80, crie a conta de administrador, uma organização e o primeiro projeto. Cadastre alguns segredos no ambiente development.
Passo 3: instale a CLI na sua máquina. No Linux, macOS e Windows ela está nos gerenciadores de pacote mais comuns.
# macOS
brew install infisical/get-cli/infisical
# Windows
scoop bucket add org https://GitHub.com/Infisical/scoop-infisical.git
scoop install infisical
# Ubuntu / Debian
curl -1sLf 'https://artifacts-cli.infisical.com/setup.deb.sh' | sudo -E bash
sudo apt-get install -y infisicalPasso 4: dentro da pasta do seu projeto, faça login e vincule o diretório ao projeto do Infisical. Isso cria um arquivo .infisical.json que pode ir para o Git sem problema, ele só guarda o id do projeto.
infisical login
infisical initSe o servidor for self-hosted, rode infisical login e escolha a opção de domínio próprio, apontando para a URL da sua instância. Por padrão a CLI conecta na nuvem oficial.
Exemplo prático
Vamos pegar uma API em Node.js que hoje lê DATABASE_URL e STRIPE_KEY de um arquivo .env. O objetivo é apagar o .env da máquina e continuar rodando igual.
Primeiro, cadastre os dois segredos no ambiente development do painel. Depois, no terminal, troque o comando de start por uma chamada via CLI:
# antes
node src/server.js
# depois
infisical run --env=dev -- node src/server.jsPronto. O código continua usando process.env.DATABASE_URL sem nenhuma alteração. Para ver quais variáveis foram injetadas, use infisical secrets na mesma pasta.
Em um servidor de produção, sem usuário logado, a autenticação é feita com uma machine identity. Você cria a identidade no painel, dá permissão de leitura no ambiente prod e exporta as credenciais na máquina:
export INFISICAL_TOKEN=$(infisical login --method=universal-auth \
--client-id=$INFISICAL_CLIENT_ID \
--client-secret=$INFISICAL_CLIENT_SECRET --plain --silent)
infisical run --env=prod --projectId=SEU_PROJECT_ID -- node src/server.jsSe preferir integrar direto no código, os SDKs oficiais cobrem Node.js, Python, Go, Java, .NET, Ruby e Rust. Um exemplo em Python:
pip install infisicalsdkfrom infisical_sdk import InfisicalSDKClient
client = InfisicalSDKClient(host="https://app.infisical.com")
client.auth.universal_auth.login(
client_id="SEU_CLIENT_ID",
client_secret="SEU_CLIENT_SECRET"
)
secret = client.secrets.get_secret_by_name(
secret_name="DATABASE_URL",
project_id="SEU_PROJECT_ID",
environment_slug="prod",
secret_path="/"
)
print(secret.secretValue)Para Docker, use a imagem infisical/cli como base ou instale a CLI no Dockerfile e troque o ENTRYPOINT por infisical run --. Assim a imagem não carrega nenhum segredo embutido.
Comparação com alternativas
O concorrente mais conhecido é o HashiCorp Vault. Ele é mais maduro, extremamente flexível e é o padrão em empresas grandes. Em troca, a curva de aprendizado é íngreme: políticas em HCL, unseal, engines de segredo, tudo exige estudo. Depois da mudança de licença para BSL em 2023, o fork OpenBao surgiu como a alternativa totalmente open source ao Vault.
Os gerenciadores nativos de nuvem (AWS Secrets Manager, Google Secret Manager, Azure Key Vault) funcionam muito bem se você está 100% em um único provedor. O problema aparece em ambientes híbridos, no desenvolvimento local e quando o time quer uma interface amigável para gerenciar valores.
O Doppler é o concorrente mais parecido em experiência de uso, com CLI e sincronizações similares. A diferença é que o Doppler é fechado e só existe como SaaS. Já o SOPS e o git-crypt resolvem um problema menor: criptografar arquivos dentro do repositório, sem servidor central nem controle de acesso por usuário.
Quando usar cada um, em resumo: Vault ou OpenBao para ambientes corporativos com requisitos complexos e time dedicado. Gerenciador da nuvem quando tudo roda em um só provedor. SOPS para projetos pequenos com poucos colaboradores. Infisical quando você quer o meio termo: servidor central, boa interface, open source e pronto para usar em uma tarde.
Pontos positivos e limitações
Entre os pontos positivos, o mais claro é a velocidade para entregar valor. Em menos de uma hora dá para ter o servidor no ar, o time logado e a aplicação rodando sem .env. A documentação é boa e as integrações com Kubernetes, GitHub Actions e Terraform são estáveis.
A licença MIT do core é outro ponto forte, principalmente depois da polémica do Vault. E o plano gratuito da nuvem oficial permite testar sem cartão de crédito, o que ajuda projetos pessoais e MVPs.
Nas limitações, alguns recursos ficam na edição Enterprise: SSO com SAML, alguns tipos de aprovação de mudança, retenção estendida de auditoria e funções avançadas de PKI. O core cobre a maior parte do uso comum, mas vale conferir a tabela de planos antes de adotar em uma empresa grande.
Self-hosted exige cuidar de PostgreSQL, Redis e backups. Se a instância cair, as aplicações que buscam segredo na inicialização não sobem. A CLI tem cache e o agente tem fallback, mas é um ponto único de falha que precisa de atenção e monitoramento.
Guarde a ENCRYPTION_KEY do servidor em um lugar seguro fora do banco. Se perder essa chave, os segredos armazenados no PostgreSQL ficam ilegíveis para sempre. Nem o backup do banco salva.
Casos de uso reais
Dev solo com vários projetos: em vez de um .env por pasta e cópias em duas máquinas, todos os segredos ficam na nuvem gratuita do Infisical. Trocou de notebook, rodou infisical login e está tudo lá.
Startup com 5 a 20 devs: novo membro entra no time, recebe acesso ao ambiente development e nunca vê a senha de produção. Quando alguém sai, o acesso é revogado em um clique, sem precisar rotacionar todas as chaves.
Time de DevOps com Kubernetes: o operador do Infisical cria os Secrets do cluster a partir do painel. Mudou uma chave de API, os pods são reiniciados sozinhos. Nada de kubectl create secret na mão.
Empresa com exigência de compliance: log de auditoria de cada leitura e escrita, aprovação obrigatória para alterar produção e credenciais dinâmicas de banco que expiram em uma hora. Isso simplifica bastante auditorias de segurança.
Dicas e boas práticas
Ative o infisical scan como pre-commit hook. Ele usa regras parecidas com as do gitleaks e barra o commit se encontrar uma chave de API no código. É a forma mais barata de evitar vazamento no Git.
Use referências entre segredos para montar strings compostas. Guarde DB_HOST, DB_USER e DB_PASS separados e crie DATABASE_URL como referência. Rotacionou a senha, a URL atualiza sozinha.
Erro comum de iniciante: usar o token pessoal do infisical login em servidor de produção. Esse token expira e está ligado à sua conta. Em máquina, sempre use machine identity.
Configure o Infisical Agent em servidores tradicionais (sem Kubernetes). Ele renova o token, grava os segredos em um arquivo temporário e pode reiniciar o serviço quando um valor muda.
Separe segredos por pasta dentro do ambiente, por exemplo /api, /worker e /frontend. Depois dê permissão por pasta. Um serviço comprometido só expõe o que ele realmente precisava ler.
Vale a pena?
Sim, para a maioria dos times que ainda vivem de .env e mensagens no chat. O ganho em organização e segurança é imediato, o custo é zero no início e a curva de aprendizado é de horas, não de semanas.
Não vale a pena forçar a troca se a sua empresa já roda Vault com processo maduro, ou se tudo está em um único provedor de nuvem e o gerenciador nativo atende. Nesses casos o Infisical vira uma camada a mais sem ganho claro.
O próximo passo é simples: crie uma conta gratuita ou suba o Docker Compose, instale a CLI e troque o start de um projeto pequeno por infisical run. Se em uma semana você não sentir falta do .env, migre o resto.
Comentários