Managing API Keys Across Dev, Staging, and Production

A typical web application talks to a dozen external services: Stripe for payments, SendGrid for email, AWS for storage, Twilio for SMS, Sentry for error tracking. Each of these has separate API keys for development, staging, and production. Multiply a dozen services by three environments and you are managing 36 secrets — at minimum.

These keys end up in .env files scattered across machines. Your laptop has dev keys. The staging server has staging keys. Production credentials live on the deploy server and maybe in a password manager somewhere. When you set up a new machine, you spend an hour hunting down the right keys for the right environment, copying them from various sources, and hoping you did not accidentally paste the production Stripe key into your development environment.

Using the same key for dev and prod. It seems convenient until your local test suite charges a real credit card, sends a real email to a real customer, or deletes production data. Using the same key across environments eliminates the safety net that separate environments are supposed to provide.

Committing keys to git. Even in a private repository, committed secrets are accessible to everyone with clone access and persist in git history forever. A single git push with a .env file can expose every API key in the project.

Sharing keys in Slack or email. "Hey, can someone send me the staging Stripe key?" is a message that will live in your company's Slack retention logs indefinitely. Those messages are searchable, exportable, and accessible to workspace admins. It is the equivalent of writing your passwords on a whiteboard in a shared office.

ConfigSync introduces environments as a first-class concept. Each environment is an isolated scope for secrets, with its own encryption and access controls. When you push or pull, ConfigSync uses the active environment to determine which secrets to sync.

When you add and push .env files, they are stored under the active environment's scope. Pulling on a machine with a different active environment retrieves that environment's secrets instead.

Now when you pull on any machine, ConfigSync checks the active environment and delivers the correct secrets:

For teams that want an additional layer of security, ConfigSync integrates with external secret providers. Instead of storing encrypted secrets in ConfigSync's cloud vault, secrets can live in your team's existing password manager.

The most secure secret is one that never exists as a file. ConfigSync's inject_as_env mode loads secrets directly into a process's environment without writing a .env file to disk. This eliminates the risk of secrets being included in backups, read by other processes, or accidentally committed.

Here is the full workflow for managing API keys across environments with ConfigSync:

1. Create environments: configsync env create development, staging, production.
2. Add .env files on each environment's machine: configsync add env ~/git/myapp.
3. Push from each environment: configsync push --filter env.
4. On new machines, set the environment and pull: configsync env use development && configsync pull.
5. For maximum security, use configsync inject instead of writing .env files.

No more hunting for keys in Slack threads. No more "which .env file goes with which server?" confusion. No more accidentally using production keys in development. Each environment's secrets are isolated, encrypted, and available exactly where they need to be.