No. The Laravel documentation says the .env file should not be committed to source control, because anyone who gains access to the repository would get your credentials. Commit .env.example with placeholder values instead, or use Laravel's built-in environment file encryption if you must store it.
What the file holds
A default .env carries your APP_KEY, database credentials, mail and cache settings, and whatever API keys you add. The framework reads these values into configuration through the env function. Anything in .env can also be overridden by real server or system environment variables, which is the preferred place for production values.
The docs give two reasons not to commit it. Each developer and server may need different settings. And a repository leak, a compromised developer laptop or a forked public copy would expose live secrets.
Three safe patterns
| Pattern | How it works | Good for |
|---|---|---|
.env.example committed, real .env per machine | Placeholders in Git, secrets set locally | Most teams |
| Platform environment variables | Secrets injected by the host or CI | Production |
| Encrypted environment file | Laravel encrypts the file so it can sit in Git | Teams that want versioned config |
The documentation notes that encrypted environment files may be placed in source control safely. The encryption key then becomes the secret to protect, so keep that outside the repository.
If a .env was already committed
Deleting the file in a new commit does not remove it from history. Treat the secrets as exposed.
- Rotate every credential in the file. Start with database users, third party API keys and the
APP_KEY. - For the
APP_KEY, use the graceful rotation described in our post on rotating it. - Add
.envto.gitignoreif it is not there. - Remove the file from history with your Git host's recommended tool, then ask collaborators to re-clone.
- Check whether the repository was ever public or forked.
- Search logs of the affected services for use of the old credentials.
Rotation is the real fix. Rewriting history only reduces future exposure.
Prevent a repeat
- Keep
.envin.gitignorefrom the first commit. - Add a pre-commit or CI check that fails if a file named
.envappears in a pull request. - Keep
.env.examplefree of real values, and review it like code. - Make sure the web server document root is
public, so.envis never reachable by URL.
A note on the web root
Laravel's default layout puts only the public directory behind the web server. Pointing the server at the project root would make files like .env fetchable. If you ever see a request for .env in your access logs, that is a bot looking for exactly this mistake.
Quick check
Is .env.example safe to commit?
Yes, as long as it contains placeholders only. The docs recommend it so teammates can see which variables are required.
Does encrypting the env file make committing it fine?
The docs say encrypted files may be placed in source control safely. Protect the decryption key separately.
Safeguard's asset discovery and compliance evidence automation can help you keep track of where your applications and their configuration live. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
