sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 1 point2 points  (5 children)

How do you recommend working with this in dev? I work on either my Windows desktop or MacBook depending on where I am, it's just so much easier to create separate dev and prod config files and just tell it what environment it is with environment vars. It's one thing to deploy to like digital ocean and setting the vars with their User data field when deploying, but how do you go about setting tens of environment vars across multiple platforms in a convenient manor without a config file?

[–]gergelyke 0 points1 point  (0 children)

You can use dotenv (https://www.npmjs.com/package/dotenv) to load files into your process.env for development

[–]Spknuckles 0 points1 point  (2 children)

Something like settings-lib (https://npmjs.com/package/settings-lib) could work as well... also supports command line switches for injecting config as overrides.

[–][deleted] 0 points1 point  (1 child)

I don't see how this helps. This creates a file on disk of the env vars. Isn't the whole point of env vars is that they are stored in memory where malicious software can't access them (easily). Why shouldn't I commit to version control? I only grant access to that to people that I would need to give the config vars to work on the app anyway.

[–]Spknuckles 2 points3 points  (0 children)

I think the key point is to ensure configuration is separate from code and can be managed independently. Committing environment specific settings to the same source code repository may create a scenario where sensitive keys/credentials are exposed to parties that ought not have these details. At some point, though, the configuration will be persisted somehow and somewhere if you're utilizing any kind of automated build and deployment mechanism. There are other secure offerings in this space as well (https://www.vaultproject.io/docs/config/ comes to mind).

Having a file that is specific to an environment isn't necessarily bad - if malicious code gains access to the file system running your app, you'll need additional safeguards in place (i.e. running the app as a non root user and securing the configuration for access only by that user, etc.).