個人開発で Next.js アプリを VPS へデプロイするとき、GitHub Actions だと少し遅い と感じる場面があります。
最初に思いつきやすいのは GitHub Actions で build して、レジストリへ push して、サーバー側で pull する 構成です。
実際、それ自体はかなり王道ですし、チーム開発では今でも強い選択肢です。
ただ、個人開発や小規模運用では、そこまで複雑にしなくてもよい場面があります。
この記事では、GHA + レジストリ と VPS上での直接 build を比べながら、どんなときに後者が現実的かを整理します。
先に要点
- GitHub Actions が悪いのではなく、個人開発では構成が少し重くなりやすい
- レジストリ push / pull が入ると、ビルド以外の待ち時間も増える
- VPS に十分なメモリと CPU があるなら、直ビルドの方がシンプルで速いことがある
- ただし、チーム開発や CI 必須なら GitHub Actions の価値はかなり高い
よくある GHA 経由デプロイ構成
まず、よくある構成をざっくり書くとこんな流れです。
git push
-> GitHub Actions 起動
-> Docker イメージを build
-> ghcr.io などのレジストリへ push
-> VPS で image を pull
-> docker compose up -d
この構成のよいところは、デプロイの再現性が高い ことです。
同じ workflow を通すので、どこで何をしているかがまとまりやすく、将来チームになっても育てやすいです。
一方で、個人開発では次のような重さを感じることがあります。
なぜ遅く感じやすいのか
1. build だけでなく転送も入る
GitHub Actions でイメージを build したあと、GitHub Container Registry などへ push し、VPS 側で pull する構成だと、build時間 + push時間 + pull時間 が合計に乗ります。
Next.js のように build である程度時間がかかるアプリでは、ここが地味に効きます。
特にイメージサイズが大きいと、コード差分が小さくても待ち時間が短くなりにくいです。
2. 個人開発では CI よりデプロイ速度を優先したいことがある
チーム開発なら、GitHub Actions で lint、test、build をそろえて回す価値は大きいです。
でも個人開発で、まずは自分だけが素早く直して反映したい 状態なら、そこまで重いパイプラインが合わないことがあります。
3. 構成の管理ポイントが増える
このあたりは、あとで効いてくる価値もあります。
ただ、最初の1サービスを回す段階では、シンプルな方が保守しやすいことも多いです。
ローカル build + push ではだめか
改善案としてよく出るのが、ローカルで build して、その成果物だけレジストリへ送る 方法です。
これは build 自体は速くなりやすいです。
ただし、レジストリへの push / VPS 側での pull は残ります。
さらに、Mac と Linux の差、CPU アーキテクチャ差、ローカル環境依存も入りやすいので、シンプルになったようで別の悩みが増えることがあります。
VPS直ビルドという考え方
そこで出てくるのが、VPS上にリポジトリを置き、その場で pull して build する 形です。
git push
-> VPS に SSH
-> deploy.sh を実行
-> git pull
-> docker compose build
-> docker compose up -d
この形だと、レジストリを挟まないぶん、イメージ転送の待ち時間 が消えます。
また、build する場所と動かす場所が同じなので、環境差で悩みにくいのもメリットです。
どこが実務的に楽なのか
1. 構成がかなり単純になる
デプロイスクリプトは、かなり素直に書くとこういう形です。
#!/bin/bash
set -euo pipefail
exec 200>/tmp/deploy.lock
flock -n 200 || { echo "Another deploy is running. Aborting."; exit 1; }
cd /opt/app/repo
git pull
cd ..
docker compose -f docker-compose.prod.yml build app
docker compose -f docker-compose.prod.yml up -d
docker image prune -f
ここでは機密情報になりうる実名やパスは出さず、一般化した形にしています。
大事なのは、git pull -> build -> up -d をサーバー上で完結させることです。
2. 同じ場所で build してそのまま動かせる
Docker Compose の image: ではなく build: を使うと、VPS 上のソースコードから直接イメージを作れます。
services:
app:
build:
context: .
dockerfile: Dockerfile
restart: unless-stopped
expose:
- "3000"
これなら、その場で build して、そのままその場で起動する ので分かりやすいです。
3. build cache が効きやすい
VPS 上に build cache が残るので、毎回ゼロから組み直すより速く感じやすい場面があります。
もちろん Dockerfile の書き方次第ですが、同じホストで回すメリットはあります。
この方法の注意点
1. VPS のメモリが足りないとつらい
Next.js の build や Docker build は、それなりにメモリを使います。
VPS の余裕が少ないと、OOM で build が落ちることがあります。
つまり、VPS直ビルドが速い のは、サーバー側の余力がある前提です。
逆に小さい VPS では、CI 側で build した方が安定することもあります。
2. 同時実行を止めた方が安全
複数サービスを同じサーバーで動かしているなら、同時 build はかなり危ないです。
特にメモリが潤沢でないと、一気に苦しくなります。
そこで、草案にもあった flock のような排他制御はかなり実用的です。
いまデプロイ中なら次は中止する だけでも、事故を減らしやすくなります。
3. prune の使い方は雑にしない
VPS 上で build を続けると、古いイメージや build cache がたまります。
Docker の公式ドキュメントでも、docker image prune や docker system prune は未使用オブジェクト整理に使えると案内されています。
ただし、削除対象をよく理解しないまま --volumes まで付けるのは危ないです。
データ保持が必要な構成では、消してよいものと消してはいけないものを分けて考える必要があります。
GitHub Actions が向いている場面
ここまで書くと GitHub Actions は不要 に見えるかもしれませんが、そうではありません。
むしろ次のような場面では、かなり価値があります。
- チーム開発で PR ごとにテストや lint を回したい
- デプロイ前に CI を必ず通したい
- staging / production の流れを分けたい
- VPS のスペックが低く、build を寄せたくない
このあたりがあるなら、GitHub Actionsとは？できること・最初の使い方を初心者向けにわかりやすく解説 の文脈にかなり近いです。
じゃあ個人開発ではどう考えるといいか
個人開発でまず見るなら、この順番が分かりやすいです。
| 観点 | GHA + レジストリ | VPS直ビルド |
|---|---|---|
| 構成の分かりやすさ | やや重め | かなり単純 |
| 転送の有無 | push / pull がある | 基本なし |
| CI との相性 | 強い | 別途考える必要がある |
| VPS スペック依存 | 比較的低い | 高い |
つまり、CI を重視するか と VPS に build 余力があるか で分けるのがかなり現実的です。
インフラ全体のやりすぎない考え方を広く見たいなら、小規模サービスのインフラはどこまで必要？最初にやりすぎない考え方と判断軸を解説 や クラウド、VPS、レンタルサーバーの違いは？コスパ比較と実務での使い分けを解説 もつながりやすいです。
まとめ
個人開発で Next.js を VPS に出すとき、GitHub Actions は便利ですが、常に必須とは限りません。
build -> push -> pull の転送コストや構成の重さを考えると、VPS 上で直接 build する方が速くて単純なことがあります。
一方で、チーム開発、CI 必須、複数環境運用なら GitHub Actions の価値はかなり大きいです。
つまり、何が正解か ではなく、いまの規模に対して何がちょうどいいか で決めるのが一番自然です。
個人開発なら、まずはシンプルに回る構成を優先し、必要になったら CI やレジストリ運用を足していく、くらいがかなり現実的です。
参考リンク
- GitHub Docs: GitHub-hosted runners
- GitHub Docs: GitHub-hosted runners reference
- GitHub Docs: About GitHub Container Registry
- Next.js Docs: Deploying
- Docker Docs: Prune unused Docker objects