DEV Community 👩‍💻👨‍💻

Cover image for Continue Using .env Files As Usual.
Mahmoud Harmouch
Mahmoud Harmouch

Posted on

Continue Using .env Files As Usual.

Table Of Content (TOC).

👉 Inroduction.

We all know that first impressions are essential. The same goes for the first sentence of an article. In fact, it might be even more critical for an article because the first sentence is what will determine whether or not someone keeps reading.

But, in the case of this article, stating that working with large-scale systems would make you eligible enough to write about the topic is quite funny. This sentence has a psychological effect that makes readers feel like they are stupid and doomed, assuming they are all working on "Hello World" kind of projects.

Needless to say, as a reader, you may start to wonder: "What in the world does he mean when he said he has worked on large-scale systems?" I mean, literally, everyone is doing that nowadays. I don't think it can be used as a unique selling point or anything; nearly everyone has experience working with large-scale enterprise systems.

Even the most junior engineer has likely worked on a system that processes millions of requests/records daily. So what makes working on large-scale systems so unique? What makes you think your experience is worth anything special? You need to show that you have something unique to offer; otherwise, it's just another redundant sentence in your article. But anyway, let's move on.

Let's start by criticizing each point that looks like a problem with .env files when in reality, they are not problems at all but rather misconceptions.

👉 1. Storing the .env file.

🔝 Go To TOC


Everything in linux is a file.

This section started by:

The problem is well... It's a file.

Well, I don't know about you and which OS you are currently using, but everything in Linux is literally a file. This includes devices, processes, sockets, files, pipes, etc. However, the critical question is: what's wrong with it?

If you think it is not a good idea to make everything in Linux a file, including env vars, then you have to invite Linus for a debate and discuss the drawbacks of this approach. Provide your solution instead.

Additionally, containers are based on Linux cgroups, namespaces, and other components, which means that they are also built around the concept of everything being a file. This makes Linux a very powerful os for running containers, as everything can be easily managed and controlled via files.

Moreover, everything in k8s is also a file, a YAML file. This concept makes k8s extraordinarily flexible and customizable. You can literally configure anything you want, and there are very few restrictions.

As the author is now working at Google, he has the chance to discuss with the brains behind k8s, argue with them about the drawbacks of files, and share his insights with us. We would love to hear his thoughts on this matter!

Besides, the question is: Who is committing an .env file to public repos? Literally, no one with at least two brain cells is willing to commit an env file, as far as I know. Some developers on github, me included, commits only templates of this file to help other understand the env vars used in a particular project. There is a .gitignore file in case you want to ignore that file from being committed; that's the basics, and everyone should be aware of that.

Even if you don't like to include a .gitignore file for each new repo, you can add a new entry in a global ~/.gitignore file, so you don't have to worry about including that file each time when creating a new repo.

Now, you may wonder: well, how to share the .env file with other developers? And the answer goes like this: If you're collaborating with other people on a project, it's essential to keep your .env file private so that only invited collaborators can see it(e.g., create a private repo for the .env file).

👉 2. Updating a secret config

🔝 Go To TOC

I have never had access to updating a database password throughout my years working at companies. This is because there is always someone responsible for managing databases. Having access to update passwords would be a huge responsibility and could potentially lead to security breaches.

So, having someone responsible ensures that passwords are kept up to date and secure. It also means that if there is ever a problem with a password, there is only one person who needs to be contacted to fix it. This system may not be perfect, but it is the best way to protect company data.

All I can get are env names and use them within the app. That's it; Nothing else. This is why having a designated person is so important. Not only does it make life easier for employees, but it also helps keep everyone on the same page, safe, and secure.

👉 3. Versioning.

🔝 Go To TOC

Environment variables are not parts of the app code, so there is no need to version them. I have never used an app that keeps track of password history changes, and I see no reason why this would be necessary. They are just static values and don't change often.

But in any case, if you want to apply versioning to an .env file stored in a private repo, you can release a new version for each value change.

Then the author proceeds to provide a solution to a problem that doesn't exist. What's even funnier is that the solution leads to potential security risks. So basically, let someone else do it for you if you don't want to manage your secrets, not to mention that the party you share with is a centralized place. If it gets compromised, everyone's secrets in the whole damn world will get exposed.

So, everyone would instead have control over their secrets and not depend on third parties, especially in case of sensitive information.

👉 Why .env file?

🔝 Go To TOC

We, as developers, use .env files to store environment variables. These files are not meant for use in production and should be removed/ignored from the codebase before deploying it to production. If you have ever worked with containerized apps, you would know that.

The idea of having an .env file in a repo is to have an example or template of the required env vars as a form of documentation that tells which variables are needed for this project. They could have default values, but as we all know, they should never contain plain text credentials. It is like telling other developers that X, Y, and Z are used in this app as env vars. Having an .env template file in a repo sets expectations for other developers and maintains best practices. This would help new developers clone the repo and work with it without any hassle.

The application should then load this template .env and look for other places to override these default values depending on the current environment. This could be a .env.local file on the system, already set system environment variables, or variables from config storage. If you ever used Jenkins or built a DevOps pipeline, you probably encountered that.

We get it; it is not a good idea to use .env files in production because they can contain sensitive information like database passwords, API keys, and other credentials that should not be accessible to others.

However, one thing you can do though is to take additional precautions to keep your .env file or env vars secure and safe.

👉 Securing an .env file?

🔝 Go To TOC

An .env file is not secure if it's being used for production purposes. Anyone with access to the machine can view and modify it without permission.

However, you can set permissions for this file. I don't know about you, but you can use the following command to secure your env file:

chmod 0400 .env
Enter fullscreen mode Exit fullscreen mode

