Migração do Doppler

A partir da v4.5, o CipherVault tem CLI cv-migrate-doppler que importa projects / configs / secrets do Doppler preservando estrutura semântica.

Mapeamento

Doppler	CipherVault
Project	(label / metadata — não tem equivalente direto)
Config (dev, stg, prd)	Vault com environment correspondente
Secret (key/value)	Secret convencional (não Fortress)
Secret value	secrets.value (cifrado AES-256-GCM)
Service token	AppConnection
Team members	Users (manual import via SCIM ou CSV)

Instalação

# Via Homebrew
brew install ciphervault/tap/cv-migrate-doppler

# Ou baixar binário do GitHub Releases
curl -LO https://github.com/Martinez1991/ciphervault/releases/latest/download/cv-migrate-doppler-linux-amd64
chmod +x cv-migrate-doppler-linux-amd64
sudo mv cv-migrate-doppler-linux-amd64 /usr/local/bin/cv-migrate-doppler

Pré-requisitos

• Doppler API token com permissão de leitura de todos projects (Service Token global ou Admin token)
• CipherVault JWT admin ou AppConnection com vaults:write
• Conta Doppler com a estrutura que você quer migrar

Comando básico

cv-migrate-doppler \
  --doppler-token $DOPPLER_TOKEN \
  --cv-url https://cv.acme.com.br \
  --cv-token $CV_TOKEN \
  --project billing \
  --config prd \
  --dry-run

--dry-run mostra o que seria importado sem aplicar.

Comando completo (todos projects)

cv-migrate-doppler \
  --doppler-token $DOPPLER_TOKEN \
  --cv-url https://cv.acme.com.br \
  --cv-token $CV_TOKEN \
  --all-projects \
  --vault-naming "{{ .Project }}-{{ .Config }}" \
  --path-prefix "imported/" \
  --report report.json

Output

[cv-migrate-doppler] Found 12 Doppler projects, 36 configs, 1247 secrets total
[migrate] billing/prd → vault "billing-prd" (created)
[migrate]   ├── DATABASE_URL → imported/DATABASE_URL  (created)
[migrate]   ├── STRIPE_KEY → imported/STRIPE_KEY  (created)
[migrate]   ├── ...
[migrate] billing/stg → vault "billing-stg" (created)
[migrate]   └── 42 secrets imported
...

✓ Migration complete:
  - 36 vaults created (or already existed)
  - 1247 secrets imported
  - 0 errors
  - report: report.json

Resolução de conflitos

Se um secret já existe no CV no mesmo path:

Flag	Comportamento
--on-conflict=skip (default)	Mantém valor existente, skipa Doppler
--on-conflict=overwrite	Sobrescreve com valor do Doppler
--on-conflict=version	Cria nova versão preservando histórico
--on-conflict=fail	Aborta migração

Cutover gradual

Padrão recomendado:

1. Migrar Dev primeiro com --config dev
2. Apps em Dev atualizam para SDK CV (ou Secretless Proxy)
3. Migrar Staging com --config stg
4. Apps em Staging atualizam
5. Production por último, com janela de manutenção
6. Confirmar 2 semanas de uso do CV antes de revogar Doppler tokens

Tokens Doppler

Após migração, revogue todos os service tokens do Doppler que estavam sendo usados pelas apps. Apps agora devem usar AppConnections do CV.

Limitações

• Doppler Branch Configs — herança suportada via parent_vault_id no CV (configurar manualmente após import)
• Doppler Token rotation — histórico não preservado (CV começa novo histórico)
• Doppler Webhooks — recriar manualmente no CV (Settings → Webhooks)
• Doppler Integrations (AWS Secrets Manager sync, etc.) — recriar via CV cloud integrations
• Secret References ($REF() no Doppler) — resolvidos no momento da migração (valor final é importado, não a referência)

Boas práticas

• Sempre --dry-run primeiro — revise output antes de aplicar
• Migre por projeto, não tudo de uma vez — fica mais fácil reverter se algo der errado
• Backup do Doppler via export CSV antes — opção de recovery
• Documente cutover em runbook — apps que mudaram, datas, validações
• Audit cruzado — compare logs do Doppler (últimos acessos) com audit do CV (primeiros acessos) para detectar apps que esqueceu de migrar

Roadmap

• v5: support para AWS Secrets Manager migration
• v5: support para HashiCorp Vault migration (KV + Transit + Database)
• v5: support para GCP Secret Manager migration