Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

okorpheus's avatar

Multiple .env files for different domain names

I’ve got a web based app used by multiple clients hosted on the same machine. In the past, each client has been a separate copy of all the source, but the only difference is the database credentials as each has their own DB. I’ve rewritten the project in Laravel. Is it possible to serve all the clients from one install of ten same laravel app and have it choose a .env file based on the domain name used to access the site?

0 likes
3 replies
LaryAI's avatar
Level 58

Yes, it is possible to serve multiple clients from a single Laravel installation and choose a different .env file based on the domain name. You can achieve this by dynamically loading the environment variables in the AppServiceProvider or a custom middleware. Here’s a step-by-step solution:

  1. Create Multiple .env Files: Create different .env files for each client, for example:

    • .env.client1
    • .env.client2
    • .env.client3
  2. Modify AppServiceProvider: In your AppServiceProvider, you can add logic to load the appropriate .env file based on the domain name.

    // app/Providers/AppServiceProvider.php
    
    namespace App\Providers;
    
    use Illuminate\Support\ServiceProvider;
    use Dotenv\Dotenv;
    
    class AppServiceProvider extends ServiceProvider
    {
        /**
         * Bootstrap any application services.
         *
         * @return void
         */
        public function boot()
        {
            $this->loadEnvironmentFromDomain();
        }
    
        /**
         * Register any application services.
         *
         * @return void
         */
        public function register()
        {
            //
        }
    
        /**
         * Load environment variables based on the domain.
         *
         * @return void
         */
        protected function loadEnvironmentFromDomain()
        {
            $domain = request()->getHost();
    
            switch ($domain) {
                case 'client1.example.com':
                    $envFile = base_path('.env.client1');
                    break;
                case 'client2.example.com':
                    $envFile = base_path('.env.client2');
                    break;
                case 'client3.example.com':
                    $envFile = base_path('.env.client3');
                    break;
                default:
                    $envFile = base_path('.env');
                    break;
            }
    
            if (file_exists($envFile)) {
                $dotenv = Dotenv::createImmutable(base_path(), $envFile);
                $dotenv->load();
            }
        }
    }
    
  3. Update config/app.php: Ensure that the AppServiceProvider is registered in your config/app.php file.

    'providers' => [
        // Other Service Providers
    
        App\Providers\AppServiceProvider::class,
    ],
    
  4. Clear Configuration Cache: If you have configuration caching enabled, you need to clear it to ensure the changes take effect.

    php artisan config:clear
    
  5. Test Your Application: Access your application using different domain names and verify that the correct environment variables are loaded.

By following these steps, you can dynamically load different .env files based on the domain name, allowing you to serve multiple clients from a single Laravel installation.

Snapey's avatar

Its certainly not a good idea to use different env files for each client.

For starters, you will not be able to config cache which is the loss of a good performance optimisation

What you have is typical of a multi-tenant application. You should look at one of the packages that supports database per client. Basically you have a master database that hold all the data for each your clients (eg domain name, database credentials, email details etc etc). This database is then used to switch each request to the client specific database.

eg https://tenancyforlaravel.com/

okorpheus's avatar

@Snapey Thank you for the feedback. I was still wondering if my idea was a good one even if doable. I'll look into tenancy, it looks like that might be the right solution.

Please or to participate in this conversation.