git doesn't push .env file on the server
Stefan Bogdanescu
Founder & Senior Architect · 2026-06-29
# Why Git Doesn't Push Your `.env` File: A Developer's Guide to Environment Management
As developers, managing configuration files and sensitive environment variables is a daily necessity. When deploying applications, especially those built on frameworks like Laravel, ensuring that environment variables are handled securely and correctly across local development and remote servers (like Heroku) is paramount.
Many developers run into a frustrating roadblock: they commit their `.env` file, push it to Git, and expect the remote server to load those exact settings. However, as youâve experienced, you often find that while other configuration files might appear, the sensitive `.env` file seems missing or replaced by something like `.env.development`.
This post will dive deep into why this happens, what the correct workflow should be, and how to manage environment variables effectively in a Git-based deployment pipeline.
## The Core Problem: Why Environment Files Cause Friction
The issue you are facing stems not from a failure of Git itself, but from how Git manages file history and how deployment platforms like Heroku handle sensitive data versus configuration files.
When you use `git add .` and commit your `.env` file, you are telling Git to track that file. However, for security reasons, **you should almost never commit your actual application secrets** (like database passwords, API keys, or secret keys) directly into the repository.
The presence of `.env.development` instead of `.env` suggests that either:
1. Your deployment process is using a specific template or build step that defaults to environment-specific files rather than the raw committed file.
2. The deployment mechanism (Heroku, in this case) is configured to use a different method for injecting variables than simply reading the committed file directly.
## Best Practice 1: Ignoring Sensitive Files with `.gitignore`
The first and most critical step in managing environment files is to prevent them from ever entering your public repository history. This is a fundamental security practice. You achieve this by adding the `.env` file to your `.gitignore` file.
**Example `.gitignore` setup:**
```gitignore
# Environment variables - NEVER commit these!
.env
.env.*.local
# Dependency directories
/vendor
/node_modules
```
By ignoring `.env`, you ensure that your secrets remain strictly local to your development machine, protecting them from accidental exposure via Git history. This aligns perfectly with security principles taught by modern frameworks like those found on **laravelcompany.com**.
## Best Practice 2: Handling Environment Variables for Deployment
Since the sensitive variables cannot be committed, we need a strategy for deployment that injects these variables securely onto the server at runtime. This is where platform-specific environment management shines.
Instead of pushing the file itself, you should:
1. **Create a Template:** Keep a non-sensitive template file (e.g., `.env.example` or `.env.template`) that shows *which* variables your application needs.
2. **Commit the Template:** Commit this template file to Git so other developers know what variables are required.
3. **Use Platform Secrets:** Configure your deployment platform (Heroku, AWS, etc.) to handle environment variable injection separately. These platforms provide secure interfaces where you input secrets that are injected into the application's runtime environment without being stored in Git.
For Laravel applications specifically, this is managed through configuration files and environment loading mechanisms. When deploying, the server loads the variables it finds in its specific environment context rather than relying on a file that was committed with the code. If you are using Laravel, understanding how environment loading works is key to deployment success, as detailed in best practices for modern application architecture.
## Conclusion: Separation of Concerns
The discrepancy between your local Git workflow and the remote deployment result is a classic case of violating the principle of separation of concerns. Your source code (what you commit) should be separate from your configuration (the secrets).
By treating `.env` files as sensitive, non-version-controlled artifacts and instead leveraging secure environment variable management provided by your hosting service, you ensure that your deployment process is robust, secure, and predictable. Always prioritize security when handling environment variables; it saves immense headaches during deployment.