Doing so, the .env file can only be read by the owner and no one else. You can use this command in a docker file if you need to copy it into the docker image. But, usually, it is not encouraged to do so. In the case of docker, secrets can be used, which are discussed later in the following sections.

If you have ever worked with laravel, the chances of using the .env file in production are high. And that is ok as long as you keep it secure. The following is a typical security practice used by Laravel developers:

#Disable index view
options -Indexes

#hide a Specific File

<Files .env>
order allow, deny
Deny from all
</Files>
Enter fullscreen mode Exit fullscreen mode

In docker, you can import env variables with docker-compose using the following command:

docker-compose --env-file .env
Enter fullscreen mode Exit fullscreen mode

Or you can specify the env file within the YAML file:

version: "3.8"

services:
  frontend:
    image: awesome/webapp
    env_file:
      - .env     # path to your .env file
Enter fullscreen mode Exit fullscreen mode

If you want to pass secrets, then you can define a secrets section within the docker-compose.yaml file:

version: "3.8"

services:
  frontend:
    image: awesome/webapp
    secrets:
      - server-certificate

secrets:
  server-certificate:
    file: ./server.cert
Enter fullscreen mode Exit fullscreen mode

If you are building a docker image, you can create an env file to store secrets and mount the file to the container.

PYPI_USER=dev_bro
PYPI_PASS=my_super_duper_secret_token
Enter fullscreen mode Exit fullscreen mode

Now you can load the .env file and give it an id called my_secret. We can use this key in the next step to access the .env file. Then modify your Dockerfile so that it mounts the secrets.

FROM python:3.9-slim-buster
COPY build-script.sh .
RUN --mount=type=secret,id=my_secret . ./build-script.sh
Enter fullscreen mode Exit fullscreen mode
# build-script.sh:
cat /run/secrets/my_secret
Enter fullscreen mode Exit fullscreen mode

Now, you can build and inject the .env file into the container:

export DOCKER_BUILDKIT=1
docker build --progress=plain -t "my_app" --secret id=my_secret,src=.env . --no-cache
Enter fullscreen mode Exit fullscreen mode

Note that these env vars are not logged into the history, so running the following command won't reveal the secrets:

docker history my_app --no-trunc | grep PYPI_PASS
Enter fullscreen mode Exit fullscreen mode

For more info about secrets in docker, you can refer to this piece of docs.

Additionally, if you are using k8s, there are API objects like ConfigMap to store config data and Secrets to store confidential data. Or, you can set env vars within a pod.

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod

spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
        # Define the environment variable
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              # The ConfigMap containing the value you want to assign to SPECIAL_LEVEL_KEY
              name: special-config
              # Specify the key associated with the value
              key: special.how
  restartPolicy: Never
Enter fullscreen mode Exit fullscreen mode

I have worked on many projects, some of which are open source. In some projects like this one, I used env vars to store my secrets within circleci to publish a new version to PyPi automatically.

Moreover, for security reasons, I have noticed that PyPi has implemented a feature to allow authentication with their servers through using api tokens without the need for passwords anymore. So, now you can store encrypted PyPi credentials within env vars.

If you ever built a pipeline with Azure DevOps, you probably wanted to copy the .env file into the docker image using Copy files task:

steps:
- task: DownloadSecureFile@1
  displayName: 'Download secure file'
  inputs:
    secureFile: .env

- task: CopyFiles@2
  displayName: 'Copy Files to: $(System.DefaultWorkingDirectory)'
  inputs:
    SourceFolder: '$(Agent.TempDirectory)'
    Contents: .env
    TargetFolder: '$(System.DefaultWorkingDirectory)'
Enter fullscreen mode Exit fullscreen mode

If you are using Jenkins, you can inject env variables using plugins like envinject

So, as you can see, it depends on the type of applications you are dealing with to follow the best practices to securely use an .env file.

👉 Advantages of using an .env file.

🔝 Go To TOC

There are so many advantages to using .env files or environment variables, such as:

  • Ease of management: Having worked on so many backend projects, I find .env files easy to manage because they are self-explanatory and don't require additional documentation.

  • Simplicity: .env files simplify the task of managing different backends because it allows you to configure all the necessary settings for each backend in one place.

  • Debugging and testing: It becomes easier because developers can modify a specific environment for each application.

  • Sharing: .env files templates like .env.example can be added to git repositories, so other developers on the team know what environment variables were used for that project.

👉 Problems With Centralized Config Servers.

🔝 Go To TOC

Several potential problems can occur when using a centralized config server for an application. If the server goes offline, the app will not be able to start. If the server updates and renames an environment variable that the app is not expecting, the app may crash on the next restart. Finally, if the app is hosted offline, it will not be able to start without an internet connection to load the env vars from outside.

👉 Conclusion.

🔝 Go To TOC

At the end of the day, .env files and environment variables work fine and are simple enough for development purposes, as long as you know how to use these files. However, it is totally up to you to choose the best approach that aligns with your personal preferences, what works best for your particular application or system.

👉 Bonus For Linux Enjoyers.

🔝 Go To TOC

On Linux, if you want to print out a specific environment variable, like LOGNAME, of the current process, then run the following command:

strings /proc/$$/environ | grep LOGNAME
Enter fullscreen mode Exit fullscreen mode

And last but not least, remember that everything in Linux is just a file including the command that you have just executed:

cat /usr/bin/strings
Enter fullscreen mode Exit fullscreen mode

Note: This article is not meant to insult anyone by any means; I just wanted to share it with everyone to clarify the situation with .env and give some tips on how to use them.

Have a lovely weekend, folks.

Cover image by Mike Souza, on Flickr.

Top comments (125)

Collapse
 
gregorygaines profile image
Gregory Gaines • Edited on

Ayy, thanks for the shout-out! Let me plug my article here.

You should check it out, it's a banger!!


