Laravel Sailは、Laravel公式のDocker開発環境をsailという短いコマンドで操作するツールです。sail upは起動、sail stopはコンテナを残した停止、sail downはコンテナとネットワークを消す停止です。標準構成のようにDBを名前付きボリュームに保存していれば、どれもデータは残り、消えるのはsail down -vのときだけです。Laravel 13からは新規プロジェクトにSailが入っておらず、古い手順どおり./vendor/bin/sail upを打つと「no such file or directory」で止まります。Laravel 13.38.0とSail v1.69.0を実際に動かして確かめた導入手順、コマンドの違い、詰まりやすいエラーの直し方をまとめます。
まとめ：Laravel Sailの要点
- Sailの正体：プロジェクト直下の
compose.yamlとsailスクリプトの2つ。sailが知らないコマンドは、そのままdocker composeへ渡る。 - Laravel 13では自分で入れる：雛形からSailが外れたため、
composer require laravel/sail --devのあとphp artisan sail:installを実行する。 - 起動と停止：
sail up -dで起動、sail stopで一時停止（コンテナを残す）、sail downで後片付け（コンテナを消す）。DBのデータはどちらでも残り、sail down -vでだけ消えた。 - 起動しないとき：ポート競合がないかを確認する。
.envのAPP_PORT・FORWARD_DB_PORT・FORWARD_REDIS_PORTで逃がす。 - Podman：Sail v1.55.0から公式に
SAIL_DOCKER_BINARY=podmanで切り替えられる。フォークは不要になった。
Laravel Sailとは｜compose.yamlとsailスクリプトで動く開発環境
Laravel公式ドキュメントのSailのページは、Sailを「LaravelのデフォルトのDocker開発環境を操作する軽量なコマンドラインインターフェース」と説明しています。中身はプロジェクト直下のcompose.yamlとsailスクリプトだけです。compose.yamlが立ち上げるコンテナを定義し、sailがそれを操作します。PHP・MySQL・Redisを自分でインストールしなくても、Compose設定を共有すれば、チームでサービス構成を揃えられます。ただし、可変のイメージタグやビルド時に取得するパッケージは更新されるため、同じ版を再現するにはイメージや依存関係の固定も必要です。
アプリ本体が動くのはlaravel.testという名前のコンテナです。今回sail:install --with=mysql,redisで作ったcompose.yamlでは、laravel.test（イメージ名sail-8.5/app）・mysql（mysql:8.4）・redis（redis:alpine）の3つが定義されていました。対応OSはmacOS・Linux・Windows（WSL2経由）です。
sail downの仕組みとDocker Composeへの引数転送
公式ドキュメントの「Starting and Stopping Sail」の節にはsail up・sail up -d・sail stopしか出てこず、sail downの説明はありません。それでもsail downが動くのは、sailスクリプトがphp・artisan・composer・npm・shellなど決まったコマンドだけを自分で処理し、それ以外の引数を最後の行でdocker composeへそのまま渡しているからです。laravel/sailのbin/sailの末尾は次のようになっています。
# Run Docker Compose with the defined arguments...
"${COMPOSE_CMD[@]}" "${ARGS[@]}" "$@"つまりsail downはdocker compose down、sail psはdocker compose ps、sail logsはdocker compose logsと同じです。up・downは英語の熟語ではなくDocker Composeのサブコマンド名をそのまま使っているので、意味を調べるときはDocker Composeのdownのリファレンスを見るのが確実です。
Laravel 13でSailを導入する手順
流れは「プロジェクト作成→Sailを入れる→sail:install→起動」の4段階です。Laravel 12までは2段目を飛ばせましたが、13では飛ばせません。
Laravel 13の雛形からのSail依存削除
Laravelの雛形（laravel/laravel）のcomposer.jsonからlaravel/sailが消えたのは、Laravel 13対応の2026年2月5日のコミットです。この変更は2026年3月17日公開のv13.0.0に入り、2026年10月時点の最新v13.11.0でもrequire-devにSailはありません。.env.exampleの既定DBもDB_CONNECTION=sqliteで、MySQLを前提にしていません。
composer create-project laravel/laravelで作ったLaravel 13.38.0のプロジェクトでは、vendor/binにあるのはpintやphpunitなどで、sailはありませんでした。古い記事の手順どおりに打つと次のように止まります。
$ ./vendor/bin/sail up
zsh: no such file or directory: ./vendor/bin/sail公式ドキュメントのエイリアスの節には「vendor/bin/sailはすべての新しいLaravelアプリに含まれている」という一文が残っていますが、2026年10月26日時点の雛形とは食い違っています。Laravel 13では次の手順で自分で入れてください。
composer require laravel/sailとsail:installによる導入
最初の2行（composer requireとsail:install）は手元のPHPとComposerで実行します（Laravel 13はPHP 8.3以上が必要）。手元にPHPを入れたくない場合は、後述のlaravel.buildで作るほうが早道です。プロジェクトのルートで、Sailを開発用の依存として入れてからsail:installを実行します。--withを付けると対話の選択を省けます。付けずに実行すると一覧から選ぶ画面になります。
composer require laravel/sail --dev
php artisan sail:install --with=mysql,redis
./vendor/bin/sail up -d
./vendor/bin/sail artisan migrate2026年10月13日公開のSail v1.69.0では、--withに指定できるサービスはmysql・pgsql・mariadb・mongodb・redis・valkey・memcached・meilisearch・typesense・rustfs・mailpit・mailtrap-local・rabbitmq・selenium・soketiの15種類です（InteractsWithDockerComposeServices.php）。PHPの版は--phpで指定でき、既定は8.5です。VS CodeのDev Containersで開発するなら--devcontainerを足します。
sail:installはcompose.yamlを書き出すだけでなく、.envも書き換えます。今回の実行前後の差分は次のとおりでした。
| キー | 実行前 | 実行後 |
|---|---|---|
| DB_CONNECTION | sqlite | mysql |
| DB_HOST | （コメントアウト） | mysql |
| DB_USERNAME | （コメントアウト） | sail |
| DB_PASSWORD | （コメントアウト） | password |
| REDIS_HOST | 127.0.0.1 | redis |
| PHP_CLI_SERVER_WORKERS | （コメントアウト） | 4 |
| APP_URL | http://localhost:8000 | 変更なし |
DB_HOSTが127.0.0.1ではなくmysqlになるのは、コンテナ同士がサービス名で通信するためです。一方でAPP_URLは8000番のまま残ります。Sailは80番（APP_PORT）で待ち受けるので、メールのリンクやurl()で作るURLを正しくしたい場合は、APP_URLをhttp://localhostに直しておきます。
laravel.buildで新規作成する方法と制約
競合記事の多くが紹介しているcurl -s "https://laravel.build/example-app" | bashは、2026年10月26日時点でも使えます。スクリプトを取得して読むと、laravelsail/php84-composerイメージの中でlaravel newを実行し、Sailが無ければcomposer require laravel/sail --devで入れてからsail:install --with=mysql,redis,meilisearch,mailpit,seleniumを流す作りで、雛形にSailが無いことをスクリプト側で補っています。
注意点は2つです。URLの?php=で指定できる版は74〜84だけで、php=85を渡すと「Invalid PHP version. Please specify a supported version (74, 80, 81, 82, 83, or 84).」が返ります。また、最後にdoasまたはsudoで所有者を変更します。認証が必要な環境ではパスワードを求められます。止まったように見えたら入力待ちです。サービスは?with=mysql,redisのように絞れます。
sailエイリアスの設定と反映
毎回./vendor/bin/sailと打つのは手間なので、公式ドキュメントにあるエイリアスを~/.zshrcか~/.bashrcに追記してシェルを開き直します。
alias sail='sh $([ -f sail ] && echo sail || echo vendor/bin/sail)'カレントディレクトリにsailがあればそれを、無ければvendor/bin/sailを実行する書き方です。以降の例はこのエイリアスを設定した前提でsailと書きます。
sail up・sail stop・sail downの違い【実測】
3つの違いは「コンテナを残すか」と「ボリューム（DBのデータ置き場）を残すか」です。ポートを変えて起動し、sail artisan migrateのあとMySQLにユーザーを1件入れた状態から各コマンドを実行して、コンテナとデータがどうなるかを確かめました（初回の起動は後述のポート競合で失敗しています）。
| コマンド | コンテナ | ネットワーク | ボリューム | 再度up -dの所要 | usersの件数 |
|---|---|---|---|---|---|
| sail stop | Exitedで残る | 残る | 残る | 2秒 | 1件（残る） |
| sail down | 削除 | 削除 | 残る | 3秒 | 1件（残る） |
| sail down -v | 削除 | 削除 | 削除 | 3秒 | テーブルごと消える |
計測はIntel MacのColima（x86_64のVM・4CPU・メモリ6GiB）上のDocker、Docker Compose 5.6.0で行いました。秒数はコマンドが戻るまでの時間で、MySQLのヘルスチェックがhealthyになるまでには毎回さらに約30秒かかりました。sail stopの後とsail downの後で再起動の速さはほとんど変わらず、違いはコンテナを作り直すかどうかだけです。sail down -vの後はusersテーブルが無くなり、「Table ‘laravel.users’ doesn’t exist」でマイグレーションからやり直しになりました。
sail upとsail up -dの実行モードの違い
sail upはフォアグラウンドで起動し、全コンテナのログがターミナルに流れ続けます。止めるときはControl＋Cです。sail up -dはバックグラウンド（デタッチモード）で起動するので、同じターミナルでsail artisanなどを続けて打てます。起動後はhttp://localhost（APP_PORTを変えた場合はhttp://localhost:8081のようにポート付き）で開きます。初回はsail-8.5/appイメージのビルドが走ります。今回はコマンドの開始からビルド完了を経て、ポート競合で失敗するまでに724秒（約12分）かかりました。できあがったsail-8.5/appイメージは3.16GBあるので、ディスクの空きも確認しておきます。2回目以降はビルド済みのイメージを使うため、数秒で起動します。
sail stop と sail down の使い分け
作業を中断して後で再開するだけならsail stopで十分です。コンテナが残っているので、次のsail up -dは作り直しが要りません。sail downはコンテナとネットワークを消すので、compose.yamlを書き換えたあとや、コンテナの状態がおかしくなったときのリセットに向いています。Docker Composeのリファレンスも、downが既定で消すのは「コンテナ」「networks節のネットワーク」「デフォルトネットワーク」だけだと書いています。
DBまで初期化したいときだけsail down -vを使います。-vはcompose.yamlのvolumes節にある名前付きボリューム（今回はsail-mysqlとsail-redis）を消すので、マイグレーションもやり直しになります。開発中のデータを消したくなければ、-vは付けないでください。テーブルだけ作り直したいならsail artisan migrate:freshのほうが手早く、挙動の違いはLaravelマイグレーションの使い方で検証しています。
Sailが止まっている間のコマンド
コンテナが動いていない状態でsail artisanやsail composerを打つと、「Sail is not running.」と表示されて終了コード1で止まります。今回はsail stopの後とsail downの後の両方でこの表示を確認しました。先にsail up -dを実行してから打ち直してください。
sail経由のartisan・composer・npm実行
Sailを使う間、アプリはコンテナの中で動いています。手元のMacに入っているPHPでphp artisanを打つと、コンテナとは別のPHPとDB設定で動いてしまいます（DB_HOST=mysqlは手元から名前解決できません）。公式ドキュメントのphp artisan queue:workという例は、Sailではsail artisan queue:workに読み替えます。
sail php --version
sail composer require laravel/sanctum
sail artisan migrate
sail npm install
sail npm run dev
sail test
sail shell今回のコンテナではsail php -vがPHP 8.5.12、sail node -vがv24.22.1（npm 12.2.1）、MySQLは8.4.11でした。sail npm run devでViteの開発サーバーを動かすときは5173番（VITE_PORT）がホストへ公開されます。Laravel側の設定はLaravel Viteの使い方にまとめています。sail testはsail artisan testと同じです。sail:installはphpunit.xmlも書き換えており、今回はDB_CONNECTION（sqlite）の行が消え、DB_DATABASEが:memory:からtestingに変わりました。テストは初回起動時に作られるMySQLのtestingデータベースで動くので、開発用のデータとは分かれます。phpunit.xmlを自分で変えているプロジェクトでは、接続先を確認してから実行してください。ブラウザテストのLaravel Duskによるテスト自動化も、Duskのインストールと初期設定を済ませ、compose.yamlのseleniumサービスを有効にしたうえでsail duskから実行できます。
MySQL・Redisなどのサービス追加と接続設定
アプリから接続するときのホスト名はサービス名です。MySQLならDB_HOST=mysql、RedisならREDIS_HOST=redisになります。TablePlusなどのGUIクライアントで手元から接続するときはlocalhostの3306番（FORWARD_DB_PORT）を使い、ユーザー名とパスワードはDB_USERNAME・DB_PASSWORDの値です。MySQLコンテナは初回起動時に、DB_DATABASEの名前の開発用DBとテスト用のtestingの2つを作ります。
後からサービスを足すときはphp artisan sail:addを使います。sail:add valkeyのように名前を渡すと、対話なしでcompose.yamlに追記されます。S3互換のローカルストレージは、以前のMinIOに代わってRustFSが選択肢になっています。メールの確認用にはMailpitが入り、http://localhost:8025で受信したメールを見られます。
PHP・Nodeのバージョン変更とイメージ再ビルド
Sail v1.69.0のruntimesディレクトリにはPHP 8.0〜8.5の6種類があり、既定は8.5です。版を変えるには、compose.yamlのlaravel.testでbuild.contextのパス（例：./vendor/laravel/sail/runtimes/8.4）とimage名（例：sail-8.4/app）の両方を書き換え、イメージを作り直します。
services:
laravel.test:
build:
context: './vendor/laravel/sail/runtimes/8.4'
args:
WWWGROUP: '${WWWGROUP}'
NODE_VERSION: '22'
image: 'sail-8.4/app'sail build --no-cache
sail up -dNode.jsは8.5のDockerfileでNODE_VERSION=24が既定で、ベースはUbuntu 24.04です。build.argsにNODE_VERSIONを足せば変えられます。image名を変えなくても、変更したビルド設定で再ビルドすればPHPの変更は反映されます。ただし、PHP版を識別し、別プロジェクトとのイメージ名の衝突を避けるため、名前も合わせて変更することを勧めます。Laravel 13はPHP 8.3以上が必要なので、Sailのランタイムで選べるのは実質8.3〜8.5です。その中で本番サーバーのPHPに合わせます。版ごとのサポート期限はPHPのサポート期限一覧で確認できます。
拡張モジュールを足すだけなら、build.argsにPHP_EXTENSIONS: 'gmp imagick'のように空白区切りで書けば済みます。Dockerfileそのものを変えたいときはsail artisan sail:publishでdockerディレクトリへ書き出して編集します。
PodmanでのSail実行とSAIL_DOCKER_BINARY設定
2026年3月24日公開のSail v1.55.0で、呼び出すコンテナエンジンを環境変数で切り替えられるようになりました（laravel/sail PR #857）。既定値はdockerで、Podmanを使うなら.envかシェルで次のように指定します。
SAIL_DOCKER_BINARY=podman上記は.envへの記載です。シェルで設定する場合は、export SAIL_DOCKER_BINARY=podmanを実行してからSailを呼び出します。
sailは${SAIL_DOCKER_BINARY} composeが通ればそれを、通らなければ${SAIL_DOCKER_BINARY}-composeを使います。つまりPodman側でpodman composeが動く状態（compose providerとしてdocker-composeかpodman-composeが入っている状態）が前提です。起動前チェックの文言も「Docker or Podman is not running.」に変わりましたが、公式ドキュメントのSailのページは2026年10月26日時点でPodmanに触れていません。チームの標準にするなら、1人が試してから広げるのが安全です。Podman自体の操作はPodmanコマンド一覧と使い方を参照してください。
Docker Desktopの有料条件（従業員250人以上または年間売上1,000万ドル以上）を避けたいだけなら、MacではColimaも選べます。今回の実測はColima上のDockerで行い、Sail側の設定変更は要りませんでした。条件はDocker Desktopのライセンスと導入手順、導入はColimaとは？MacでDocker Desktopを外す導入手順で解説しています。
Sailが起動しない・localhostにつながらないときの対処
公式ドキュメントは「Sailを起動する前に、手元で他のWebサーバーやデータベースが動いていないことを確認するように」と書いています。ポート競合は、起動失敗時に確認する項目の一つです。
ポート競合（port is already allocated）
手元で別のRedisが6379番を使っている状態で、ポートを変えずにsail up -dを実行しました。mysqlは起動したものの、redisの起動で次のエラーになり、laravel.testも作成済み（Created）のまま起動しませんでした。終了コードは1です。
Error response from daemon: failed to set up container networking: driver failed programming external connectivity on endpoint app-redis-1 (...): Bind for 0.0.0.0:6379 failed: port is already allocated直し方は、手元で動いているサーバーを止めるか、Sail側のポートをずらすかです。.envに次を足してからsail down→sail up -dし直すと、今回は起動できました。
APP_PORT=8081
FORWARD_DB_PORT=33316
FORWARD_REDIS_PORT=63790ずらしても変わるのはホスト側の番号だけで、コンテナ同士の通信（DB_HOST=mysqlの3306番）はそのままです。.envのDB_PORTを書き換える必要はありません。どのポートが使われているかは、macOSやLinuxならlsof -nP -iTCP:3306 -sTCP:LISTENで調べられます。
起動直後のHTTP 500とセッションテーブル未作成
ポートを直して起動できた直後にhttp://localhost:8081を開くと、HTTP 500が返りました。ログには「Table ‘laravel.sessions’ doesn’t exist」が出ています。Laravel 13の.envはSESSION_DRIVER=database・CACHE_STORE=databaseが既定なので、MySQLへ切り替えた直後はセッション用のテーブルがありません。sail artisan migrateを実行すると200に変わりました。sail:installの最後に出る「Run “artisan migrate”」という警告は、この手順のことです。
Docker or Podman is not runningの原因と接続先確認
Sailは通常、設定されたエンジンに応じてdocker infoまたはpodman infoを実行し、失敗すると「Docker or Podman is not running.」を出して止まります。Docker DesktopやColimaが起動しているかを確認してください。Colimaのようにdocker contextで接続先を切り替える環境では、docker context lsで現在の接続先が動いているエンジンを指しているかも見ます。Linux版のDocker Desktopを使うときは、公式ドキュメントのとおりdocker context use defaultを実行します。同じ段落で、コンテナ内でファイルの権限エラーが出る場合はSUPERVISOR_PHP_USERをrootにする方法も挙げられています。
Windows（WSL2）のファイルアクセス遅延と配置先
WindowsではWSL2のLinux側（~/配下など）にプロジェクトを置きます。/mnt/c/のようなWindows側のフォルダに置くと、ファイルアクセスがOSの境界をまたぐため遅くなります。MicrosoftのWSLのドキュメントも、Linuxのツールで扱うファイルはWSLのファイルシステムに置くよう勧めています。
原因がわからなければ、sail psで落ちているサービスを探し、sail logs mysqlのようにサービス名を付けてログを見ます。
Sailを選ばないほうがよい場面
Sailは開発用の環境で、本番での利用は想定されていません。laravel.testはPHPの組み込みサーバー（artisan serve）でアプリを動かし、MySQLのパスワードもpasswordのままです。本番でコンテナを使うなら、Nginx＋PHP-FPMなどで本番用のイメージを別に作り、AWSなどのインフラ構築の段階で設計し直すべきです。
開発用でも、Dockerを使わないほうが手軽な場面があります。MacやWindowsでPHPのアプリだけを動かしたいなら、PHPをネイティブで動かすLaravel Herdを使えば、コンテナや仮想マシンを管理せずに始められます。逆に、チームでMySQLやRedisの構成まで揃えたい、CIと同じ構成で動かしたいならSailが向いています。両者の比較はLaravel HerdとSailの使い分けで詳しく扱っています。
よくある質問
sail downとsail stopの違いは何ですか？
sail stopはコンテナを止めて残し、sail downはコンテナとネットワークを削除します。名前付きボリュームに入ったDBのデータはどちらでも残り、消えるのはsail down -vのときです（外部ボリュームやバインドマウントは-vでも消えません）。
sail upとsail up -dの違いは何ですか？
sail upはフォアグラウンドで起動してログを表示し続け、Control＋Cで止まります。sail up -dはバックグラウンドで起動し、ターミナルをすぐに返します。
Laravel 13で「vendor/bin/sail: no such file or directory」と出るのはなぜですか？
Laravel 13の雛形にSailが含まれなくなったためです。composer require laravel/sail --devで入れてからphp artisan sail:installを実行すると、vendor/bin/sailとcompose.yamlができます。
Laravel SailはPodmanで使えますか？
Sail v1.55.0以降なら、SAIL_DOCKER_BINARY=podmanを設定するとPodmanを呼び出します。podman composeが動く状態にしておく必要があり、公式ドキュメントにはまだ手順がありません。
Laravel Sailは本番環境でも使えますか？
標準構成のまま本番環境に使うべきではありません。Sailは開発用で、PHPの組み込みサーバーや開発用のDB設定を使います。本番は別に用意したコンテナ基盤やサーバーで動かします。
