Go ahead, delete your .env.example file

For every project that we work on and for every configuration change of those projects, we need to do manual work to keep our local environments up to date so they continue to work. Often, this is a struggle. Also, aren’t we all sick of hearing “it works on my machine”?

Why are we creating and maintaining this configuration manually? The reason: our required configuration contains sensitive values that should be kept secret. For this reason, the environment file that’s consumed by our applications is added to the .gitignore file, in order to avoid it being synced to source control.

To date, there is no common practice to collaborate on and share these sensitive values securely and effectively. We’re either sharing the values insecurely (via email and other messaging apps), or adding to the hassle of configuring our environments by doing our own encryption inside source control using tools like GPG (do you also always forget which command to use?). Or, we manually copy sensitive values, for example by pairing with a colleague that already has the sensitive value on their machine.

Why can’t we have a way to collaborate on configuration both effectively and securely? With the launch of 1Password Developer Tools, let’s take a closer peek at an alternative way to collaborate on configuration to remove the hassle – and securely store and synchronize the sensitive values that we should keep secret.

A new way to collaborate on environment configuration

Instead of keeping the environment configuration out of source control, why don’t we just remove the sensitive values, so that we can enjoy all the benefits of collaboration that source control provides us?

This is exactly what 1Password now allows you to do. You store the sensitive values in 1Password and replace those same values in your environment configuration with references to where these values are stored in 1Password. 1Password CLI loads these values from 1Password when and where you need them.

Since the environment configuration no longer contains sensitive data, you can check it into source control, collaborate on it using pull requests and every developer working on the project automatically receives the configuration they need when they check out a version of your source code.

Accelerate onboarding

When new folks join the team or start working on a new project, there’s no longer a requirement to configure a local environment. Their manager can add them to the 1Password user group for the team they just joined, which grants them access to the secrets they need to do their job. Instead of spending their first day struggling to get their environment configured, all the new developer needs to do is clone the repository and they’re good to go.

Let’s go a step further and automate access provisioning through the 1Password CLI so the new team member doesn’t need to be manually added to the user group by the manager. For example, one can grant access automatically when teammates are added to the GitHub project for which they require these secrets.

Remove interruptions from your day-to-day

When environment configuration is managed manually, your development workflow is interrupted when a colleague merges a change that requires configuration. Then, you have to redirect your attention to reproducing the environment of your colleague to fix your build, before you can continue developing another feature, costing the team valuable time.

Using the new workflow enabled by 1Password, you no longer need to manually synchronize your environment to keep up with the state of the code-base. When your teammate makes a change to the codebase that requires a configuration change, they commit the required config change in the environment file together with the code changes. When you pull these new changes, you’re good to go. All the configuration is synchronized through source control and you never have a broken environment anymore. 🚀

The file you’re using to configure the program when you’re developing the feature is the exact same file that you’ll check into source control and share with your colleagues. This ensures that the configuration is reproducible and complete. There’s no longer an additional .env.example or README.md file that you’ll need to separately update (and can forget to do) to inform your colleagues about the necessary changes.

Achieve Dev/Prod parity

To prevent errors occuring in production that weren’t present during development, the dev/prod parity factor of the twelve factor app states you should keep development, staging and production as similar as possible.

For security, secrets should vary between the different environments. As traditional .env files contain the plaintext secrets, they aren’t kept in source control. And to protect the production environment, access to the secret values is typically restricted to a smaller group (e.g. Operations or Sr. Devs). When (other) developers make changes to the application code that require a configuration change, they cannot edit the environment file that specifies the configuration the application requires in production. This friction can lead to missing configuration in production, which causes the application to not work properly, or not work at all in production.

1Password secret references allow to use a single configuration file for all environments. And because the configuration file no longer contains the secrets, all developers working on the application are allowed to access it and can write and review the configuration, without requiring access to the secrets themselves. The operation team uses the same configuration file for production as the developers do during development. They use the specification the developers have created to pass the intended credentials to the application. The configuration file serves as a shared contract between developers and operation engineers.

DB_USER                = op://my-project-$env/database/username
DB_PASSWORD            = op://my-project-$env/database/password
STRIPE_PUBLISHABLE_KEY = op://my-project-$env/stripe/publishable-key
STRIPE_SECRET_KEY      = op://my-project-$env/stripe/secret-key

Developers deserve great ux, too. They run the application with the required secrets with a touch of their fingerprint on their local workstation. In production, the operations team will use 1Password Connect as a back-end to get optimal low-latency and control in their infrastructure.

Improve security

Did you notice that throughout this new workflow the environment file on your system never has the plaintext secrets? The 1Password CLI passes the secrets to just the process running your application, adding to the security of your workflow. The secrets are only kept in memory and never written to disk.

For secrets protecting our development environments, because there was such a hassle synchronizing updates with all devs working on the project, we have come to accept that we (almost) never rotate these secrets.

In too many cases, former teammates can still access these environments. Because this new way of collaborating on the environment configuration removes the manual steps required to synchronize changes, we can now rotate secrets as many times as we’d like without interrupting the developers working with these secrets. Note that this is especially important to do for development workflows that connect to production infrastructure, which tend to be more sensitive. Think for example about configuration for operations and configuration for infrastructure as code projects.

Get started using 1Password environment configuration in your projects today

We’re curious what you think about this new way of collaborating on development environment configuration. How will you be using this? And where should we go with this next? Let us know in the community!

Collaboration on environment configuration is just one of the many improvements we’re creating to make developers’ daily lives easier and more secure. Keep an eye out for more updates and subscribe to our developer newsletter to be notified of new developments.

To upgrade your team’s productivity and security today, get started with environment configuration using 1Password.

Simon Barendse

Tech Lead Terminal Integrations