Environment or app variables but with a safe and better approach

Most companies and developers today heavily rely on .env variables and similar methods to manage, access, and deploy applications with their secrets. And we must admit, they are cool, and easy to setup unless you're looking to scale and build an ecosystem around them. You will quickly face all kinds of problems doing it this way.

So, for this reason, Envless was born. It was a daily problem in our projects, and we wanted to reinvent the solution for our use and for the community's benefit. We want to change how people think about environment variables and start migrating to the .envless structure.

But our first blog post isn't just about our product; it's also about the old way of using environment variables with .env files or similar technologies in different programming languages.

What are .env variables, app secrets?

Environment variables, or app secrets as they are referred to by the development community, are a way to define key-value pairs of public or secret data that can be accessed by the application at any point. The idea is reusability and easy switching of them for different environments, such as staging, development, and production.

Why does the development community use them if they are bad?

When it comes to this method of environment variables, it's clear that one of the biggest reasons is simply that it's easy to set up, and everyone else uses it in development. Also every cloud product for deployments is built to support them, making it hard to move on despite all the problems they come with.

As for the problems, there are many. The idea of the .env file is old, dating back to 2012 when some libraries in different programming languages had packages to work with them. They were integrated that early and never looked back. Anyway now that is our job, let's see why they are a pain and why we shouldn't use environment or app secret variables this way in 2024.

• Not decentralized. So everyone on the team working on the project should have a copy of those variables, which means if one of the team members adds a variable that other team members don't have, it can lead to unexpected outputs. The variables are not synced in any way, and there is no control over how they are defined, so this responsibility falls on the developers.

• Variables are not real data types; instead, they are all string values. This means if you want to use boolean or integer values, you need to manage those in the process, which is very complex and can easily lead to unexpected behavior and break the application.

• Not type-safe. If you are using TypeScript, by default, they come without types, so you won't know anything about their availability or the state of the types of the variables you use.

• They are unencrypted, so sharing them between team members or cloud providers in any form is very risky and can expose important variables to the public.

• They are an easy target for malware in several ways. If they are deployed to your GitHub account, they can be exposed easily. If a virus infects your computer, these files can be discovered, parsed, and stolen. Additionally, if you accidentally expose them somewhere, bots search the internet for such variables and can find and exploit them.

  
  

We can say that there have been tools to address each of these problems, but none have been stable or created a comprehensive ecosystem to solve all of them. So, clearly, the .env file presents real issues for developers and carries security risks.