From .env Files

This is a stub pointing at the full tutorial. The migration walkthrough lives in tutorials because it's hands-on rather than narrative.

Quick orientation#

If you're coming from .env files (12-factor apps, Docker Compose secrets, Heroku config vars, Kubernetes ConfigMap-as-env, GitHub Actions secrets), the structure of your migration is:

1. Inventory. What's actually sensitive vs what's public configuration.
2. Decide a path scheme. environments/<env>/<service>/<credential> works for most setups.
3. Import. Write each sensitive value into ScaiVault under the new path.
4. Adapt service code. Read from ScaiVault with env-var fallback. Keep the fallback around long enough to roll out safely.
5. Roll out staged. Staging first, production with fallback, production without fallback.
6. Remove the env vars. They only exist in ScaiVault now.

The complete walk-through with code examples and the staged-rollout pattern is at Migrate from .env Files.

When this fits#

• Your secrets are currently set by your deployment pipeline (GitHub Actions, Argo, Jenkins, Heroku) and end up as environment variables in the running process.
• Some or all of them should be auditable, rotatable, or accessible to humans without redeployment.
• You don't have an existing secret manager (Vault, ASM) in the way.

If you do have an existing secret manager, see from HashiCorp Vault or from AWS Secrets Manager first — they cover the federation pattern, which is a gentler migration path than direct import.

What's next#

• Migrate from .env Files — the full walkthrough.
• Integration: GitHub Actions — replacing GitHub Secrets with ScaiVault reads at job start.
• Integration: Kubernetes — replacing env-from-secret with ScaiVault init containers.