Ask HN: How do you share and sync .env files and secrets with your team

We use Doppler and it seems pretty decent

I've mostly used the 1Password CLI. A simple `op inject .env.template > .env` (off the top of my head) and done!

We use Fernet[1] or Ansible vault[2] with the encrypted secrets committed to the code repositories, but I guess we can do that because the code is not public.

The rest we share over a secure, company approved, channel, and save them into local KeePass-es (KeePassXC)

[1] https://docs.ansible.com/ansible/latest/vault_guide/index.ht...

[2] https://cryptography.io/en/latest/fernet/

It depends on how big a team you are and where you need things to work. If vault seems like too much, I'm guessing you're a smaller team, at which point, a password manager with a command line interface is what you're looking for. There are heavier weight options, but then you're in hashicorp vault territory again.

I built Rot to solve this. It creates a git diff-able list of keyrings and secrets that you can inject via environment variables to sub commands, like `rot run mykeyring terraform apply`. You can use Shamir Secret Sharing to create "disaster recovery" access into the keyrings too.

https://rotx.dev

We use Infisical for both our dev and prod environments. If you're a YC company you can get your first year free.

https://infisical.com

Store the encrypted env file (ejson is good) in your project and have a shared 1Password key to decrypt them.

Secrets committed and encrypted with sops. You can decrypt it locally with a key shared in 1Password

Around 100 lines of shell scripting and an encrypted S3 bucket that has a shared secrets .env file which is ignored from version control for each project.

IAM handles access control and the shell script makes it easy for folks to show, diff, download and upload secrets for a project.

When a secret gets changed it also sends a Slack notification so folks know to download the latest copy.

It costs practically nothing, is super easy to maintain and it keeps your app only needing to deal with environment variables.

Years ago, before going full on Vault, I was using git-crypt, a git plugin that uses gpg to encrypt files before committing them to the repo.

Not sure if it’s still fine, I see their last release is 2 years old nowadays.

https://github.com/AGWA/git-crypt

We use 1password with op (1password cli) to sync secrets on dev

We use Doppler and it’s been great.

Ignoring the point about managing secrets for a moment, and just speaking about "sharing/syncing .env files" —

I would like to suggest that anyone that cares about this, first gets onto using direnv(1) — and getting their collaborators on projects to do the same — rather than relying on the `.env`-file support included in Python / Docker Compose / etc.

Why? Because of a specific function that direnv(1) injects into its script execution environment, called source_env_if_exists().

You can use this function to separate your env-var config into two "layers": a project-global env, and a user-specific local-worktree env. The global layer can just call source_env_if_exists at the end, pointing at the local layer.

(In my own projects, I usually name this local overlay env-file `.envrc.local`)

With this approach, rather that creating an `.envrc.template` and telling each dev that they need to copy it into place, you can instead create and commit the `.envrc` file itself, holding any public/static base configs; tell your devs to override and add env in `.envrc.local`; and add `.envrc.local` to your project's `.gitignore`, so that nobody will accidentally commit their env overrides.

This also has an interesting impact: direnv(1) normally de-authorizes the sourcing of the `.envrc` file whenever its content-hash changes — which is annoying when you're constantly tweaking local env-vars. But (perhaps surprisingly), direnv(1) does not recursively hash the script files depended on through source_env_if_exists() for purposes of calculating the overall authorization hash of the toplevel script — so changing `.envrc.local` in this setup, doesn't result in having to type `direnv allow`.

As another bonus, with the `.envrc.template` approach, as soon as you copy `.envrc.template` to `.envrc`, this base config is now no longer "managed" by the project, and so can age/break. Whereas, a repo base `.envrc` can be updated by the project maintainers, and the resulting derived env will change along with it! (But, of course, making any change to the project base `.envrc` will result in each developer needing to re-authorize the `.envrc` file with `direnv allow` — which is the correct security model, as you don't want maintainers of public projects being able to attack users who've `direnv allow`ed the `.envrc` of their repo, by silently changing the content of that `.envrc`.)

And as an interesting extension to this, you can add code after source_env_if_exists(). So you can:

• validate the env-var values the developer set in `.envrc.local`

• require that certain env-vars be set in `.envrc.local` — where a value not being set results in the `.envrc` script printing an error message and exiting. The dev will see this as soon as they `direnv allow` in the dir, and the message can guide them to configuring the env-vars. (You can even do this conditionally, where e.g. a connstring env-var must be set for a provider if-and-only-if that provider is enabled.)

• allow env-vars to be specified in various different styles, together as URLs or separately as host/username/password/etc, and then canonicalize / synthesize the env-vars your project actually wants, filling in the parts of a computed var the dev didn't specify with default values

• you can require the `.envrc.local` file export an ENVRC_ABI_VERSION var, and compare that to a constant burned into the `.envrc` file, and error on mismatch. Then, if the project's base `.envrc` gets updated in a way where it now looks for different env-vars than before, you can just bump the constant in `.envrc`. When devs re-authorize the new `.envrc` version, rather than just being confused why everything is now broken, the `direnv allow` command will error out, pointing the dev to a URL on the project wiki, where there's `.envrc.local` version-migration guidance (which tells them whatever semantic changes they need to make, a...

Secrets manager, but the secrets are JSON objects. Each secret contains all the secrets for a specific "environment". Then we use scripts in the repo to download the secrets and set up the env.

We use the same pattern in production and CI/CD

SOPS is pretty great. On year ~6 of using it across two companies and no complaints to speak of.

We use Doppler. It’s pretty good.

Why does the team need to share secrets? What's the problem that needs to be solved here? We don't need to share any secrets.

I used dotenv-vault at my last job (paid customers) and it worked well. I think that service has been replaced by dotenvx but I haven’t tried that.

You could securely exchange .env files using public key cryptography with a tool such as GPG. Broadly, you'd 1) generate a key-pair, 2) export and share the key to your co-worker, 3) import your co-worker's public key 4) encrypt your file 5) send the encrypted file via email or any channel to your co-worker 6) decrypt!

You can revoke access to that person by changing your .env file credentials and deleting your co-worker's key.

Since nobody else asked. If your team isn't infra/acting as infra then you don't.

Least required access, set up a dev environment with CI/CD and if they need to do any local dev(frontend contacting your API etc) then implement auth you are in control of.

If your team needs to make actual API calls to external services for dev, change that, you codebase is likely not testable. Integration tests should run on CI.

Much of this is likely a few days work if your codebase isn't massive and if your codebase is massive then put that in the next sprint.

We use Vercel and have configured a way to pull the dev environment keys from there. This is of course a very tech stack-specific solution.

I'm currently using direnv + 1password + https://github.com/tmatilai/direnv-1password. `direnv` to load shell environment dynamically upon entering a directory. It can load static .env files, but can also source shell scripts to load envvars.

1password is the company password manager. It has shared 'vaults' where a team can share secrets with one another. They can thus be used for authorization, who can access which secrets.

direnv-1password is a plugin for direnv that will load secrets from 1password into envvars. With this, upon entering a project, you'll be asked to unlock 1password (using yubi or fingerprint scan) and it'll fetch the needed secrets from the project.

This way secrets secrets are not easily readable from your disk, like they would with .env files.

Other password managers likely have similar tooling for direnv. Though I don't know whether it'll be this convenient.

At a former workplace I wrote this tool which was put to use.

It utilizes GPG to store the secrets and Golang templates to support the files.

https://github.com/jyap808/jaeger

I use `ess` (env sample sync) to sync my `.env` with `env.sample`: https://github.com/acaloiaro/ess.

This of course does not share the secrets themselves, but helps document what secrets an application requires.