4 ms·

put it in an .env file and add the .env file to .gitignore?

• mooreds 4y ago
  Yup! And then documenting the .env file keys and values so that other users know where to get the proper values to add to it.
  • joshstrange 4y ago
    Adding a `.env.sample` or similar with dummy values and comments is extremely helpful along side top-level documentation
• muttled 4y ago
  I was thinking the other day that there had to be a better way of storing API keys than just in a file that's not sent to source control but I really can't come up with something that isn't just security by obscurity or basically requires a human to type a credential from memory every time the server is rebooted. Maybe some sort of hardware key or the virtual equivalent in a container?
  • atmosx 4y ago
    You can create abstractions using apps that will access the local keychain (usually password protected) and expose secrets to the local env whole running the app “a-la Doppler, secret hub, etc”. There is aws-vault which follows a similar pattern. Other than that, no way you can go around the fact that the token needs to be exposed at runtime… Another security layer is using temp credentials but still you need the original creds to issue the temp creds…
  • FrenchDevRemote 4y ago
    for a closed source project you can probably do better but for an open source project i don't see a better way to dit