[3.x] Laravel Sail "quick setup" + Multi-Stage Deployment strategy #262
Replies: 4 comments 6 replies
-
|
Thank you very much for submitting this! I'll definitely review this and tee this up to get into the docs once I get through Spin. Thanks again for all your efforts! |
Beta Was this translation helpful? Give feedback.
-
|
@iksaku I should change the target in docker-composer for use development stage right? |
Beta Was this translation helpful? Give feedback.
-
|
I'm using Laravel Jetstream with Inertia, when I run on production it show error "vite manifest not found" while I already defined npm run build on Dockerfile, any idea how to fix it? |
Beta Was this translation helpful? Give feedback.
-
✅ Huge UpdateIn v4, we redid the entire docs site. We now have a "Quick Start" example as well as a guide on how to go from Development to Production 🚀 |
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
While Laravel Sail provides its own set of runtimes, it is fairly easy to also use with the new v3.x images.
Setup is pretty quick and doesn't need the developer to blow their project with files, nor give up customization. Below are the steps I used:
1. The
DockerfileWe'll need to create a
Dockerfile, which can be placed inside thedocker/directory that sail creates by default, or even in the root of the project. We'll pull theserversideup/phpimage we prefer and create asailuser for the container:Tip
Check out the man page for
useradd: https://linux.die.net/man/8/useraddIf using Alpine, we need to install
bashas it is the shell that Sail defaults to:2. Updating the
docker-compose.ymlfileFor simplicity, the
Dockerfilewill be considered to be in the root of the project, so need to change the container's build context:services: laravel.test: build: - context: ./vendor/laravel/sail/runtimes/8.2 + context: .By default,
WWWGROUPis already part of build arguments, andWWWUSERonly as environment variable, so we just need to moveWWWUSERto be and argument instead.services: laravel.test: build: context: . args: + WWWUSER: '${WWWUSER}' WWWGROUP: '${WWWGROUP}' # ... envrionment: - WWWUSER: '${WWWUSER}' # ...These changes should be enough to get Sail working with the project 🎉
If you're like me and you're looking to reuse the images for production, then we can make use of multi-stage builds to build a base image, a sail image for development and (optionally) a production-ready image.
Depending on your use case, you can have the production-ready image be the base image and manually mount the project directory, or pack the whole project into a single image and deploy to platforms like Fly, Render, Railways or any other hosting provider that can manage containers.
In this case, I'm deploying my project already packed in a container, and my
Dockerfilelooks like this:You must not forget to set the
build.targetproperty in yourdocker-compose.ymlfile:services: laravel.test: build: context: . + target: development # ...I hope this proves useful and hopefully makes it into documentation, although built-in support for sail would be best, but with such a huge rewrite that 3.x is, I think you have enough stuff to do before 😅
Please let me know if anyone has any questions or suggestions regarding Sail support 😄
Changelog
2024-04-24: Align example with new "unprivileged" image system.2024-05-31: v3 is out of beta 🎉Beta Was this translation helpful? Give feedback.
All reactions