Whenever it comes to securing the API keys or something that we don't want to be exposed to the public for our Open Source Project, we always tend towards the .env file, and every week, 29k+ developers download a trendy package, dotenv.
Why is the filename only .env?
It's a myth, that the filename can only start with .env. You can name it anything and it will still be working fine with node.js.
For example, this is my folder structure to test this feature, and as you can see, instead of .env, I added my name as a filename.
This file contains a PORT, which I want to print in my main file
And, as you can see, the PORT is being printed in the console. 
Why we should be using dot( . ), in front of the environment file ?
When it comes to environment files, it's considered good to use a dot ( . ), in front of the filename, because adding a dot in front of any file name, makes it a hidden file or folder.
That's why there are multiple folders in your OS, that are hidden and can only be accessed via CLI, For example, .ssh, .github, .vscode, etc.
How to access the environment file without using dotenv?
Instead of using dotenv to read environment files, you can use the node.js inbuilt method to read them, which is
node --env-file=.env app.js
Here, instead of using .env as a file name, you can use any file name that is in your root folder.
Top comments (48)
Nice work so far and thanks for sharing but however your article did not : (1) state the problem as the title suggest . (2) security measures (3) Alternative and best adoptable practice . What you demonstrate is just changinge file name . Keep up the good work we look forward to get more details from you so we all can benefit.
No, the demonstration is that the
dotenvmiddleware package is wholly unnecessary and that Node.js itself implements the desired functionality without having to download and install additional third-party middleware.Pay attention.
ok thanks for the clarification.
I like the honest critique.
Feel free to take a look at my latest article and let me know what you think.
dev.to/dansasser/supercharge-your-...
.env file is never committed to the repo, thus not exposing your secrets. As far as using variables in prod, it doesn't really matter, you could inject .env file into the container at build time/ssh into the virtual machine and define it if you are solo, you just have to be careful that there is no way that the file could ever leak.
I never understood why not including a
.envto the repo. For me a.envis a source for a sane default setup. Of course I would agree not to commit any secrets. And if you want to work with local settings you would copy.envto.env.localand set your custom settings there. Or in prod you would have.env.prod(which of course you won't commit either).Am I doing things wrong?
I can agree on _ not committing secrets_ but that is different from _not commiting
.env.You can start with .env.default and set up your variables there, and commit that to source control. Then make a copy of it with your local values and name it .env, and add that file to .gitignore. The default file acts as a template for the external environment values, and the values are still private. Win win!
I use
.env.example,.env.development.example, etc. and add those to the repo, with sane defaults in them, or comments on how to get the right variables. This prevents accidental commits.AFAICS this introduces one extra step: copy
.env.exampleto.env. As.env.exampleis not loaded by default?Take a look at npmjs.com/package/envalid.
It's a great package for defining your default config which can be committed to source control.
You can then override the config with environment variables.
It makes things easy easier for new devs to get started because they have all the default config they need (except any secrets) and has a centralised place for seeing what config the app requires.
I used to use envalid for everything but honestly found myself a bit frustrated with it recently; Nextjs projects in particular don't seem to be compatible. Very frustrating.
Most projects by default don't commit
.env.localto a repo. You can simply edit the.gitignorefile to change whether or not your custom file or the.envfile is committed.No need for me to it now😁
I would understand if this all was due to some security concerns, but really if someone got access for reading.
.envfile he has access for everything else...As for me naming files with environment variables is mostly conventional approach.
if that's a bold try to obfuscate the existence of API Key values inside a .env by moving them to a different file... let me tell you that if someone has access to your .env they also have access to your package.json and probably to your server processes as well. If it were me I could just ask the node terminal what
process.envcontains 🤷🏼♀️This article is not talking about not to use .env file, but not to use dotenv npm package.
Sure but it doesn't explain why you shouldn't use it. Have I missed anything?
Well, then the title is just bad - as it contains the word "file"…
It says "package", not "file"
Maybe he edited it?
The punchline about replacing the package with a CLI arg was in the last paragraph, so I wonder if most people missed it.
yes it has been edited but anyway.... the recommended way would probably be using dotenvx mostly for the encrypt stuff
Like the other people, what was the problem using .env as filename ? As someone has told, such file isn't part of the repository and shouldn't contains secrets but just configuration items.
In your suggestion, you've named the file "manas" so, without extra security feature, I will be able to access the file using a URL and see his content.
At least name it .manas, don't you think ?
This article is not talking about not to use .env file, but not to use dotenv npm package.
You're basically saying "stop using React, because look, you can do everything React can with pure JS. It's just a trendy library that nobody needs to use."
dotenv offers a lot of additional features such as variable expansion, default values, and multi-line values. There's a reason it's got 29 million weekly downloads.
Clickbait at it's best.
We really need content moderation against these cheap and title defying contents that people write just to add to their resumes that they write content. This is not okah.
I hope you could have read the article before writing the content.
I read the article multiple times before commenting to ensure I'm not misreading anything.
How in the world does renaming a .env file have to do with dotenv package. Then, you present the ability to use nodejs natively to read the file which is 🦾, but then, you do not specify the constraints.
You have not specified why to use your approach.
My advice
Please try to sit down and learn about content writing. it would benefit a lot.
Can you please share a content that you wrote, so I can learn ?
Well i go with his idea. Because most sever technology now have their own variable security, for example vercel.com which will tell you to add each content or variable constant inside .env to their own security guild(i don't know the proper name for it) for proper security. You get me right 👍
Good article, too bad there's too many trolls here that are not discussing the main point of your article. It's in the title people.
Only thing I would add is Node.js began supporting .env files starting with version 20.6.0, so if you're using a version that's anything before that you'll still need to download third party packages like dotenv.
Point is you don't need to install a third party app anymore for a built in supported feature. This article is relevant because still many people are unaware of this.
This article is not talking about not to use .env file, but not to use dotenv npm package.
I think you meant 29m+
Yeah, My mistake :)
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more