Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
Hi!
I'm in the middle of changing my dev environment from Laragon to Laravel Sail.
However, when accessing 127.0.0.1 it takes a good time for the browser to even respond with some data.
Any ideas that could improve the response time?
@foks maybe your laptop/pc is not really capable of running Docker alone? (assuming you're on Windows)
If you are on Mac, I highly recommend you use Valet instead.
Also, is running Sail and Docker necessary for you? Are there any services you need that you can only run on Sail/Docker?
I want to emulate my production environment, where I use Horizon. That's why I'd like to use Docker.
My laptop, which I'm currently on has 8Gb ram, and a 300GB SSD? Personally, I would like the laptop to have more ram.
@foks I'm running on a 32GB memory Macbook Pro and still Docker eats a lot of resources.
How about Laragon?
@neilstee I used Laragon before switching to Laravel Sail. My reason for switching is that I need to run horizon, as it's used in my production environment.
@foks is this a brand new Laravel project with fresh Horizon install? Or an existing project you are trying to run on Sail?
If that's a fresh/clean install of everything and still slow, then your machine can't really handle it.
Also, have you tried installing WSL2? I see some threads that recommend using it for running Sail although I'm not familiar with it since I'm using Mac.
If you really need the horizon badly, consider installing Linux on your machine. Good luck!
Also, have you tried installing WSL2? I see some threads that recommend using it for running Sail although I'm not familiar with it since I'm using Mac
@neilstee I'm running WSL2. It's an existing project that I'm trying to run with Sail.
I don't need it badly, but I'd prefer to make sure that everything works with Horizon before I deploy the new update.
@foks try installing a fresh Laravel and Horizon and see if it still occurs.
My point is that maybe your existing project is causing it to slow.
But if a fresh install of Laravel and Horizon still an issue then your machine is not capable of running it.
I don't need it badly, but I'd prefer to make sure that everything works with Horizon before I deploy the new update.
Then I guess it's okay that it is slow? As long as it works and you know that the cause of slowness is your machine?
Or the slowness is causing an issue on the Horizon part?
Then I guess it's okay that it is slow? As long as it works and you know that the cause of slowness is your machine? Or the slowness is causing an issue on the Horizon part?
I haven't seen any issues with Horizon due to the slowness. (It's just annoying that it is slow)
I'll try with a fresh Laravel & Horizon install and report back.
Have you tried Laradock?
I haven't.
In my project I added opcache and it is running just like having the LAMP stack installed locally on my machine.
My docker has 4 CPUs and 3Gb of memory.
This was the tutorial that I used.
So I found out that it was the "bridge" that WSL2 uses to link Ubuntu. So what I ended up doing was moving the project into /home/<user>/<projectname> and then chmod the directory, and then Laravel Sail has fast responses.
@Foks tnks bro. you save my life after 2 days! ❤️
This is a follow-on from the @foks selected answer, and is just as much a note for future me as anything.
By using /home/<user>/<projectname> the project is entirely in the VM. You can access the files from Windows at \\wsl$\{your-vm-name} but I'm guessing that will be fairly slow, especially when indexing. I think VS Code has an alternative way to connect that should be faster (maybe it can ssh into the VM and not use mounted filesystems at all).
From within the installed VM project area, you can run Windows commands, so finding the Windows directory for the current directory can be done by issuing:
explorer.exe .
For me, this brings up Explorer with \\wsl$\Ubuntu-18.04\home\adminuser displayed.
A downside seems to be that files changed by the application within the VM do not have events fired back to Windows. So you could run composer update and your VS Code or PHPStorm will not see the vendor directory updates without reloading the directories, and then there is a slow indexing to deal with again. For example, I can touch xxx in the VM, and the Explorer window showing that directory does not see the xxx file until I F5 refresh.
I am personally uncomfortable keeping all my work files inside the VM filesystem - just seems risky for something that is potentially very ethemeral. However, for speed, it is really zippy.
Update: from /home/<user>/<projectname> you can use the command:
code .
and up pops VS Code connected to that application work area as a remote connection. Connecting like that, it sets up watchers on the filesystem, so it does instantly see any file changes. Of course, you are not out of the woods yet, and some work is needed to make sure VS Code uses the correct version of PHP to do its syntax checking. That will be the PHP CLI version running in sail and not the version running in the Ubuntu VM (yes, it's VM turtles all the way down). I think a shell script in your project to wrap vendor/bin/sail php and telling VS Code to run that for all syntax checking, is to way to go.
I'm not sure what the equivalent for PHP Storm is.
I think you can have fast run-time access to files, so the app runs quickly. Or you have fast development access to files, so they are indexed quickly in your editor (if you have to access files via a shared filesystem). But it seems you cannot have both with WSL2. I hope I'm wrong, and there is a way around this.
By default, opcache is not enabled in Docker. Add in dockerfile:
RUN docker-php-ext-install opcache COPY ./opcache.ini /usr/local/etc/php/conf.d/opcache.ini
Create file opcache.ini:
[opcache] opcache.enable=1 ; 0 means it will check on every request ; 0 is irrelevant if opcache.validate_timestamps=0 which is desirable in production opcache.revalidate_freq=0 opcache.validate_timestamps=1 opcache.max_accelerated_files=10000 opcache.memory_consumption=192 opcache.max_wasted_percentage=10 opcache.interned_strings_buffer=16 opcache.fast_shutdown=1
Please or to participate in this conversation.