手元で動くWebアプリを公開するなら、VPSを借りて自分で動かす方法と、PaaSにアプリを預けて動かす方法があります。どちらでも公開URLを持てます。違いを実感するのは、コードを更新する日と、アプリが止まった日です。
VPSとPaaSで、誰が何を管理するか
VPSは仮想サーバーを借りる方式です。LinuxのサーバーにSSHで入り、実行環境や起動方法を整えます。たとえばDigitalOceanのDropletでは、サーバー作成後にSSHで接続し、利用目的に合わせて設定します。DigitalOcean公式の初期セットアップ
PaaSは、アプリを実行する環境の管理をサービス側に任せる方式です。利用者はコード、起動コマンド、環境変数などを設定します。たとえばRenderは接続したGitブランチから自動デプロイできます。Render公式のデプロイ仕様
仮想サーバーを借り、OS・起動・配布を開発者が設定。
事業者が実行基盤を提供。開発者はアプリと依存関係を管理。
| 運用するもの | 一般的なVPS | Git連携型のPaaS |
|---|---|---|
| OS・ミドルウェア | OSのパッチ、リバースプロキシ、アプリ実行環境を管理 | プラットフォームが実行基盤を管理。アプリの依存関係や自作イメージは開発者が更新 |
| コードの更新 | 配布、再起動、失敗時の切り戻しを設計 | ビルドと配置の仕組みを利用。公開後の動作確認は開発者が担当 |
| 障害時の切り分け | サーバーの状態とアプリのログの両方を調べる | デプロイ履歴、アプリのログ、サービスの稼働状況から調べる |
| データの保護 | DBを同居させるならバックアップと復元も設計 | 外部DBやマネージドDBを選べる。保持期間と復元手順は契約や設定ごとに確認 |
同じNode.jsアプリを1回更新するとどう違う？
たとえばサークルの備品予約アプリで、画面の文言を直すとします。VPSなら、初回公開で用意した手順に沿ってサーバーへ新版を配置し、プロセスを切り替えます。GitHub Actionsなどで自動化する場合も、権限の設定、配置失敗時の扱い、元の版への戻し方を決めます。
PaaSなら、対象ブランチへのpushを起点にできるサービスがあります。公開URLで直した箇所を見て、デプロイ履歴のコミットと照合します。DBのスキーマ変更を伴う場合はどちらでも手順が別に要ります。コードだけ戻しても、DBの変更はそのまま残るためです。Render公式の自動デプロイ
push → 自分の配置手順 → プロセス切り替え → 公開URLを確認
push → 事業者のビルドと配置 → 公開URLを確認
KamuiDashはGitHubからWebサーバーをデプロイできるPaaSの例です。Node.jsアプリならリポジトリ、起動コマンド、環境変数を設定し、デプロイ結果を確認できます。KamuiDash公式のNode.js設定
更新直後に予約画面が開かなかったら
VPSではアプリのプロセスが起動しているか、次にリバースプロキシのログでアプリへの接続に失敗していないかを調べます。PaaSではデプロイ履歴で公開中の版を確認し、アプリのログで起動時のエラーを探します。コードの変更で説明できなければ、事業者の稼働状況も確認します。
何を触りたいかで決める
OSの設定を学びたい、独自のネットワーク設定が必要、複数プロセスの配置を自分で決めたいなら、VPSを選ぶ理由があります。予約アプリのように標準的なHTTPサーバーで動き、開発時間を機能追加に回したいなら、PaaSを候補にできます。常時起動が必要か、再起動後に残すファイルはあるか、裏で動かすジョブはあるかを先に確認すると、PaaSのプランを絞れます。たとえばRenderの無料Webサービスは無通信で停止し、ローカルに書き込んだファイルは再起動などで失われます。Render公式の無料枠
料金を見るときは、月額に加えて、DB・バックアップ・通信にいくらかかるかを同じ条件で並べます。さらに、OS更新や復元確認を誰がいつ行うかを決めます。月に一度のメンテナンスでも、引き継ぐ人が分からなければ運用は続きません。
あわせて読みたい
GitHubからWebアプリを公開する方法は、KamuiDashで確認できます。