First let me say I like how your only cons against config servers is that it can go down and it's remote. Wait till you learn about what a database is, you'll probably be using a json file for the rest of your life!

Also what's your obsession with bringing up my file statement? Is the /usr/bin/strings "file" carrying production data? If not, then I don't have a problem with it.

nearly everyone has experience working with large-scale enterprise systems.

As large as Google's? Lol. Im Jk. Nice burn tho.

As the author is now working at Google, he has the chance to discuss with the brains behind k8s, argue with them about the drawbacks of files, and share his insights with us. We would love to hear his thoughts on this matter!

Funny enough, internally all secrets / configs must be stored in enterprise stores like HashiCorp Vault or Google KMS.

Who is committing an .env file to public repos?

New people, people who don't know? In-fact, .env files have their own vulnerability listing because of how much it has happened https://www.acunetix.com/vulnerabilities/web/dotenv-env-file/. So a-lot I assume.

If the server updates and renames an environment variable that the app is not expecting, the app may crash on the next restart

One of the benefits of a config server is reproducibility. This won't be an issue. Config servers keep a trail of all configs.

If the server goes offline, the app will not be able to start.

If your database goes down your app can't start. If your hosting platform goes down your app can't start. Anything can go down, doesn't mean it's not viable. You can introduce a cache within your application so it only has to read variables one time.

But in any case, if you want to apply versioning to an .env file stored in a private repo, you can release a new version for each value change.

What if your private repo gets leaked, now everyone has access to all your **** secrets! What is someone downloads the whole repo to their laptop and it gets stolen? Or someones personal laptop has one of these production configs and someone decides to a take a peek?

Just saying with a config server, a stolen laptop means nothing since you have permissions and access management. Someone can't just come along and copy and past a config server.

--

And some points still stands.

  • Someone has to edit and see all secrets. No Matter How Trusted This Person It, It Breaks So Many Guidlines which is why Google uses config servers.
  • No secret rotation
  • No access restrictions or permissions
  • No audit logs, if a secret gets leak you don't know the entry point.
  • Probably passing secrets through email / slack
  • Manual file editing leads to human errors. Oops someone forgot to update one of out .env files now productions down.

—-

Final note: I should have taken into account that most devs reading probably haven’t operated at the scale to notice the issues my article is addressing. Maybe that’s one of the major disconnects.

I’ve noticed a lot of I haven’t had these issues therefore it doesn’t exist type replies.

Collapse
 
jeanno profile image
Jeanno • Edited on

A practice adopted by Google doesn’t automatically become universally applicable for every project.

At a big tech company it might make sense to reduce security risk by taking layers of precautions. But if it’s just a small personal project, obviously people shouldn’t care too much about setting up a separate config server, or doing credential rotation.

Keeping secrets away from repo is still a common practice. However, the way Gregory presented it just isn’t very helpful. The “I work in Google so I must be right. The audience hasn’t operated at Google scale so they don’t understand” attitude is simply naive and arrogant.

Collapse
 
gregorygaines profile image
Gregory Gaines • Edited on

If I came off as naive or arrogant, I'm sorry I didn't mean to come across that way. The reason I brought up my work experience is to give credibility behind my statements. In fact, people have brought up my Google experience more than I have.

I also did admit to the fact people haven't worked at the huge scale where they experience the problems to makes my article useful and I'v already admitted that myself. Even in my original argument I mention that .env files have their place which people seem to miss.

I never said since people haven't worked at Google they don't understand nor have I ever implied that. I only mention scale which you yourself proved in your comment above.

Thread Thread
 
thomasjunkos profile image
Thomas Junkツ

If you need to have to back up your credibility in order to make your point is no good idea. It's basically arguing with authority (you in this case).

Your point should be good independently the speaker is working at google or at some 2 people random startup.

Thread Thread
 
gregorygaines profile image
Gregory Gaines • Edited on

I see it as having a good point and worked in the environment to apply those points. I decided to give a little insight into how I came across those points, not have people take it as a personal attack.

Thread Thread
 
polaroidkidd profile image
Daniel Einars

I read a lot of the comments on your article and the common theme seems to be the added dependency. I'm curious about the Google secrets manager now and will give it a spin since I find myself copy & pasting environment variables between environments and two dev machines. The service would allow me to have one central point to manage them (yes, also a single point of failure).

Thread Thread
 
gregorygaines profile image
Gregory Gaines • Edited on

Yes, but only if you need it or it will make development easier.

And wow! someone willing to understand the approach instead of throwing an insult!!

Thread Thread
 
t0nyandre profile image
Tony André Haugen

I really can't see why so many people show hate on this approach. This is a good approach for development AND production environments because you have one central point to manage all secrets. I have been using this approach now for a year without being in a big company which is FORCED to do so. I just love how easy it makes every step of development and it removes the possibility where secrets could potentially get leaked. And if you structure all your secrets your life as a developer will become so much easier :)

Thanks for a really good, but misunderstood (?) article! Keep on writing about you experience because I will for sure read them :)

Thread Thread
 
gregorygaines profile image
Gregory Gaines

Thank you Tony. I’ll drop more bangers be sure to follow to get notifs.

Collapse
 
femar profile image
Fredrick Femar Ochieng

good

Collapse
 
webjose profile image
José Pablo Ramírez Vargas

I must side with Gregory here on this one. We at Intel also have to separate secrets and everything. dotenv doesn't seem a suitable candidate AT ALL. I removed all dotenv use from the React projects. wj-config allows me insertion of K8s secrets or config files while maintaining the separation between data source and consumption.

Bottom line is: Don't get stuck in the past.

Collapse
 
ivorator profile image
ivorator

I am curious, what secrets you are keeping in react projects at Intel...
You know, any "secret" the client has is no longer secret to anyone accessing that UI.

