Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
You can have multiple .env files in your project and use your own logic to determine which one out of them Laravel will load when bootstrapping. That’s not what I’m asking about here.
About 95% of my .env settings are usually identical for my local and production environments, but a few are environment-specific. Making any changes to common settings requires making the same changes in all environments separately.
It would be very useful to have a base .env file for the common settings and additionally an .env.[environment] file for each environment for the environment-specific settings. With encryption, you could add the base file to your SVN so that changes propagate automatically, without affecting the environment-specific settings.
But from everything I can find online, this is just not possible. You can load either a generic .env file or an environment-specific .env.[environment] file, but never both.
Is this correct? Is there really no way to tell Laravel to load and combine several .env files while bootstrapping, making the settings in all of them available to use in config files?
(This is annoying me particularly right at the moment, since I’m working on a project that will be hosted on a shared host with no access except via FTP, so every time I change an environment setting, I have to either (a) change all the production-specific settings to their production values, save, upload, and then change them back to their local-specific values; or (b) have completely separate .env files for local and production, and then remember to change the setting in both .env files and upload the production one to the server. Both options are annoying.)
I got this working by adding to AppServiceProvider class (Laravel 12.19):
use Dotenv\Dotenv;
use Illuminate\Support\Env;
public function boot (): void
{
// ...
Dotenv::create(Env::getRepository(), base_path(), '.env.' . app()->environment())->load();
}
Now I have .env:
APP_ENV=local
TEST_PARAM=AAA
And .env.local:
TEST_PARAM=BBB
Tinker shows proper results:
> env('TEST_PARAM')
= "BBB"
// if I remove TEST_PARAM from .env.local file
> env('TEST_PARAM')
= "AAA"
@Glukinho Aha! I didn’t realise you could simply add and load an .env after bootstrapping is done – that is very useful, will definitely try this.
@Glukinho how would this interact with cached configs?
@krisi_gjika Unfortunately it doesn't, so this solution is not suitable in most cases :(
Can you propose better way? I find the idea of having "inherited" env files (common .env file + more specific .env.[APP_ENV] file) useful, but I don't have enough knowledge in Laravel internal bootstrapping to organize it properly.
@Glukinho I think it might be simpler to have a bash script or smth similar that builds 1 .env from various sources, and you can run it on deploy or when you do changes to your env(s)
@kokoshneta No, because it completely defeats the purpose of .env files, which are meant to emulate environment variables on a server in environments where it’s difficult to set (i.e. your local development machine where you may be running multiple projects).
@martinbean I don’t see how having multiple environment files would defeat the purpose of that. ‘Environment’ is not a well-defined term, and there are at least two levels of environment that are present in Laravel’s default .env files: the project environment and the server environment.
You can have multiple projects running on the same server, which can be either a local development machine or a ‘real’ server (staging, production, etc.).
Some environment variables will be specific to the project regardless of the server running it (project name and version, app key, primary and fallback locales, etc.); others will be determined by the server regardless of the project (database host and port, for example); and yet others will depend on the combination of project and server (e.g., using Mailtrap on development machine in all projects, but Mailchimp on the server in one project and Sendgrid in another).
Being able to load or combine .env files to match these different combinations of real-time environments in no way defeats the purpose of .env files to my mind. The fact that loading multiple files is supported and documented in Dotenv itself also indicates that Scott Motte doesn’t consider it against the purpose either.
Please or to participate in this conversation.