---
title: "Laravel Sailとは｜sail up・sail downの意味と導入手順【Laravel 13実測】"
url: "https://www.issoh.co.jp/tech/details/4275/"
published: 2024-11-21
updated: 2026-10-26
categories: ["Laravel"]
publisher: "株式会社一創"
---

# Laravel Sailとは｜sail up・sail downの意味と導入手順【Laravel 13実測】

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のページ](https://laravel.com/docs/13.x/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](https://github.com/laravel/sail/blob/1.x/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のリファレンス](https://docs.docker.com/reference/cli/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日のコミット](https://github.com/laravel/laravel/commit/4c9bb62621666c30adecaa06b6aabdf923a2b6e2)です。この変更は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 migrate
```

2026年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](https://github.com/laravel/sail/blob/1.x/src/Console/Concerns/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のリファレンス](https://docs.docker.com/reference/cli/docker/compose/down/)も、downが既定で消すのは「コンテナ」「networks節のネットワーク」「デフォルトネットワーク」だけだと書いています。

DBまで初期化したいときだけ`sail down -v`を使います。`-v`は`compose.yaml`の`volumes`節にある名前付きボリューム（今回は`sail-mysql`と`sail-redis`）を消すので、マイグレーションもやり直しになります。開発中のデータを消したくなければ、`-v`は付けないでください。テーブルだけ作り直したいなら`sail artisan migrate:fresh`のほうが手早く、挙動の違いは[Laravelマイグレーションの使い方](/tech/details/7253/)で検証しています。

### 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の使い方](/tech/details/3251/)にまとめています。`sail test`は`sail artisan test`と同じです。`sail:install`は`phpunit.xml`も書き換えており、今回は`DB_CONNECTION`（sqlite）の行が消え、`DB_DATABASE`が`:memory:`から`testing`に変わりました。テストは初回起動時に作られるMySQLの`testing`データベースで動くので、開発用のデータとは分かれます。phpunit.xmlを自分で変えているプロジェクトでは、接続先を確認してから実行してください。ブラウザテストの[Laravel Duskによるテスト自動化](/tech/details/5648/)も、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 -d
```

Node.jsは[8.5のDockerfile](https://github.com/laravel/sail/blob/1.x/runtimes/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のサポート期限一覧](/tech/details/18881/)で確認できます。

拡張モジュールを足すだけなら、`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](https://github.com/laravel/sail/pull/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コマンド一覧と使い方](/tech/details/2845/)を参照してください。

Docker Desktopの有料条件（従業員250人以上または年間売上1,000万ドル以上）を避けたいだけなら、MacではColimaも選べます。今回の実測はColima上のDockerで行い、Sail側の設定変更は要りませんでした。条件は[Docker Desktopのライセンスと導入手順](/tech/details/17442/)、導入は[Colimaとは？MacでDocker Desktopを外す導入手順](/tech/details/17842/)で解説しています。

## 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のドキュメント](https://learn.microsoft.com/ja-jp/windows/wsl/filesystems)も、Linuxのツールで扱うファイルはWSLのファイルシステムに置くよう勧めています。

原因がわからなければ、`sail ps`で落ちているサービスを探し、`sail logs mysql`のようにサービス名を付けてログを見ます。

## Sailを選ばないほうがよい場面

Sailは開発用の環境で、本番での利用は想定されていません。`laravel.test`はPHPの組み込みサーバー（`artisan serve`）でアプリを動かし、MySQLのパスワードも`password`のままです。本番でコンテナを使うなら、Nginx＋PHP-FPMなどで本番用のイメージを別に作り、[AWSなどのインフラ構築](/service/system/aws/)の段階で設計し直すべきです。

開発用でも、Dockerを使わないほうが手軽な場面があります。MacやWindowsでPHPのアプリだけを動かしたいなら、PHPをネイティブで動かすLaravel Herdを使えば、コンテナや仮想マシンを管理せずに始められます。逆に、チームでMySQLやRedisの構成まで揃えたい、CIと同じ構成で動かしたいならSailが向いています。両者の比較は[Laravel HerdとSailの使い分け](/tech/details/17145/)で詳しく扱っています。

## よくある質問

### 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設定を使います。本番は別に用意したコンテナ基盤やサーバーで動かします。

## 関連記事

- [Laravel Herdとは｜PHPバージョン切替と.test公開の仕組み・Sailとの使い分け](/tech/details/17145/)
- [Laravelマイグレーションの使い方｜php artisan migrateとrollback・freshの挙動を13.xで検証](/tech/details/7253/)
- [Colimaとは？MacでDocker Desktopを外す導入手順と設定の落とし穴【0.10系】](/tech/details/17842/)
- [Laravel Viteとは？使い方・@viteの書き方と本番ビルドの落とし穴【Laravel 13実測】](/tech/details/3251/)
- [Laravelのテスト自動化をDuskで実装する方法｜インストールからCI実行まで](/tech/details/5648/)

---

出典: [Laravel Sailとは｜sail up・sail downの意味と導入手順【Laravel 13実測】](<https://www.issoh.co.jp/tech/details/4275/>)（株式会社一創）