Thread Thread
 
webjose profile image
José Pablo Ramírez Vargas

The whole story behind wj-config was to make sure it worked in both NodeJS and React. In our particular project yes, we did not have any any secrets in the latter, but we had a URL mess.

Thread Thread
 
ivorator profile image
ivorator

A whole lot of time wasted by devops trying to figure out why a deployment is not using the real env var, just to figure out dotenv is loading some file and shadowing them.

Yes I agree, dotenv is some weird file configuration pretending to be env configuration. That would be pretty good example of how not to use .env file.

Collapse
 
abigalead profile image
abigalead

Probably passing secrets through email / slack

If you are using a private repository, you can add contributors without sending emails. Just add the GitHub handle to that repo as a collaborator.

Collapse
 
gregorygaines profile image
Gregory Gaines

Again if you have to edit a file, all the secrets are exposed to the editor.

Thread Thread
 
abigalead profile image
abigalead

You hire someone who is responsible for all his/her actions, right?

  • No audit logs, if a secret gets leak you don't know the entry point.
  • Manual file editing leads to human errors. Oops someone forgot to update one of out .env files now productions down.

Commit history?

  • No secret rotation.

Why do you need that?

Thread Thread
 
gregorygaines profile image
Gregory Gaines • Edited on

At Google you can be the VP of a project and STILL don't have access to see secrets. Thats just how things work. It's like moving to a safe neighborhood. There's no crime but you still lock your doors.

Commit history?

Wasn't the point of a .env was that it goes in the .gitignore?

Secret Rotation - Why do you need that?

The fact you asked that scares me a little lol. Rotate AWS Secrets, CyberArk Rotate Secrets

Thread Thread
 
abigalead profile image
abigalead

As mentioned in his post, you can have a private repository to share the env file with other team members. If someone changes the values of these environment variables, it will be logged into the commit history.

Thread Thread
 
gregorygaines profile image
Gregory Gaines • Edited on

Maybe I'm not being clear enough. No one person SHOULD EVER have access to view any secrets at anytime, unless they are initially adding it (which even then shouldn't be possible but I don't want to increase the scope of this discussion).

It doesn't matter where that .env is. In a repo, the moon, under a volcano, or area-51. The rule above still applies.

Collapse
 
ivorator profile image
ivorator

I am not quite sure on what you base the assumption that people are using .env files in production. This is why you sort of come up as arrogant. You seem to somehow assume people are clueless.
Your actual deployment secrets would usually come from your, well deployment config, and can come from many places. These can be sealed secrets, gh actions secrets, and the vast majority of devs will not know, or care what and how the production environment does it.
In my experience.env, just as docker-compose are part of your dev setup. There is absolutely nothing secret there. The whole point of having these as env variables, rather than a config file of some sort you read directly, is to replace them later, rotate them and whatnot

Collapse
 
gregorygaines profile image
Gregory Gaines • Edited on

It was more of a PSA than a hey you do this assumption. I never claimed anyone did anything so I’m not sure how I came off as arrogant but I’ll work on it. Also I did not mean to challenge anyone’s intelligence.

I didn’t mean for anyone to take my article as a personal attack.

Thread Thread
 
ivorator profile image
ivorator

It's a big like saying stop using docker compose, is not good for production. Sort of moot since most people know and don't.

Now the funny part is there are many ways to deal with secrets, depending on your deployment, including yes encrypted files you can keep in your repo. And your solution actually will not work, or be redundant in many cases.

As of why you sound arrogant? Well, "I have been driving fast cars on the highway, let me explain to the yokels why pickups suck", lol. Sort of missing the use case.

Thread Thread
 
gregorygaines profile image
Gregory Gaines • Edited on

I think a better comparison is "I've seen 99% of car guys saying you can beat a mustang gt with a pt cruiser and here what to buy to do it" lol. And of-course I see the commenters at the pt cruiser enthusiasts telling me you don't need a new car, just mod your existing one, eventually making it as fast as the gt instead of outright buying the gt.

I put the use case in the first sentences, but i digress. My solution is completely viable, plz re-read if you don't think so because you example has nothing to do with making my solution not viable or redundant. Or can you try connect them better?

Thread Thread
 
ivorator profile image
ivorator

Oh boy. The problems you are solving are not problems because people don't use .env files the way you think they do. The world won't end if you know the local postgres container password is "password". So no it does not need encryption, or rotation or whatever the heck, because it's just a placeholder password, for a placeholder db, for placeholder data.

To repeat once more. In vast majority of cases .env is used to manage environment variables for a local container or app, in a development setup. The reason it's shared, or rather an example .env is for people to know what env vars need to be set.

Your production deployment will vary. If you deploy to AWS you will use the AWS secrets manager. If you deploy to GCP you will use the GCP secrets, naturally.

So telling people to not use .env, is rather uninformed as to what people use .env for.

Thread Thread
 
gregorygaines profile image
Gregory Gaines • Edited on

I know .env don’t need those things, I’m saying they can’t do those thing that’s why I bought up a config server and he’ll out those who might need those things.

And not everyone uses .env files for what they are for which caused the birth of my article. I feel like we are in a circle.

Collapse
 
ashutoshpw profile image
Ashutosh Kumar

I was literally searching for the use case of KMS servers, your points and explaination completely makes sense to me.

One thing, I would like to add:
Both the things have their own use-cases, KMS is better at a scale like Google. .env is better in smaller engineering teams who know what they are doing. Like in my case, one person is responsible to set ENV in production environment. Rest of all, gets only test credentials.

One can move from .env to KMS when project goes so big (people count increases) by Changing all existing secrets.

Collapse
 
ashu2 profile image
ASHu2

