.env file in production

@jlrdw Yes but the .env file is not publicly accessible. That's why I don't really understand why it shouldn't be used in production.

@vincent15000 it was never meant for production, but development. But yes it can be secure only if main laravel is put at least one level higher out of any web folder. Think about it a bot can read text files when in a web folder.

@jlrdw Of course we use .env files in a production environment. That's the entire point of them: to offer environment-specific settings and keys. Every production Laravel app will have its own .env file.

This is a case where the AI reply should be marked as "Not Helpful."

@jlrdw But the config folder is at the same lever as the .env file, so according to what you say it is readable by a bot ?

@JeffreyWay I can't see any "Not Helpful" button or option.

Even in the three-dots menu, it only says report spam. Maybe it is a light-theme issue?

By the way, best answers are illegible when they get the blue background on light theme.

@rodrigo.pedra I think its only for the OP. I saw it on my question.

@webrobert ah ok! This makes sense. Thanks for the "quick draw" response =)

@rodrigo.pedra I can't see the Not helpful button. I have checked on my own posts. Nothing for me. Just the usual Set best answer button.

@JeffreyWay originally it was for development only and later it changed, came from ruby which states:

Can I use dotenv in production? dotenv was originally created to load configuration variables into ENV in development. There are typically better ways to manage configuration in production environments - such as /etc/environment managed by Puppet or Chef, heroku config, etc.

However, some find dotenv to be a convenient way to configure Rails applications in staging and production environments, and you can do that by defining environment-specific files like .env.production or .env.test.

Before Graham Campbell took over that site the original author stated the same thing, so I have always gone by what the original authors intent was.

If others want to put it in shared hosting the wrong way so that the credentials are exposed that's their business not mine, but on places like digital ocean yes it is safe.

Honest not trying to argue but I've been using laravel since the early days and happened to remember the original intent of that file. And I don't understand why Graham Campbell changed the wording in the readme.

@rodrigo.pedra you have been around long enough also to know the original authors vulcus .env readme clearly stated it is meant for development only.

The readme changed when Graham Campbell took over.

This file came from the idea from Ruby and their readme still States this.

https://github.com/bkeepers/dotenv

https://laracasts.com/discuss/channels/laravel/should-we-use-the-env-file-in-production-as-well-and-how-to-protect-it

In my opinion the AI is right and wrong, a .env file is only secure when main laravel is not placed in a web folder.

@jlrdw , you are right. I didn't consider a shared hosting setup.

On the last few years I've been working only with cloud hosting, such as AWS, Azure, and the such. And as you said on these places there it is safe to use, I would add that it is also easier.

Maybe this laziness of mine made me forget of shared hosting, it is easy to get used to good stuff =)

Thanks for the heads-up!

@cwhite it is still meant for development only, Graham Campbell took this part out. The readme clearly states it came from Ruby and ruby has not taken that part out.

The original, which I found:

Usage Notes

When a new developer clones your codebase, they will have an additional one-time step to manually copy the .env.example file to .env and fill-in their own values (or get any sensitive values from a project co-worker).

phpdotenv is made for development environments, and generally should not be used in production. In production, the actual environment variables should be set so that there is no overhead of loading the .env file on each request. This can be achieved via an automated deployment process with tools like Vagrant, chef, or Puppet, or can be set manually with cloud hosts like Pagodabox and Heroku.

I am not trying to argue with anyone, but especially in shared host where some people setup laravel following some youtube video, and expose their environment, that's not good.

Main laravel should not be in a web folder, but somewhere else in the file system. But I agree it is secure if and only if laravel is correctly setup.

@jlrdw Properly securing your .env file in a shared host environment is a different conversation in my opinion. But it's incorrect to say that you shouldn't create an .env file for production. Folks can set them however they wish, but it's an incredibly common practice for Laravel apps.

• https://forge.laravel.com/docs/1.0/sites/deployments.html#environments
• https://laravel.com/docs/10.x/configuration#environment-configuration

@JeffreyWay I definitely agree, I'm just trying to tell people to make sure they are secure if they are used.

@jlrdw There is no reason that the env cannot be secure in a shared hosting environment, its just that the advice from the hosting company states "put your website in the public_html folder" which beginners blindly follow, exposing all their credentials

Those same users would be completely clueless if you said that they must create actual environment variables and most would also be limited by what cpanel (etc) allows them to do.

I think perhaps the framework itself ought to check and throw an exception if it finds .env in a publicly accessible location.

@saurabhd no this is not correct. The variables eg APP_URL can just as easily be read from actual server attributes such as those to you can set in .htaccess file. The .env file is not mandatory its just the easiest way for most folks.