Why you should use nginx instead of apache for laragon.
I am using Laragon with several local Laravel Apps. There are lots of API Reqeusts between those apps.
Using Apache there is following problem:
If App1 makes (within a normal browser triggered request) an http request to the API of App2, than App2 gets the Environment Variables of App1!
(This is not a Laragon specific problem, it is a combination of Not Thread Safe Apache for Windows and the a Laragon component handling .env Variables )
It is possible to set your Env Variables in your Apache vhost config eg
#laravel hack SetEnv DB_DATABASE xyz
don't forget to remove the variables from your .env file
Use Nginx as Webserver - if so don't forget to check that your usr/laragon.ini contains
Upstream=2 (or higher)
The problem with nginx, is that a lot of servers still use apache, and when I have to develop apps to use later in a real environment, i need my local .htaccess to work.
There are solutions out there that have a stack of nginx with apache to run nginx and still honor the .htaccess file, but I dont know how to do this with laragon.
With this i just want to say that sometimes the option to use nginx is simply not there.
For your local Development Environment:
As mentioned above you can set your Laravel ENV variables in your Apache Vhost instead:
SetEnv DB_DATABASE xyz
SetEnv DB_NAME testdatabase
and remove those Variables from your local Laravel .env file
This way the problem with mixed up environment Variables does not occur on windows based Apache Servers. All changes are made in your local .env files - so this doesn't break your staging and production environments.
@peterreb : Did you test with PHP NTS (Non Thread Safe)?
When using PHP NTS, Laragon will use Apache mod_cgi instead.
@leokhoa I have had this problem with UwAmp and PHP NTS. That was the reason I changed to Laragon in the first place
I had a similar problem using two Laravel applications, where the main application was trying to find a table that actually belonged to the API. Both applications were separated with separate virtualhost, so the solution I found was to set up the database connection in database.php and remove from .env. Problem solved.