Well said, still then I'd argue even if you're small scale you should use the best practices.
Fundamentally it's not a matter of scale or not, it's a matter of security.
Even the one person you mention might have a compromised system at any point in future. Better do it now than be sorry later.

Collapse
 
ltsochevdev profile image
Sk1ppeR

Databases can be hosted locally next to the app and connect to it using Linux socks so essentially you can pull the ethernet cable out and it would work.

Collapse
 
gregorygaines profile image
Gregory Gaines • Edited on

Config servers can be hosted on VPCs giving a local host like connection to your application. No internet traversal required.

But if you pulled the Ethernet cable out then how could users connect to your application? Wouldn’t it not be useful at that point? Am I missing something?

Thread Thread
 
ivorator profile image
ivorator

You are missing the difference between development environment and production deployment.
You usually run a bunch of services locally on your laptop, while you work on one of them. Your users are not connecting to that.

E.g you could have frontend, backend API, proxy, message broker, db or two, worker services which consume from a queue. And you can be working just on one of these, but you need working setup.

These would need configuration, including secrets shared between services. You don't need to worry about these being secret, because only db or service you can use them for are said services you run locally.

This is what majority of people use .env files for, i.e. keep environment variables for local environment.

Granted, you can have secrets for third party services there, so it's never good idea to commit .env in repo, in case someone adds something actually secret there. Also why it should always be in .dockerignore, so you don't push it to image registry

Your production deployment and configuration are a whole different beast. How you keep your the real secrets depends on your setup. At this stage usually you would separate secrets, and regular env vars and treat them differently. You would not keep your logging level as a secret for example

If one keeps actual production secrets in .env files, that is indeed very very noob move. Then there are things as Laravel which seem to just use .env as some sort of .ini file.

Thread Thread
 
gregorygaines profile image
Gregory Gaines

I know the difference between local and production. If you read my article, I say myself .env variables are useful for local / development oriented environments and I was specifically talking about production.

I knew there was a disconnect! Nice conversation, you seem very passionate.

Thread Thread
 
ivorator profile image
ivorator

You are focusing on specific case, i.e. production (or third party access) secrets, as if that's the only use case for .env files, and as if secrets are the only env vars your app needs on production. Are you really going to keep everything in a sealed secret or a vault server of some kind?

To quote you - "What I'm trying to say is don't store valuable secrets in simple files"

Not sure why do you think people do. There is nothing secret or valuable on placeholder password for local development, or most env vars.

Thread Thread
 
gregorygaines profile image
Gregory Gaines

Just because I'm focusing on one use-case doesn't mean I'm saying thats the only use-case.

Maybe I'm not being clear? Again, I mention .env are useful for development oriented environments which excludes my points from those environments. Development oriented environments including local.

Thread Thread
 
ivorator profile image
ivorator

So with other words, "continue using .env files as usual" i.e. not for keeping production secrets, which you probably don't have access to anyway. Glad we agree, lol

Thread Thread
 
gregorygaines profile image
Gregory Gaines • Edited on

Yeah lol I’d phrase it as “keep using .env not for production and only if your using them right as usual”.

We were going in a big circle. I should have made by target audience clearer which I feel is the biggest issue people have not my article itself.

Nice chat your passionate, glad we could talk!

 
ltsochevdev profile image
Sk1ppeR

Offline on-prem self-hosted exists in 2022 btw.

Collapse
 
codebytesfl profile image
codebytesfl

I work in large enterprise (we're competitors to Google ;) ). Your article makes a lot of great points.

I'm not sure if Google has something similar, but we use AWS Parameter Store to centralize our "env". We have robust permission system that allows only the app to consume the secrets, and certain users to edit the parameters.

In a large enterprise this helps us separate our concerns. Our developers can focus on developing rather than securing an .env file. Our DevOps can focus on secret management. We also frequently rotate values in our "env" which would really annoying to keep all the devs in sync, securely. This central place allows for someone to edit the value Once and All developers now have the latest values.

Additionally, our parameters are fetched at run time vs at build. Meaning we can rotate a value without restarting the services. The services automatically pick up the new values next time it's called.

Unfortunately this method adds a lot of overhead. Unnecessary in small / solo projects. ENV files would probably best. But in enterprise, in large teams, and teams with strict security protocols (separation of concerns) there are alternative solutions that may be better.

Collapse
 
brense profile image
Rense Bakker

Can we all agree on one thing? That there should definitely be a .gitignore file in every repo with atleast this content:

.env
Enter fullscreen mode Exit fullscreen mode

From a dev perspective thats the only thing that matters anyways =p

Collapse
 
ivorator profile image
ivorator

For the sake of argument, not really (though I personally always do, because you don't want your env to be overwritten by the latest pull).

Say you have a frontend repo. If you use any secret stuff in your frontend build, it ends up baked inside your UI, and anybody using your UI can see that "secret" API token you cleverly hid from the repo:D.

If I had a dime for every UI which emits API tokens neatly in every request, but went through the trouble to hide it from every dev but the general public.

If your front requires any secrets - it probably should not.

Thread Thread
 
brense profile image
Rense Bakker

About which part do you disagree exactly? Putting FE "secrets" (nothing in the FE is ever secret) in a .env doesn't solve the issue of the "secret" getting baked inside the FE during build.

Thread Thread
 
ivorator profile image
ivorator

There is no need to hide .env from repo to hide secrets, since they are public

Thread Thread
 
brense profile image
Rense Bakker

But that's exactly where the risk/problem is... Someone on the team will interpret the .env as something where they can put local secrets (because that's what it is for) and BAM secrets are now leaked into version control and you have a problem. There's no benefit from committing .env to version control so don't do it. If you have FE "secrets" that don't change based on environment, just put them in a json file or return them through a BE api if they should change per environment.

Collapse
 
mahmoudajawad profile image
Mahmoud Abduljawad

Thank you for the points. I couldn't agree anymore.

Collapse
 
isalahyt profile image
iSalah-YT

Thank you so much for that 💗🤠

Collapse
 
leob profile image
leob

I see a little polemic unfolding, lol :)

