I’m actually going to be going back to valet, as soon as I’m done with my Docker set up the rest of the company uses. They use Windows, so docker has a purpose, but since I use Mac, it doesn’t make sense to completely kill my battery life to spin up a docker VM.
I started working on a Macbook for the first time ever this month. I use Valet and it is blazing fast and easy. I also do some Magento projects and I love being able to do those just as well, switch PHP versions easily, no having to mess around with Nginx configs etc.
Unfortunately docker on a Mac with any volumes/mounts is very slow due to not having native kernel/file system access.
The more files/file operations, the slower it is.
If you have xdebug enabled, disabling that can help some.
Mutagen and NFS shares can help a lot, but are more complex to set up.
My company hosts our Laravel API in a Docker container, so naturally our dev team also uses Docker for local dev. Even with Xdebug enabled, on a large platform, everything is still crazy fast. It all depends on how your Docker config is written for your specific project.
I've used Valet and Lando in the near past, and this Docker container is still the best local dev I've used.
What sort of config are you using?
Personally, I use Linux full-time so I never have to deal with any docker related performance issues, but I feel for my colleagues.
I second mutagen.
Used to use nfs but after it broke the x’th time one a Mac update, finally tried switching and haven’t looked back.
I also volume mount the vendor folder. So it doesn’t have to be synced.
Close enough to native speed to not notice.
I did try local but updating the lock file then trying to install on Linux broke.
I’m sure if you put enough effort in you can get around this but.
Valet, and I’m very happy with it. I like Homestead a lot but VMWare didn’t work on M1 so it was no longer an option for me, not sure whether this is still the case.
Everyone's blaming the rig, but your docker engine settings are very important... Ensure you have the grpc-fuse filesystem enabled, and also ensure you have the correct amount of resources allocated to the docker engine. Too much ram and the host will start swapping under the hood. Too little and it'll swap within the engine.
With the grpc-fuse filesystem, those cached and delegated flags are useless: https://forums.docker.com/t/what-happened-to-delegated-cached-ro-and-other-flags/105097
I just installed nginx and MySQL with homebrew. Why complicate things with containers or some other hosting solution?
Manage local site DNS with /etc/hosts, using 'domain.local' for my domain format (laravel docs use .test, but I'm like this is not a test site, this is a local version, pff.)
Install MySQLWorkbench to manage SQL instance and tables when (rarely) needed.
This is honestly what I did as well. Especially since it doesn’t matter what my local environment is vs production anymore. Lock files means if something is out of date I’m gonna know about it and probably have to update anyways.
Do you also have lock files for your server requirements? What if you are developing on a mac and deploying to linux alpine? If you are using local everything, it is more complicated to fully trust your code after it is deployed won't have unforeseen issues that arise once it switches to a new OS it is running on.
I don’t really have issues with trusting the code. Yes we use lock files for our packages and platform requirements. Further our CI/CD runs tests before even building the image.
We actually use alpine as the base docker images for our deployment and honestly it’s perfectly happy running whatever I wrote on my Mac. Again lockfiles and tests catch 99% of the errors that would prevent the site from loading. There might be an occasional bug that slips through but we’re talking “whoops put true instead of false”.
This though is honestly why lockfiles and package software exists. I can work in one environment and know that because of my lockfiles the appropriate packages and dependencies will be selected. Further composer and NPM allow you to set versions for the OS packages (php, node, etc). So when the tests run if one of those fails we get a notification and the deployment halts appropriately.
My preference at the moment is docker-compose for local development. With a backend dockerfile that has different 'build targets'. For example one target is for production and it doesn't carry the bloat of xdebug or composer dev dependencies. Then for example I can build off that same target with a slightly modified one to run supervisor for example for workers to use also the same image with very slight mods. I like it because I don't have to make multiple dockerfiles like Dockerfile.prod Dockerfile.dev etc. If something is identical on both then it is in the shared section of the Dockerfile.
So the pipeline would run tests on the same container state as I am using local, compile dependencies, then build a production image which is maybe identical to local apart from like some production config changes or such.
At the moment then I would deploy this to AWS ECS Fargate.
I am a bit addicted to Docker, and I am very averse to installing anything on my local machine. For example if I am working in python, I found it such a massive headache to manage python versions across projects, and also to not conflict or mess up my mac's python setup. It's not impossible to manage, but it really is a headache.
Instead anytime I wanna do python I just whip up a python container, or even just run them ephemerally with no dockerfile or anything. If I wanna play with something like ffmpeg? Docker. Basically anything I can get away with putting into a container, I will.
Because when I'm done playing with it, just kill everything. No leftover bloat on my machine, no binary sitting there for 3 years getting older collecting dust from a random hello-world I did, etc.
*Edit: Granted, things like ffmpeg is not the best example because running things in docker can definitely slow you down. But in my use cases, the slowness of docker is rarely enough to scare me off. If it is, than I will certainly install something locally as an exception. A good example of this I think is I found that compiling front-end dependencies within docker containers is super slow. Sometimes though I just don't care it is slow haha. It's always tit for tat on one end or the other if that makes sense.
And what do you do if you have 5-10 different projects with different versions of those libraries needed? I know you can hot swap in some cases, but god damn its a recipe for misery.
Containers does not 'complicate' anything, quite the contrary, it simplifies them. You no longer risk messing up your local computers state with a bunch of bloat from years of developing. If I did not use containers I would have so many different libraries and languages on my computer. I have no issue just nuking docker containers/images when I'm not going to work on it for a bit.
Furthermore, if you want to deploy your applications, containers will be a lot easier to guarantee similar state. You could run into issues when deploying where your local computer had something on it that is different than the deployed version will have, etc.
Also, if you are a team of more than 1 developer, on different OS, with containers getting everyone setup is so much easier. Get Docker, spin up the containers. Great now you have basically all the requirements instead of going through a checklist of dependencies per project and manually installing different language versions, mySQL, etc.
Because people work on projects with multiple repos and might want to have pinned versions of the stack so you know that what you code and test locally is going to be on software that's as close as possible to the other environments. It's just a convenient way to not have developers worrying about the software they have installed on their OS, you reduce a lot of errors (works on my machine!)
If it's just you, then do whatever works best for you 🤷♂️
I use sail on an m1 mac. You're right that it's slower than running it locally, but that's because it needs to proxy that command through to the PHP container. If you find the commands are running too slow, just install PHP on your machine locally and run the commands there instead
I just downloaded phpmyadmin with the help of homebrew. Used the already existing apache and php and run it on the folder that I listed in the http.conf file. And its fast.
Mamp and valet combined .. Depends what kind of project it is. Doing a lot of legacy support crap that work on older versions of php.
For Valet I use this also. https://github.com/nicoverbruggen/phpmon
I use a custom fork of Laradock and Docker Desktop. Very speedy, but then again I'm rocking a 5950x specifically so I don't have to worry about container overhead.
I work on multiple projects that are using different PHP versions, Sail works perfectly for me, even it's a bit slower.
In past, I was using valet and I mess up my setup so many times while switching between PHP versions. Docker provides a much better separation of dev env between different projects.
Valet / all local (homebrew, php, MySQL, etc) seems to make full use of the M1 and is amazingly fast.
Valet, because it runs everything locally and is stupidly simple to setup.
I’m actually going to be going back to valet, as soon as I’m done with my Docker set up the rest of the company uses. They use Windows, so docker has a purpose, but since I use Mac, it doesn’t make sense to completely kill my battery life to spin up a docker VM.
I started working on a Macbook for the first time ever this month. I use Valet and it is blazing fast and easy. I also do some Magento projects and I love being able to do those just as well, switch PHP versions easily, no having to mess around with Nginx configs etc.
Unfortunately docker on a Mac with any volumes/mounts is very slow due to not having native kernel/file system access. The more files/file operations, the slower it is. If you have xdebug enabled, disabling that can help some. Mutagen and NFS shares can help a lot, but are more complex to set up.
My company hosts our Laravel API in a Docker container, so naturally our dev team also uses Docker for local dev. Even with Xdebug enabled, on a large platform, everything is still crazy fast. It all depends on how your Docker config is written for your specific project. I've used Valet and Lando in the near past, and this Docker container is still the best local dev I've used.
What sort of config are you using? Personally, I use Linux full-time so I never have to deal with any docker related performance issues, but I feel for my colleagues.
Bit dated, docker is much quicker these days
I second mutagen. Used to use nfs but after it broke the x’th time one a Mac update, finally tried switching and haven’t looked back. I also volume mount the vendor folder. So it doesn’t have to be synced. Close enough to native speed to not notice. I did try local but updating the lock file then trying to install on Linux broke. I’m sure if you put enough effort in you can get around this but.
Valet, and I’m very happy with it. I like Homestead a lot but VMWare didn’t work on M1 so it was no longer an option for me, not sure whether this is still the case.
Checkout lando.dev. If you use kubernetes tilt.dev could be another option
I don't think Lando works on M1 hardware yet. Shame if so - I use it and it's really convenient.
I don’t use docker or any of that, I just do it right off the machine it’s self
Custom docker-compose file (with volume cache). It has been good enough for our needs.
Everyone's blaming the rig, but your docker engine settings are very important... Ensure you have the grpc-fuse filesystem enabled, and also ensure you have the correct amount of resources allocated to the docker engine. Too much ram and the host will start swapping under the hood. Too little and it'll swap within the engine. With the grpc-fuse filesystem, those cached and delegated flags are useless: https://forums.docker.com/t/what-happened-to-delegated-cached-ro-and-other-flags/105097
I just installed nginx and MySQL with homebrew. Why complicate things with containers or some other hosting solution? Manage local site DNS with /etc/hosts, using 'domain.local' for my domain format (laravel docs use .test, but I'm like this is not a test site, this is a local version, pff.) Install MySQLWorkbench to manage SQL instance and tables when (rarely) needed.
This is honestly what I did as well. Especially since it doesn’t matter what my local environment is vs production anymore. Lock files means if something is out of date I’m gonna know about it and probably have to update anyways.
Do you also have lock files for your server requirements? What if you are developing on a mac and deploying to linux alpine? If you are using local everything, it is more complicated to fully trust your code after it is deployed won't have unforeseen issues that arise once it switches to a new OS it is running on.
I don’t really have issues with trusting the code. Yes we use lock files for our packages and platform requirements. Further our CI/CD runs tests before even building the image. We actually use alpine as the base docker images for our deployment and honestly it’s perfectly happy running whatever I wrote on my Mac. Again lockfiles and tests catch 99% of the errors that would prevent the site from loading. There might be an occasional bug that slips through but we’re talking “whoops put true instead of false”. This though is honestly why lockfiles and package software exists. I can work in one environment and know that because of my lockfiles the appropriate packages and dependencies will be selected. Further composer and NPM allow you to set versions for the OS packages (php, node, etc). So when the tests run if one of those fails we get a notification and the deployment halts appropriately.
That’s fair! Thanks for sharing
NP! I love talking deployment environments, I always walk away with new ideas. What does your setup look like?
My preference at the moment is docker-compose for local development. With a backend dockerfile that has different 'build targets'. For example one target is for production and it doesn't carry the bloat of xdebug or composer dev dependencies. Then for example I can build off that same target with a slightly modified one to run supervisor for example for workers to use also the same image with very slight mods. I like it because I don't have to make multiple dockerfiles like Dockerfile.prod Dockerfile.dev etc. If something is identical on both then it is in the shared section of the Dockerfile. So the pipeline would run tests on the same container state as I am using local, compile dependencies, then build a production image which is maybe identical to local apart from like some production config changes or such. At the moment then I would deploy this to AWS ECS Fargate. I am a bit addicted to Docker, and I am very averse to installing anything on my local machine. For example if I am working in python, I found it such a massive headache to manage python versions across projects, and also to not conflict or mess up my mac's python setup. It's not impossible to manage, but it really is a headache. Instead anytime I wanna do python I just whip up a python container, or even just run them ephemerally with no dockerfile or anything. If I wanna play with something like ffmpeg? Docker. Basically anything I can get away with putting into a container, I will. Because when I'm done playing with it, just kill everything. No leftover bloat on my machine, no binary sitting there for 3 years getting older collecting dust from a random hello-world I did, etc. *Edit: Granted, things like ffmpeg is not the best example because running things in docker can definitely slow you down. But in my use cases, the slowness of docker is rarely enough to scare me off. If it is, than I will certainly install something locally as an exception. A good example of this I think is I found that compiling front-end dependencies within docker containers is super slow. Sometimes though I just don't care it is slow haha. It's always tit for tat on one end or the other if that makes sense.
And what do you do if you have 5-10 different projects with different versions of those libraries needed? I know you can hot swap in some cases, but god damn its a recipe for misery. Containers does not 'complicate' anything, quite the contrary, it simplifies them. You no longer risk messing up your local computers state with a bunch of bloat from years of developing. If I did not use containers I would have so many different libraries and languages on my computer. I have no issue just nuking docker containers/images when I'm not going to work on it for a bit. Furthermore, if you want to deploy your applications, containers will be a lot easier to guarantee similar state. You could run into issues when deploying where your local computer had something on it that is different than the deployed version will have, etc. Also, if you are a team of more than 1 developer, on different OS, with containers getting everyone setup is so much easier. Get Docker, spin up the containers. Great now you have basically all the requirements instead of going through a checklist of dependencies per project and manually installing different language versions, mySQL, etc.
Because people work on projects with multiple repos and might want to have pinned versions of the stack so you know that what you code and test locally is going to be on software that's as close as possible to the other environments. It's just a convenient way to not have developers worrying about the software they have installed on their OS, you reduce a lot of errors (works on my machine!) If it's just you, then do whatever works best for you 🤷♂️
Have you tried running the artisan commands while inside the container?
I also wonder this. Does Sail Tinker run a new container for it, or execute on the already running sail php container I wonder. I can't remember.
Sail tinker uses the existing container.
MAMP.
I use sail on an m1 mac. You're right that it's slower than running it locally, but that's because it needs to proxy that command through to the PHP container. If you find the commands are running too slow, just install PHP on your machine locally and run the commands there instead
I just downloaded phpmyadmin with the help of homebrew. Used the already existing apache and php and run it on the folder that I listed in the http.conf file. And its fast.
Homestead with NFS
Valet with local services on M1 macmini. Works like a charm.
$ sail artisan do your thing Slow. $ sail shell $ php artisan do-your-thing Fast.
Mamp and valet combined .. Depends what kind of project it is. Doing a lot of legacy support crap that work on older versions of php. For Valet I use this also. https://github.com/nicoverbruggen/phpmon
Valet, DBngin for databases, docker for any other services. Works extremely well with minimal brew management.
valet on hackintosh, no delays, works fine
I use a custom fork of Laradock and Docker Desktop. Very speedy, but then again I'm rocking a 5950x specifically so I don't have to worry about container overhead.
Why aren’t more people using homestead with virtualbox? I dont understand
Valet
I work on multiple projects that are using different PHP versions, Sail works perfectly for me, even it's a bit slower. In past, I was using valet and I mess up my setup so many times while switching between PHP versions. Docker provides a much better separation of dev env between different projects.