Migrate Off .env Files in Under Five Minutes

The hardest part of adopting a secrets manager isn't the tool itself — it's the migration. You have .env files scattered across repos, local machines, and deployment platforms. Moving all of those values into a vault feels like a weekend project.

We built two features to make it a five-minute job.

The .env migration wizard

The CLI command secr migrate handles the entire workflow:

# Auto-discover .env files in the current directory
secr migrate

# Or specify a file
secr migrate .env.production

Here's what happens:

1. Discovery — secr finds .env, .env.local, .env.production, and similar files in your project root
2. Parsing — handles quoted values, comments, multiline strings, and values containing = signs
3. Duplicate detection — if a key already exists in your secr project, it flags the conflict and asks whether to skip or overwrite
4. Dry run — add --dry-run to preview what would be imported without writing anything
5. Import — writes all new secrets to your secr project in a single bulk operation

# Preview without importing
secr migrate --dry-run

# Overwrite existing secrets
secr migrate --overwrite

The parser handles the edge cases that trip up naive .env readers: values with = in them (DATABASE_URL=postgres://...), single and double quoted strings, inline comments, and empty values.

Dashboard import

If you prefer a GUI, the environment page now has an Import .env File button. Upload a file, preview the parsed key-value pairs with checkboxes, deselect anything you don't want, and import. The browser-side parser handles the same edge cases as the CLI.

Config export and import

Once your project is set up — environments configured, secrets stored, templates defined — you can export the entire configuration as a portable JSON file:

# Export to stdout
secr config export

# Export to a file
secr config export --output my-project.json

The export includes:

• Project metadata (name, slug)
• Environment definitions
• Secret templates (required key registries)
• Version number for forward compatibility

To replicate the setup in another org or project:

secr config import my-project.json

This creates any missing environments and templates. It doesn't copy secret values — just the structural configuration. This is intentional: secret values shouldn't travel in plaintext JSON files.

The dashboard has matching export/import buttons on the project detail page. Click Export Config to download the JSON, or Import Config to upload one.

Provider import

Already have secrets in another platform? secr can pull them in directly:

# Import from Vercel
secr import --from vercel

# Import from AWS Parameter Store
secr import --from aws-parameter-store --region us-east-1

# Import from Heroku, Render, Railway, Netlify, Supabase,
# GitHub Actions, Cloudflare Pages, DigitalOcean, Fly.io,
# or AWS Secrets Manager
secr import --from <provider>

The import flow is three steps: authenticate with the source provider, preview what will be imported, select the keys you want. The dashboard has a matching multi-step modal with provider-specific form fields.

Some providers (Fly.io, GitHub Secrets) are write-only — secr imports the key names but can't read the values. These are flagged as sensitive placeholders that you'll need to fill in manually.

The migration checklist

Here's the fastest path from .env to secr:

1. secr init in your project root — creates .secr.json
2. secr migrate — imports your .env file
3. Update your app to read from secr instead of dotenv:
   • secr run -- npm start injects secrets as environment variables
   • Or use the SDK: const client = new SecrClient({ token })
4. Delete the .env file and add it to .gitignore
5. secr config export — save your project config for replication

That's it. Your secrets are encrypted, versioned, access-controlled, and no longer sitting in a plaintext file in your repo.