Collapse
 
adonis profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Adis Durakovic

Wait till you learn about what a database is

It's a bunch of files

Anything can go down

Sure, but adding an unnecessary layer of potential downtime for literally nothing is just stupid.

Reading your comments, you're clearly delusional and I doubt you have any experience. Stop misleading junior-devs.

Collapse
 
kohanan profile image
kohanan

Same for me. i also doubt if he is actually a Google employee or just trolling this platform.

Thread Thread
 
gregorygaines profile image
Gregory Gaines • Edited on

Or maybe I'm just above your level of understanding that just can't comprehend it therefore it feels like trolling lol.

In JK, on a seriously note, I would love if you could give some pointers. Throwing insults isn't interesting. And wow the commenters are more interested in my work than me.

Thread Thread
 
kohanan profile image
kohanan

The clickbaity title is enough evidence for trolling.

Thread Thread
 
gregorygaines profile image
Gregory Gaines

Nice chat, have a nice day!

Collapse
 
gregorygaines profile image
Gregory Gaines • Edited on

Lol y’all love taking that files quote. You don’t look at a database and say yea that’s just files. It’s a complex storage and retrieval system with permissions and access management like a what?? Drumroll….. like a config server 🎉🎉. Your a funny guy 🤣.

Insults with no counter points isn’t very insightful. But maybe since I have no experience like you claim then I probably haven’t learned that it is 🤔.

Again, I admit most developers have not worked at the scale to experience the problems my article addresses. If I’m delusion it seem your included in that group.

Plz re-read my article and don’t just free throw. Thanks!

Collapse
 
cicirello profile image
Vincent A. Cicirello • Edited on

When your first 4 paragraphs do nothing but criticize 1 sentence in another post, at least some of your readers will leave without ever getting to whatever technical content your post contains. I read the post you refer to. It was a good read that made good points, and lead to an interesting discussion in the comments.

I clicked on your post because the title implied that it would offer a counterpoint to the other. So I assumed would be just as interesting. But I won't ever know because the attitude of your first 4 paragraphs has sent me away.

Collapse
 
lukyey profile image
lukyey

You are correct. The author exaggerated a bit by criticizing this sentence. But I totally agree with him. It is wrong in all 4 directions!

Collapse
 
tiagorangel2011 profile image
Tiago Rangel de Sousa

Same for me!

Collapse
 
thomasbnt profile image
Thomas Bnt

It's a bad thing for new readers who stop reading right away, I think, because there is still a counterbalance to the referenced post.

Collapse
 
tinae1 profile image
tinae1

Thanks for sharing. Bookmarked! Docker secrets look interesting, never used it before.

Collapse
 
theaccordance profile image
Joe Mainwaring

Excellent rebuttal to a narrow opinion previously shared here.

Recently, I began to use 1Password to store the values I normally hard code in .env files so team members in my organization could more quickly get up and running, I've documented that process here

Collapse
 
gregorygaines profile image
Gregory Gaines • Edited on

I don’t know about 1Password. From what I did see, it functions like a vault / centralized configuration utilizing the benefits I mentioned in my article. I’m proud!!!

I am feeling a sense of irony reading your reply tho. Good job on your solution!

Collapse
 
theaccordance profile image
Joe Mainwaring • Edited on

FWIW calling your article a narrow opinion is meant to be a constructive point of view. You do bring valid points and reasoning, but I view that .env file as just a tool in the toolbox. You just have to know what makes it the right tool for the job, and there are A BUNCH of situations where the .env file is not the right approach

Collapse
 
ashu2 profile image
ASHu2

I don't understand what's narrow here lol. I won't talk about how he's contradicting himself

Thread Thread
 
theaccordance profile image
Joe Mainwaring • Edited on

The headline, for starters.

I won’t deny there’s valuable content, but the narrative did have an off-putting effect to readers.

Collapse
 
matijanovosel profile image
Matija Novosel

Even though I think that you've gone a little bit too hard on the author of the other post I can't shake the feeling that clickbaity posts such as those do more harm than good since they don't elaborate in detail why that approach is lacking.

This is a great rebuttal though and now both sides of the approach can be taken into consideration.

Collapse
 
gregorygaines profile image
Gregory Gaines

I was sure I sent the first half listing issues and then give solutions? Was I not clear enough? Even then this article doesn’t even counter all the points I made in the original article.

Collapse
 
matijanovosel profile image
Matija Novosel

I'll have a thorough read once again in that case, though I'm not for dropping the approach completely. It is a nice discussion, though!

Collapse
 
shifi profile image
Shifa Ur Rehman

So that's why so many of google's applications are being taken down 😂 jkjk.

Anyway here are my two cents:
I agree with most of it. And focus on the word "most" of it. Just the part where you make one person responsible of all the secrets and then try that person if a breach (of contract; its implied in an NDA right?) happens. But in any case, forget for a few mins you are dealing with a corporate giant who has literally an army of lawyers in their pocket to fight for them, if it were a startup or a company transitioning from startup to a medium sized company/firm/org, their reputation would've already passed through the shredder by the time they wake up and realize what has happened.

You just need to be bit by a snake to really grasp the intensity of the poison. Maybe you haven't been bitten by that snake yet.

But yes, if we forget the above point that one person is responsible for every secret, your explanation is pretty constructive and there's a lot it leaves to debate over.

A good article indeed.

Collapse
 
shifi profile image
Shifa Ur Rehman

And hot damn i didn't know a soldier boy has already posted an anti to this article 😂 this community is golden!

