小規模アプリはどこで動かすか:静的配信・PaaS・自己管理VPS

公開日: 2026-09-14 / 用途・置き場所 #Astro #Cloudflare Workers #PaaS #契約前の確認

小規模アプリの置き場所は、自分でコードを書いたかどうかでは決まらない。必要な機能を、事業者が運用する機能(マネージド機能)で満たせるかを先に照合し、それでもOSやネットワークを自分で設定する必要が残る場合に自己管理VPSを選ぶ。WebSocket、常駐する処理、データの保存が必要というだけでは、自己管理VPSに決まらない。

選ぶ前に埋める要件票

項目 書き出す内容
配信 ビルド時に確定するページで足りるか、アクセスのたびに内容を作るページがあるか
1回の処理 計算にかかる時間と、外部APIやデータベースを待つ時間はそれぞれどれくらいか
常駐する処理 リクエストとは別に動き続ける処理(キューの処理、WebSocketの接続維持など)があるか
データの保存 データベース、アップロードファイル、セッションをどこに永続させるか
台数 複数の実行インスタンスに増やす可能性があるか
OSとネットワーク カーネルやファイアウォール、独自のネットワーク構成など、OSを自分で設定する必要があるか
保守の担当 実行環境の更新、障害対応、復元を誰が行うか

静的配信で足りるか

Astroは、サイト全体をビルド時にHTMLとして出力する方法と、ページをアクセスのたびに生成するオンデマンドレンダリングを分けている。後者を使うには、実行先に合わせたアダプターが必要になる(Astro Docs: On-demand rendering)。ログインで内容が変わるページやフォームの受付がなければ、静的配信だけで済むことが多い。

フォームの送信先や検索など一部だけが動的なら、静的配信と外部のAPIやFunctionsを組み合わせる。ページ全体をサーバーで動かす理由にはならない。

Functionsで足りるか:リクエストごとに実行する

CloudflareのPages Functionsは、専用サーバーを動かさずにCloudflare Workersの上でコードを実行する仕組みとして説明されている(Cloudflare Docs: Pages Functions)。

Workersの制限は、CPU時間と経過時間を分けて読む。CPU時間には上限があり、外部APIやデータベースの応答を待つ時間はCPU時間に含まれない。一方、HTTPリクエストで起動した処理は、応答が終わったりクライアントが切断したりすると、関連する処理が打ち切られることがある(Cloudflare Docs: Workers Limits)。計算の重さと、応答後に続けたい処理の有無を要件票で分けておく。上限の値はプランで異なるため、候補サービスの現行の資料で確かめる。

Workerのメモリや、Node.js互換の/tmpは永続保存先ではない。Cloudflareは/tmpのファイルがリクエストごとに独立し、残らないと説明している(Cloudflare Docs: fs)。データは同社のKV、R2、D1、Durable Objectsなど、保存用の機能に置く。

WebSocketも、それだけで常駐サーバーが要るとは限らない。Durable ObjectsはWebSocket接続を扱え、Hibernation APIを使うと、何も起きていない間はオブジェクトがメモリから外れても、クライアントの接続は維持される。ただしその間はメモリ上の状態が消えるため、接続ごとに保存する仕組みで状態を戻す(Cloudflare Docs: Durable Objects WebSockets)。

常駐できるPaaSで足りるか

PaaSには、リクエストごとに起動するものだけでなく、プロセスを動かし続けるサービスもある。RenderのBackground Workerは、外部からの通信を受けずに動き続け、キューを見て処理する用途向けと説明されている(Render Docs: Background Workers)。

ディスクの扱いは永続と一時を区別する。Renderのサービスは標準では一時的なファイルシステムで、再デプロイや再起動でファイルの変更が失われる。有料のサービスには永続ディスクを追加でき、残るのは指定したマウント先の変更だけで、ディスクを付けたサービスは複数インスタンスに増やせない。データベースはマネージドのPostgreSQLなどが合うなら、そちらを勧めている(Render Docs: Persistent Disks)。要件票の「データの保存」と「台数」を同時に見る。

確認日: 2026年9月14日(この節までの出典すべて)。ここで挙げたのは仕組みを確かめるための例で、サービスの推奨ではない。

自己管理VPSが候補に残る場合

マネージド機能を照合しても、OSやネットワークを自分で設定する必要が残り、実行環境の更新・監視・復元を担当する人が決まっているなら、自己管理VPSが候補になる。担当が決まらないなら、要件のどれを変えればマネージド機能に収まるかを先に検討する。

要件票から選ぶ

  1. 配信がビルド時に確定する → 静的配信
  2. 一部だけ動的で、処理が短く、保存先をマネージド機能で用意できる → 静的配信+FunctionsやAPI
  3. 動き続ける処理や永続ディスクが要り、候補サービスの制約(台数、マウント先など)に収まる → 常駐できるPaaS
  4. OSやネットワークの設定が必要で、保守の担当がいる → 自己管理VPS

候補を回答から確かめるなら自己管理VPSを契約するか決める前の確認ツール、自己管理VPSが残って契約条件を比べる段階ならVPSの契約条件を比較するへ進む。外部サービスからの通知を受けるならWebhookを受信する前に確認することも合わせて埋める。

参考資料(確認日: 2026年9月14日)