先に要点
- 個人開発で Next.js を VPS に出すとき、GitHub Actions は便利ですが、常に必須とは限りません。
build -> push -> pullの転送コストを考えると、VPS 上で直接 build する方が速くて単純なことがあります（サーバー側に余力がある前提）。- チーム開発、CI 必須、複数環境運用なら GitHub Actions の価値はかなり大きいです。
CI を重視するかとVPS に build 余力があるかで分けるのが現実的です。
個人開発で Next.js アプリを VPS へデプロイするとき、GitHub Actions だと少し遅い と感じる場面があります。
最初に思いつきやすいのは GitHub Actions で build して、レジストリへ push して、サーバー側で pull する 構成です。
実際、それ自体はかなり王道ですし、チーム開発では今でも強い選択肢です。
ただ、個人開発や小規模運用では、そこまで複雑にしなくてもよい場面があります。
この記事では、GHA + レジストリ と VPS上での直接 build を比べながら、どんなときに後者が現実的かを整理します。
先に要点
構成
個人開発では重くなりやすい
GitHub Actions が悪いのではなく、個人開発では構成が少し重くなりやすい
待ち時間
転送のぶん増える
レジストリ push / pull が入ると、ビルド以外の待ち時間も増える
VPS直ビルド
余力があれば速い
VPS に十分なメモリと CPU があるなら、直ビルドの方がシンプルで速いことがある
チームなら価値が高い
ただし、チーム開発や CI 必須なら GitHub Actions の価値はかなり高い
よくある GHA 経由デプロイ構成
まず、よくある構成をざっくり書くとこんな流れです。
git push
-> GitHub Actions 起動
-> Docker イメージを build
-> ghcr.io などのレジストリへ push
-> VPS で image を pull
-> docker compose up -d
一方で、個人開発では次のような重さを感じることがあります。
なぜ遅く感じやすいのか
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 する場所と動かす場所が同じなので、環境差で悩みにくいのもメリットです。
deploy.sh を実行するどこが実務的に楽なのか
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 が効きやすい
同じホストで回すメリット
build cache が残る
VPS 上に build cache が残るので、毎回ゼロから組み直すより速く感じやすい場面があります。もちろん Dockerfile の書き方次第です。
この方法の注意点
1. VPS のメモリが足りないとつらい
Next.js の build や Docker build は、それなりにメモリを使います。
VPS の余裕が少ないと、OOM で build が落ちることがあります。
2. 同時実行を止めた方が安全
複数サービスを同じサーバーで動かしているなら、同時 build はかなり危ないです。
特にメモリが潤沢でないと、一気に苦しくなります。
こうした排他制御はかなり実用的です。いまデプロイ中なら次は中止する だけでも、事故を減らしやすくなります。
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、レンタルサーバーの違いは？コスパ比較と実務での使い分けを解説 もつながりやすいです。
GitHub ActionsとVPS直接ビルドに関するよくある質問
Q. 個人開発でも GitHub Actions を使うべきですか？
A. PR ごとの自動チェック、複数の Node.js バージョンでの確認、テストの自動実行が必要なら使う価値が高いです。git push したら本番反映 だけが目的なら、VPS 上の hook スクリプトでも十分です。
Q. GitHub Actions の無料枠はどれくらいですか？
A. 2026年10月時点の公式の料金ページでは、パブリックリポジトリで標準の GitHub ホストランナーを使う場合は無料です。プライベートリポジトリはプランごとに毎月の無料枠があり、GitHub Free は 2,000分、Pro と Team は 3,000分、Enterprise Cloud は 50,000分です。超えた分は、たとえば Linux 2コアのランナーで1分あたり 0.006ドルです。1回のビルドに何分かかるかを測れば、月に何回デプロイできるかを見積もれます。
Q. VPS の build_files ディスク圧迫はどう避けますか？
A. ビルド成果物の世代を tar.gz で残し、古いものを定期削除します。capistrano のような世代管理ツールを使うと、残す世代数を設定して古いものを自動で消せます。
Q. GitHub Actions から VPS へのデプロイはどう設計しますか？
A. SSH 鍵を GitHub Secrets に登録し、Actions で rsync または scp + ssh コマンド実行 でデプロイするのが定番です。Tailscale や Cloudflare Tunnel と組み合わせて、VPS の SSH を公開せず使う構成もあります。
Q. ビルドは GitHub Actions、実行は VPS、という分け方は良い設計ですか？
A. はい、どこに重い処理を寄せるか で考えれば素直な構成です。VPS のスペックを最小限に抑えられ、ビルド時間も並列化しやすくなります。
Q. キャッシュを使えばビルド時間はどれくらい縮みますか？
A. actions/cache で node_modules や Next.js の .next/cache を保存しておくと、変更が小さいときのビルドを短縮できます。どれだけ縮むかはプロジェクト次第なので、キャッシュの有無で実際のジョブ時間を比べて確かめます。
Q. デプロイに失敗したときのロールバックはどう設計すれば良いですか？
A. 旧バージョンの成果物を残しておき、シンボリックリンクの切り替えだけで戻せる構成にします。current -> release_v3 を release_v2 に張り直すだけで即時ロールバックできるのが理想です。
まとめ
個人開発で 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
- GitHub Docs: GitHub Actions billing
- Docker Docs: Prune unused Docker objects