Collapse
 
majoun profile image
Amina

Exactly!

Collapse
 
gregorygaines profile image
Gregory Gaines

We get taken down but at-least we not getting secrets leaked. Sounds like a win in my opinion lol.

Collapse
 
shifi profile image
Shifa Ur Rehman

Yes. But honestly, think about what I said. The person in charge of secrets at your corporation is afraid of life ruining legal repercussions and that's only because your legal side is so damn strong. A small to medium software house doesn't enjoy the same level of legal assurances.

Like I said, your article opens up discussions of a whole other kind. I can make a podcast on it and you'll see we'll make dozens of episode just exploring the true details behind the scenes. Over the top, .env seems a simple enough issue. The more you delve into its dark depths the more you realize.... It's really just a subjective decision by whoever makes it.

I have no hate against megacorporations. I just know for sure by experience, when you start to discuss "what they do and people should do exactly", these megacorporations are almost always years behind in the most unusal of places. And for your google, this .env can be that if you don't think everyone is criticizing you and look at both the sides of this coin.

Thread Thread
 
gregorygaines profile image
Gregory Gaines

Seems like all the better reason why this conversation needed to happen. And it’s a deep topic which is why I opened the door. I admit most people haven’t worked at the scale to notice the issues my article addresses.

Thread Thread
 
shifi profile image
Shifa Ur Rehman

No no. My dear good Sir, everyone sane, and I mean roughly 70-80% developers, even the juniors included know this issue. They ask about this shenanigan.

I literally had a trainee who asked me this question about two days ago, and why I was so excited to see your post was that I found yin and yang's of this conversation right in a single thread and gave her these articles to read and better reflect on it herself.

Like her and most others (about 6/7), they chose to stick with .env files but acknowledge the exact issues you gentlemen have laid infront of us.

This means either this thing is so well established that no matter how many better solutions you think of, they won't be enough. OR... the correct implementation of the thing is yet to be seen.

Either way, I agree with you my dude. It's not just criticism. I understand your point of reference, and I understand how you revolve around it. Im just saying that... This is a coin. And it has two very different sides with their own identity. Whether one likes it or not.

But like I said, good article. Many points to ponder over in future. This will be in my shower thoughts I promise you :p

Thread Thread
 
gregorygaines profile image
Gregory Gaines • Edited on

Well put, there isn't one lie in your comment! I completely understand, I guess the rapid back-and-forth and constant insults thrown at me has had me on the defensive and for that I apologize.

I'm glad we had a chance to talk and I wish you much success.

Thanks!

Thread Thread
 
shifi profile image
Shifa Ur Rehman

You sir. Are a gem. Keep on rocking!

Thread Thread
 
shifi profile image
Shifa Ur Rehman

"all criticism is good criticism if one has the appetite for it". Let's close on this. And bid farewell until we talk again in another one of your posts ^^ /

Collapse
 
dubcee93 profile image
dubcee93

While this article eventually has some somewhat interesting content, it is pathetic that the author has chosen to criticize another post in such a childlike manner. The other post did not come at you personally, yet you took it that way. It's sad, honestly. @gregorygaines may be right or he may be wrong, but he has posted an article with good reasoning and points and has been very respectful in his replies. You, however, picked a fight for no reason and are now reminding everyone of their annoying little sibling. Grow up and leave the toxicity behind. One can debate interesting topics and still maintain a demeanor of respect. Good Lord.

Collapse
 
majoun profile image
Amina

What do you mean? The article was so formal and highly professional. Did you ever consider reading it? Or just cowardly assumptions?

Collapse
 
dubcee93 profile image
dubcee93

I did read it, including the very beginning part, It may have some well-written parts (note where I said 'While this article eventually has some somewhat interesting content'), but it also has a an intro and several parts that sound like a snotty-nosed child said them.

Collapse
 
xpfann profile image
Scott

Here is the thing: let's imagine you are having a good dinner at MacDonald, and out of the blue, a guy comes up to your table and tells you: "Stop Eating Tacos, or whatever, Now.". Would you be offended? Probably not. But what if they said it in an insulting, aggressive way? Then you might be offended.

This post is clearly not a personal attack or an assault on the other author. But instead of getting mad at this post, take a moment to appreciate the author's time and effort in writing such a response. This person has written nothing but facts, and it takes guts to write something like this. So kudos to him for having the courage to speak his mind.

Collapse
 
dubcee93 profile image
dubcee93

1) I can genuinely say I don't think I understand your first paragraph.

2) Sure, it takes some guts to say anything, I suppose. Although, I don't think it takes that much guts to type something on the Internet. That aside, the post would have been great if it had just been to the point, but instead it included a level of toxicity that wasn't necessary to make the point. That is what I commented on. I love sharing ideas and learning new things - I really do, but I can also do without the toxicity that is already so prevalent elsewhere on the Internet. It'd be nice if people as smart as software developers could get rid of the ape mind and just have an academic discussion or debate without taking pot shots that don't add anything.

Collapse
 
sahibalejandro profile image
Sahib J. Leo

This is a great article! Thank you for sharing your knowledge.

Collapse
 
ashu2 profile image
ASHu2 • Edited on

I like how your Problems With Centralized Config Servers is mainly around it can go down and needs internet. Ufff.

Your database can go down, your docker servers can go down. Everything can go down. Should we stop using internet now and go back to DVDs ? Even DVDs can go down.

Collapse
 
jarrodhroberson profile image
Jarrod Roberson

exactly, your app needs the internet is never listed as a concern. these are just people that do not know what a logical fallacy is or have never studied debate.

Collapse
 
xpfann profile image
Scott • Edited on

