tptompkins's avatar

Best practices for storing your .env files

There are a lot of people that would advise not to store your .env files in version control where other developers would have access to your sensitive api keys and encryption keys. If you shouldn't store your .env files in version control, what are the best practices for storing them so that you minimize the possibility of accidentally deleting or losing your keys? It seems that it would be ideal to still have some sort of versioning / replication process in place, even if it's not Github or Bitbucket, so that you could always restore your keys in the event of some catastrophic event.

So the question becomes, what is everybody doing to securely store and replicate their .env files and keys? Are you using a password manager to store your keys? Are you storing on encrypted / replicated drives? Something else? What's your process?

Tommy

0 likes
11 replies
jekinney's avatar

I use the env.example file to store the basics and structure. Add to my git. I don't store anything valuable but it's a starting point. Incase I need to update something from a different pc.

shez1983's avatar

good question.. you could store a local copy (backup) somewhere on your pc ie something like sitesenv/site1.env site2,env.. you could even animate this task using gulp so everytime env changes you can do it

on the server, not sure how you would do that..

Roni's avatar

I doubt you'd ever want that on a production machine, but I keep a private git repo for only that. I just add a directory for each project with a readme file for notes and the current .env. After one catastrophic event several years back, I figured I'd never want to go through it again.

You may only use it once a decade, but it will save you a$$ when it's needed.

2 likes
davestewart's avatar

Yeah, main settings in .env.example and everything else in a folder / wiki / password manager somewhere.

jekinney's avatar

@Roni amen!!! Lose those keys you can't get back (some services make you regenerate), forgotten passwords or worse you have to bug a client for them which is a nightmare if they are technically chalanged.

1 like
tptompkins's avatar

I like the idea of having a separate private git repo that only I have access to. But I can also see there being some potential security issues if anyone was to ever gain access to my machine and was able to browse my files.

Does anybody ever worry about Github or Bitbucket employees having access to your private repos and potentially lifting sensitive info?

The more that I think about it, the more I'm starting to lean towards using a password manager such as 1password.com. They claim that even they can not decrypt your data without the master keys which only you have access to. With 1password, I can even create "vaults" to store credentials and share vaults with specific people if I need to share keys with a team.

Roni's avatar

1 password might not be a bad idea, I haven't used it. However, my private git is not on my dev machine. I use gitlab under a second user for that. To put it in perspective, I'm an engineer and I've also done a ton of site visits with a laptop, over the last 10 years I've had one stolen from my desk leaving it for only 5 min! Dropped one (laptop) off the edge of a building, fallen with one down an unfinished flight of stairs. And the had a fresh cup of tea fall over one one with the vibration during some foundation drilling...

Hence, I keep my own instance of gitlab running safe and sound, if you are super paranoid thats a good start. I also use gitlab.com itself as part of our DR plan.

As for the employees of gitlab? I'm not sure. Truthfully, I'm not working for the CIA or anything so I don't know that my files are that interesting. But I feel like I have to trust in professional ethics at some point. How do you feel about Apple, Microsoft, Google, Dropbox or some cloud storage facility somewhere having access to it?

I'm not evangelizing gitlab, but we work on lots of tiny repo's that I feel should be private, and gitlab.com has free unlimited private repo's maybe it might work for you.

HTH -Roni

tptompkins's avatar

Normally, I wouldn't be as concerned with other projects, but the current project I'm working on could potentially have some large consequences if anyone was ever to gain access to certain keys. I went with 1password and I'm really impressed with it so far.

gregrobson's avatar

An option is to email it to yourself! Before you say I'm crazy....

  • I have two factor auth for Gmail
  • I never want to loose access to my email
  • To get to Gmail on my phone requires a fingerprint
  • To get to Gmail on my PC requires a password (Chrome uses Windows built-in encryption for saved passwords)
  • I have the Gmail backup keys for two factor auth stored somewhere safe - I'm not telling you where! :P

If someone gets into my Gmail account, I have far bigger problems!

It works well personally, not sure what would be best for teams?

1 like
404's avatar

Get an Azure DEVOPS account, go to pipelines then library then secure files. Best place to store them

Snapey's avatar

@404 well done member since 8 minutes ago, for resurrecting the oldest post of the day

You can now encrypt your env file. But honestly its never been a problem since I have ONE env file and it lives on the production server

Please or to participate in this conversation.