What is Laravel Sail, and how do you add it to a Laravel 13 application and start its containers?
answer
- a Compose file plus a bash script
- composer require laravel/sail --dev
- sail:install writes compose.yaml, rewrites .env
- --with=mysql,redis or pick interactively
- ./vendor/bin/sail up -d, then sail stop
basics
~20 sLaravel Sail is a bash script plus a generated compose.yaml that runs the app and its services in Docker. In Laravel 13 you run composer require laravel/sail --dev, then php artisan sail:install, then ./vendor/bin/sail up.
solid answer
~50 sSail is Laravel's Docker development environment: a `compose.yaml` in the project root and the `sail` script shipped in `vendor/bin`, which wraps Docker Compose. The Laravel 13 skeleton does not require it, so you add it with `composer require laravel/sail --dev` and run `php artisan sail:install`. That command asks which services you want — MySQL, PostgreSQL, MariaDB, Redis, Valkey, Mailpit, Meilisearch and others — or takes `--with=mysql,redis`; it writes `compose.yaml` with a `laravel.test` application service built from Sail's PHP 8.5 runtime by default (`--php=8.4` picks another), rewrites `.env` so `DB_HOST=mysql`, `DB_USERNAME=sail`, `DB_PASSWORD=password`, `REDIS_HOST=redis` and so on, points `phpunit.xml` at a `testing` database, and builds the images. `./vendor/bin/sail up -d` starts everything in the background and the app answers on `http://localhost`; `sail stop` stops it. Everyone on the team then runs the same PHP, whatever is installed on their laptop.
code
bash · 7 linescomposer require laravel/sail --dev
php artisan sail:install --with=mysql,redis,mailpit
./vendor/bin/sail up -d
./vendor/bin/sail artisan migrate
./vendor/bin/sail stopgo deeper
Recall the install steps — composer require laravel/sail --dev, sail:install, sail up — and that Sail runs the app and services in Docker.
Explain what sail:install writes: the laravel.test service and runtime, chosen services and volumes, and the .env and phpunit.xml rewrites.
Show why Sail helps a team: the PHP runtime and services are pinned in the repository, so onboarding and version changes become reviewed file changes.
Decide whether a containerised local environment is worth standardising for the team, weighing uniformity against Docker overhead on developer machines.
## What Sail is **Laravel Sail** is Laravel's lightweight, Docker-based **local development environment**. At its heart it is two things: - a **`compose.yaml`** file in the project root, describing an application container named `laravel.test` plus the services you chose (a database, Redis, a mail catcher); - the **`sail` script** — a bash script shipped in `vendor/bin` by the `laravel/sail` package — which wraps Docker Compose with Laravel-flavoured commands such as `sail artisan`, `sail composer` and `sail test`. Sail runs on macOS, Linux and Windows through WSL2, and needs Docker running. It does not install PHP, MySQL or Redis on your machine: all of that lives in containers, described by files the team commits. ## Adding Sail to a Laravel 13 application The Laravel 13 skeleton's `composer.json` no longer lists `laravel/sail`, so a new app does not have the script until you add it: 1. `composer require laravel/sail --dev` — installs the package and the `vendor/bin/sail` script. 2. `php artisan sail:install` — choose services interactively (MySQL is pre-selected), or pass them: `php artisan sail:install --with=pgsql,redis,mailpit`. `--with=none` installs only the app container, and a run with `--no-interaction` and no `--with` gets MySQL, Redis, Selenium and Mailpit. 3. `./vendor/bin/sail up -d` — build if necessary and start every container in the background. 4. `./vendor/bin/sail artisan migrate` — the installer reminds you to do this when it added a database. ## What `sail:install` changes | File | Change | |---|---| | `compose.yaml` | created (or extended) with `laravel.test` built from `vendor/laravel/sail/runtimes/8.5` by default, plus one entry per chosen service, named volumes such as `sail-mysql`, and `depends_on` links | | `.env` | `DB_CONNECTION` set for the chosen database, `DB_HOST=mysql` (or `pgsql`, `mariadb`), `DB_USERNAME=sail`, `DB_PASSWORD=password`, `REDIS_HOST=redis`, `MAIL_MAILER=smtp` with `MAIL_HOST=mailpit` and `MAIL_PORT=1025`, and `PHP_CLI_SERVER_WORKERS=4` | | `phpunit.xml` | `DB_DATABASE` pointed at a `testing` database, which the MySQL, MariaDB and PostgreSQL containers create on first start | `--php=8.4` (any of 8.0 to 8.5) chooses the runtime at install time, and `--devcontainer` also writes a `.devcontainer/devcontainer.json`. ## Starting and stopping - `sail up` runs in the foreground; Ctrl+C stops the containers. - `sail up -d` runs them detached; `sail stop` stops them. - The application is served at `http://localhost` — port 80 unless `APP_PORT` says otherwise — and Mailpit's inbox at `http://localhost:8025`. - Any command Sail does not define itself is passed to Docker Compose, which is why `sail up`, `sail ps` and `sail build` work. - Before starting, make sure nothing else on the machine already uses the published ports, such as a local MySQL on 3306. ## The team with different PHP versions Consider a team where one developer has PHP 8.2 from the operating system, another 8.5 from a package manager, and CI runs 8.4. Code that works on one laptop fails on another — a new language feature, a missing extension, a different default. With Sail, the PHP version is part of `compose.yaml` (the `laravel.test` build context names the runtime), so after `git pull` and `sail up` every developer runs the same PHP with the same extensions, and nobody's host PHP matters. Changing the version is a reviewed change to one file followed by a rebuild. ## Why interviewers ask Sail questions test whether a candidate understands their own development environment rather than just typing commands from a tutorial. A good answer separates the pieces: the Composer package that provides the script, the Artisan command that generates configuration, the Compose file that defines containers, and the `.env` changes that connect the application to them. Knowing that Laravel 13's skeleton does not ship Sail — and that `sail:install` rewrites `.env` — is also what lets someone debug the usual first-day failures: a missing `vendor/bin/sail`, a port already in use, or an application still pointing at `127.0.0.1`. ## What Sail is not - Not a production platform: the application container runs PHP's development server and ships debugging tools. - Not a replacement for learning Docker: it is ordinary Compose underneath, and `sail:publish` hands you the Dockerfiles to customise. - Not required: Laravel runs just as well on a native PHP install or a team's own Docker setup.
- The Laravel 13 Sail docs say `vendor/bin/sail` is included with all new Laravel applications. Is that true for a fresh `laravel/laravel` 13 skeleton?Not for the skeleton pinned here: its `composer.json` requires `laravel/framework` and `laravel/tinker`, with no `laravel/sail` in `require-dev`. So on a fresh app you run `composer require laravel/sail --dev` before `php artisan sail:install`; the docs' own installation section starts with exactly that step.
- What does `php artisan sail:install --no-interaction` install when you pass no `--with`?The default service set: MySQL, Redis, Selenium and Mailpit. Interactively, the service picker pre-selects only MySQL. Passing `--with=none` installs just the application container, which suits an app that keeps the skeleton's SQLite default.
saying these in an interview costs you the question
- Sail installs PHP, MySQL and Redis directly onto the developer's machine.
- Every new Laravel 13 application already has vendor/bin/sail without any extra package.
- sail:install only writes compose.yaml and leaves .env untouched.
- Sail is Laravel's recommended way to run applications in production.
- Sail only works on macOS.