“Securing Secrets: Deploying .env Files in Production Without Compromising GitHub”

In this post, we will discuss a robust strategy for using .env files in your production environment without exposing sensitive information on your GitHub repository. Discover secure ways to protect your application’s secrets and configuration variables, while ensuring a flexible and reliable deployment process. Learn how to strike the right balance between efficiency and security while strengthening your project against potential vulnerabilities.

As we know, storing .env files directly in GitHub repository is considered bad practice. Yesterday, I brainstormed a solution to this problem and found a way to store our .env files directly on the server. You may be wondering what happens when new code is committed to the repository? Won’t this replace the old code and .env file?

Actually, it will, but instead of keeping the .env file in the main code, we can store it in a different location. For example, if Jenkins is used for CI/CD, there will be a folder named “Jenkins” on the server and inside it, a “Workspace” folder will be available. When new code is pushed to the repository, Jenkins replaces the code in the workspace. To avoid overwriting the .env file, we create a file with any desired name inside the Jenkins folder.

Key point: Store the file in the Jenkins folder, not on the workspace.

This approach eliminates the need to repeat the process every time new code is pushed to the repository. By saving the file inside Jenkins and providing the file path to Docker or docker-compose (whichever you use), you ensure a secure and streamlined process for managing your application’s secrets.