The mistake you absolutely must not make in a public Git repository

NicolasBrondinBernard

Author
@NicolasBrondinBernard

You wouldn't give out your password on Twitter, would you? So why do it on Github?

Article published on 21/12/2020, last updated on 10/08/2026

Recently, I helped a beginner developer who didn't understand why his host had blocked his SMTP access and why he was receiving dozens of emails with "delivery failure, wrong recipient" for messages he had not sent.

After ruling out a few possibilities, I made him understand that he had accidentally pushed his configuration file to his public Git repository, which contained the login credentials to his SMTP server.

If you think this practice is rare, let me tell you that I've seen it happen many times, whether among beginners due to lack of understanding, or among more experienced developers due to a moment of carelessness.

It's such a common mistake that many malicious bots constantly scan public Github repositories looking for an API key, a login, or a password in configuration files or directly in the code.

To counter these bots, some cloud hosting providers (notably AWS) use their own bot to track down these publicly exposed keys in order to disable them and avoid any unpleasant surprises for their users.

Best practices

The solution to avoid any mishap with your configuration data is called "environment variables".

Environment variables are variables just like in programming, but instead of being accessible by a single piece of software, they are available globally to the entire operating system.

The idea behind all this is to never share these configuration variables between your different environments (local, dev, production, etc.), and especially not in your Git repository.

Access to an environment variable will depend on the language you're using, for example in Javascript (NodeJS), you'll need to use "process.env.MY_VARIABLE" while in PHP you'll use "getenv('MY_VARIABLE')".

But before using an environment variable, you'll need to initialize it, and for that we have two solutions:

Host configuration

More and more cloud hosting providers offer the ability to configure environment variables directly from the application's admin panel, this is notably the case for AWS, Heroku, Clever Cloud and many others...

If your host offers this solution, I strongly recommend using it, as it is the most secure approach. No file to move or copy, and once these variables are set, you don't need to touch them again, they'll always be there for all your deployments.

The dotenv library

I recommend using this library either for your local development environment, or if your host doesn't offer environment variable management in the admin panel.

"dotenv" allows you to inject environment variables directly from a standardized declaration file (.env), which makes it possible to abstract away the operating system (Windows has a different syntax for initializing an environment variable).

But then isn't there a risk of adding this file to the Github repository?

This file must absolutely stay out of your commits, even if your repository is private (it's safer), and ideally you should deploy it yourself on each deployment environment without going through Git.

To make sure it's excluded from the Git repository, I suggest simply adding .env to your .gitignore file, this way Git won't even see that this file exists!


Olivier Guillard sur Unsplash

Finished reading this article?
Our complete courses
Take it to the next level with our courses!

Complete courses, exercises and certificates to really learn programming!

4.8 average rating

Comments (0)

to leave a comment

No comments yet