Question posted in 
A member of my team has managed to create such a Dockerfile – in production:
RUN cp /var/www/.env.example /var/www/.env
as a part of Laravel v.10 production deployment.
My point is that this should not be done in production because .env.example is meant to be just an example of ENV-variables – but not their immediate source. And that such a copying – on production – must be strictly prohibited – as it confuses developers seeking the real ENV-values origin.
The official Laravel documentation states:
https://laravel.com/docs/master/configuration#environment-configuration
In a fresh Laravel installation, the root directory of your
application will contain a.env.examplefile that defines many common
environment variables. During the Laravel installation process, this
file will automatically be copied to.env.
That was the point of my team member explaining why he did that.
My point is that in production one might use only a .env.production file as an immediate source of ENV-values – but not .env.example one. I think that such a code would be OK (in production):
RUN cp /var/www/.env.production /var/www/.env
Our Laravel configuration currently does not contain a .env.production file.
I believe that copying .env.example into .env is possible only in development – but should be prohibited in production.
Who is right – me or the member of my team – and why?
UPDATE: The problem discussed does not relate to security issues, because sensitive information (like passwords) is not currently stored in our .env.example. Such information is additionally copied (from a 3-d party security storage) into .env – after it is created from .env.example.
2
Answers
You are right, and your team member’s approach has significant security concerns in a production environment. Here’s the breakdown:
Security best practices: Copying .env.example directly into .env in production exposes sensitive information like database credentials and API keys. This should be strictly avoided as it makes your application vulnerable to attacks.
Production environment separation: .env.example is intended for developers as a reference of possible environment variables. Production needs its own specific .env file with actual values, distinct from the examples.
Confusion and maintainability: Using .env.example as the source would confuse developers working in production and hinder maintaining clear configuration distinctions.
What your team should do:
Create a .env file for production: Instead of copying .env.example, configure a separate .env file containing actual values for production. This file should not be overwritten by deployments, but should be a static file, which can be manually edited.
Exclude sensitive files from version control: Never commit .env or any other files containing sensitive information to version control repositories like Git. Commit only an example .env.example file to demonstrate how it’s set up.
Consider using environment management tools: Utilize tools like Laravel Valet or Dotenv for managing environment variables securely in production.
The .env.example file is a skeleton of what data should be in the .env file. It should never have any information in it beside the name of the parameters.
Thus copying it in production is not a security issue as there are no sensible values in that file.
It only serves as a model .env file, which then you should fill depending on your environment.