How about an app with a simple database, does it require internet connection to work locally? Also, there is a major issue with privacy that the author didn't point out. Allowing a third party to manage your credentials would be an issue with privacy. Doing it yourself is even better.

Thread Thread
 
gregorygaines profile image
Gregory Gaines • Edited on

I did. I mention multiple third party and self hosted solutions. I’m under the impression you did not read my article as your just shooting free throws in the comments.

Thread Thread
 
jarrodhroberson profile image
Jarrod Roberson • Edited on

the original article by Gregory that this is a "response" to, specifically stated ...

I've worked on huge enterprise systems and I'm disappointed to see 99% of all JavaScript tutorials tell you to use a .env for production config and secrets which is dumb.

The original article also never stated anything about you must "Allowing a third party to manage your credentials" it just says use secure storage like a vault. There are plenty of secure vault storage systems that you can host yourself or "run locally" if that red herring is such a deal breaker.

so your comments are completely a straw man fallacies. If you want to constructively critique then great, but you are not doing that, you are just slinging logical fallacies, a few more and you will cover all 10.

Thread Thread
 
xpfann profile image
Scott • Edited on

99% of all JavaScript tutorials tell you to use a .env for production config and secrets which is dumb.

Can you please cite the source from where this statistic is taken? Or is it just based on gut feelings? Can you please stop being rude and posting nonsensical information?

It is tough to take your comment seriously when you make claims without backing them up with sources. If you cannot provide a reference for this information, I must assume it is false. In addition, your tone is very off-putting and makes it difficult for me to take your comment seriously. I suggest you take a more respectful and professional approach in your writing if you want people to take your words seriously.

Thread Thread
 
gregorygaines profile image
Gregory Gaines • Edited on

One statistic is the comments themselves lol. But seriously I’ll get back to this comment soon. I never meant to come off as rude or arrogant, I was trying to get my point across quickly sorry if it came off that way.

And if my comments are nonsensical I don’t know what to tell you. I’ve gotten accolades from many companies and other devs. Maybe give my article another read if that’s your conclusion without emotional prejudice because every interaction I’ve had with you has been negative or insulting. Can we try this interaction again being respectful?

Collapse
 
wadecodez profile image
Wade Zimmerman • Edited on

Definitely a bigger fan of .env, but don't really enjoy either article because I think this is a stupid debate.

IMO do whatever is more efficient for your team. If there is actually a benefit to using the cloud vs .env files then use the cloud.

However, on my "small scale" projects, the time/costs required to implement a config server are not worth it. For me, it is more efficient to use a .env file.

Collapse
 
jmau111 profile image
jmau111⭐

I don't think the debate can be qualified as "stupid." It's a real concern. A major issue is unencrypted secrets in .env, which happens all the time.

Cybercriminals exploit vulnerable instances to get credentials and progress through the different layers. It's a credible scenario.

Collapse
 
wadecodez profile image
Wade Zimmerman

Encryption does not equal security. Encryption equals obscurity. No matter how you encrypt your data, or where you store it, there must be a master password to decrypt everything. What happens if someone disregards other security measures? A hacker will obtain the master password. This is why passwords should be hashed instead of encrypted (but that is a whole other conversation).

BTW most hacks do not occur through code, they occur through social engineering. (yet another conversion)

What I'm getting at is, .env files are not insecure, it's your instance, server, application, or place of work that is insecure. As a dev, here are some things you should know (study cyber security for more mitigation):

  • API keys typically have access control and are revocable.
  • Teams should use different set of secrets in production than in development or staging.
  • Services should run as a specific user rather than root.
  • Files have permissions.
  • Automated tests should mock/fake calls to services.

Also, if you are handing your secrets over to a third party, how do you know they won't get hacked? You don't.

Thread Thread
 
jmau111 profile image
jmau111⭐ • Edited on

Encryption equals obscurity.

I beg to differ. Encryption is a layer of security. Encrypting is not like hiding something somewhere as is, hoping nobody will find it.

BTW most hacks do not occur through code, they occur through social engineering. (yet another conversion)

Does not mean anything, to me, as it does happen, just subscribe to exploitdb. So you want to take the risk just because another technique seems more popular? It does not look like a solid approach, to me.

Also, if you are handing your secrets over to a third party, how do you know they won't get hacked? You don't.

Right, you don't. Nobody said it would fix all problems. Still better than unencrypted/hardcoded credentials.

Collapse
 
webjose profile image
José Pablo Ramírez Vargas

As a backend developer that had to meddle with the front-end work done in React, I found their use of dotenv sloppy and basically unacceptable. This is when I created the first version of wj-config. Not only does it do everything dotenv does, but does everything config does, and it can be used in the browser or NodeJS without transpiling or anything because I transpiled it to ES modules, something understood in both worlds as-is.

So if you asked me which one to use, I'd just say "put dotenv to rest and move forward with wj-config".

Collapse
 
scottshipp profile image
scottshipp

What is the debate here?

There's not really any debate to be had about good security practices. Those are well-known and easy to discover and learn.

The benefits of externalized configs are also understood at this point. They've also found their way into every language ecosystem.

I also think that any points about the scale of an application as it relates to the need for good security practices are weak on their merits. Whether the application has many users or a few, security is orthogonal. An application could be used by a single user to store a million dollars of bitcoin and you can bet that security is a primary consideration.

So what is the debate here?

Usually, it's better to listen and try to understand, rather than to debate.

Collapse
 
xpfann profile image
Scott • Edited on

Exactly. It looks like the other guy is struggling to learn the basics of .env files. He started to act like he was the genius in the room, knew everything, and generalized google's practice, especially for junior devs.

Generalizing Google's practices is not helpful. What works for one company may not work for another. Each company has their own way of doing things, and it's important to respect that.

Collapse
 
gregorygaines profile image
Gregory Gaines • Edited on