デプロイのたびにSSHして手作業── これは事故の温床であり，時間の浪費でもある．git pushしたら本番が更新される仕組みを，GitHub Actionsで作ろう．

対象はVPSで手動デプロイしている個人開発者．読み終えたとき，CI/CDの全体像と最小構成のワークフローが手に入ります．

なぜ個人開発でもCI/CDを組むのか

手動デプロイは「手順を覚えている自分」に依存する．久しぶりに触ると手順を忘れ，ミスが入り，本番を壊す．

CI/CDは手順をコードに固定する．加えてpush時にテストを自動で回せるので，壊れたコードが本番に届く前に止められる．

全体像：push → テスト → デプロイ

パイプラインは(1)pushを検知 (2)テスト/ビルド (3)VPSへ反映の3段だ．まずはこの流れを頭に入れる．

VPSへの反映方式は大きく2つ．SSHしてgit pull＆再起動する素朴な方式と，イメージをビルドしてレジストリ経由で配る方式だ．まずは前者で十分始められる．

ステップ1：デプロイ用のSSH鍵とSecretsを用意

デプロイ専用のSSH鍵を作り，公開鍵をVPSに，秘密鍵をGitHubのSecretsに登録する．鍵をリポジトリに置いてはいけない．

登録するSecrets（例）

VPS_HOST   = サーバーのIP
VPS_USER   = deploy
VPS_SSH_KEY = 秘密鍵の中身

ステップ2：ワークフローを書く

.github/workflows/deploy.yml を作る．mainへのpushをトリガに，SSHでVPSに入りデプロイコマンドを実行する．

.github/workflows/deploy.yml

name: deploy
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USER }}
          key: ${{ secrets.VPS_SSH_KEY }}
          script: |
            cd /home/deploy/app
            git pull origin main
            docker compose up -d --build

ステップ3：テストを前段に挟む

デプロイの前にテストjobを置き，それが通ったときだけデプロイする．これで「壊れたコードの自動デプロイ」を防げる．

deploy job に needs を付ける

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test
  deploy:
    needs: test     # testが成功した時だけ実行
    runs-on: ubuntu-latest
    # ...（上のdeploy手順）

発展：self-hosted runnerでVPSを直接使う

ビルドが重い／プライベートな処理を完結させたい場合，VPSにself-hosted runnerを置く手もある．デプロイ先と実行環境が一致するので融通が利く．

ただし常駐プロセスが増えるぶん，メモリ・セキュリティ管理の負担も上がる．まずはGitHub側のrunner＋SSHで十分だ．

補論：自動デプロイ先のVPSは「速さ」と「巻き戻し」が要

自動デプロイは便利な反面，壊れた変更も自動で本番に届く．だからこそデプロイ先には「速いビルド」と「即座の巻き戻し」が欲しい．

高速NVMe・50種類以上のOSテンプレートに対応した国内VPS─シン・VPS─ はNVMe SSDでdocker buildやgit pullが軽快に進み，スナップショットでデプロイ前に戻すのも容易だ．self-hosted runnerを置く場合も，後からメモリを増やせるので拡張に困らない．

本番ドメインは 取り扱い400種類以上のドメイン取得サービス─ムームードメイン─ で取得しておけば，ステージング用のサブドメインも切りやすく，「検証→本番」の流れをきれいに作れる．

よくある質問

Q1：GitHub Actionsは無料で使える？

パブリックリポジトリは無料，プライベートも毎月の無料枠がある．個人開発の規模なら無料枠で十分回ることが多い．

Q2：デプロイに失敗したらどうする？

デプロイ前にスナップショットを取る運用にしておけば即巻き戻せる．加えてワークフローに簡単なヘルスチェックを入れると安全性が増す．

Q3：main直push運用は危険では？

個人開発なら許容範囲だが，ブランチ＋PRでテストを通してからmergeする運用にすると，自動デプロイの安全性が一段上がる．

まとめ ― 「git pushしたら本番が更新される」体験を手に入れる

CI/CDはデプロイ手順をコードに固定し，テストで守る仕組みだ．一度組めば，手作業の事故と消耗から解放される．

まずはSSHデプロイの最小ワークフロー1本から．pushしたら勝手に本番が動く瞬間を体験すれば，もう手動には戻れない．