作ったアプリを公開しようとサーバーを探すと、最初につまずくのがプラン選びです。
1GB
2GB
4GB
8GB
数字が並んでいるだけで、自分にどれが必要なのかが分からない。 私もそうでした。
安いプランで始めて足りなくなったら上げればいい、と考えて 2GB を選びました。VPSの稼働46日目に平常時を測った、私の環境の記録です。
先に、答えだけ
私の構成では、2GBで動きました。 確認したのは46日目の平常時です。アクセスが増えたときや別のアプリにも足りるかは、まだ分かりません。
実際に確認したこと
- Django / Next.js / PostgreSQL など6つのコンテナを、Docker Composeで動かしていた
- 2026年8月13日の平常時は、コンテナ合計333MiB、load 0.34だった。同日に確認したVPSの
uptimeは46日で、各コンテナの連続稼働日数ではない - 8月30日のキャッシュ無しビルドも1回成功した。ただしスワップは140MiB増え、ビルド中のサービス状態は確認していない
余裕を取るなら、4GB以上も候補にする場面
- サーバーの上で
next buildのようなビルドを回す - これからコンテナを増やす予定がある
こちらは推定です。4GBでは測っていないため、必要最小容量も4GBでの成功も未確認です。
先に決めたいのは、何を動かすか、ビルドも同じVPSで行うか、どのくらい余裕を残すかです。ビルドを外へ出しても、アプリの稼働に必要な容量は残ります。
ここから下は、平常時の記録と後日のビルド計測です。限界に届くまで負荷を増やした場合は、どちらも測っていません。
そもそもVPSのプランは何が違うのか
VPS（仮想専用サーバー）のプランは、主に3つの数字で分かれています。
| 項目 | 何を決めるか |
|---|---|
| メモリ（RAM） | 同時に動かすプログラムや処理のための作業領域 |
| CPU（コア数） | 処理を進める計算資源。処理内容や同時アクセスで必要量が変わる |
| ディスク（SSD） | アプリ、DB、ログ、イメージなどを保存する領域 |
「2GBプラン」という名前でも、確認したいのはメモリだけではありません。CPUやディスクの割り当ても、各社の仕様を見ます。
この記事では主にメモリを見ます。CPUを使う処理が多いアプリや、DB・画像・ログが増える構成では、その分も別に見積もる必要があります。
何を動かしているか
私が公開しているのは、記事を配信するWebサイトです。次のプログラムが常に動いています。
| 動いているもの | 役割 |
|---|---|
| Next.js | 画面を表示する部分（フロントエンド） |
| Django | データを処理する部分（バックエンド） |
| PostgreSQL | データを保存するデータベース |
| nginx | 外からのアクセスを受け取って振り分ける窓口 |
| certbot | HTTPS（鍵マーク）の証明書を自動更新する |
| redis | よく使うデータを一時的に覚えておく |
これらは Docker のコンテナとして動かしています。
測ったのは2026年8月13日、VPSの uptime が46日だった時点の平常時です。使ったのは docker stats / free -h / docker system df の3つだけで、負荷をかけたり、わざと重くしたりはしていません。
実測1：私の構成の平常時には余裕があった
実際に測った結果です。
| コンテナ | メモリ使用量 | 2GBに対する割合 |
|---|---|---|
| Next.js（フロントエンド） | 201.7 MiB | 10.26% |
| Django（バックエンド） | 75.6 MiB | 3.85% |
| certbot | 27.6 MiB | 1.40% |
| PostgreSQL | 12.7 MiB | 0.64% |
| nginx | 12.4 MiB | 0.63% |
| redis | 3.0 MiB | 0.15% |
| 合計 | 約 333 MiB | 約 17% |
6つ全部合わせて 333MiB。2GB に対して17%しか使っていません。
サーバーの忙しさも測りました。
$ uptime
10:05:58 up 46 days, 10:59, 1 user, load average: 0.34, 0.24, 0.20
46日目の確認時点で、loadは0.34。 この時点では負荷が低い状態です。46日間ずっと同じ負荷だったという記録ではありません。
ここまでの数字から言えるのは、この時点の私の構成には余裕があったことです。
実測2：ただし、スワップが294MiB使われていた
次に、サーバー全体のメモリを見ます。
$ free -h
total used free shared buff/cache available
Mem: 1.9Gi 778Mi 139Mi 5.0Mi 1.2Gi 1.2Gi
Swap: 2.0Gi 294Mi 1.7Gi
まず見るのは available（新しい処理に使えるメモリの見積もり）です。ここは1.2Giあり、この時点では余裕がありました。負荷が変わると値も変わるので、この1回だけで必要容量を確定はできません。
引っかかるのは最後の行です。
294MiB がスワップに逃がされていました。
逃がされたページは、また必要になればメモリへ読み戻されます。ただし、使用量の数字のほうは、メモリに余裕ができただけでは自動的にゼロには戻りません。
つまりこの294MiBは「いま294MiB足りていない」ではなく、「過去のどこかで、いったんディスクへ逃がす場面があった」ことを示しています。
常時動いているのが合計333MiBであることを考えると、これを押し出したのは普段の動作ではなさそうです。一時的に大きくメモリを使った処理があったのだろう、と考えました。
心当たりは1つありました。
実測3：ディスクの8割がビルドキャッシュだった
Docker がディスクをどう使っているかを見て、原因の輪郭が見えました。
| 種類 | 個数 | サイズ |
|---|---|---|
| イメージ | 6 | 3.7 GB |
| コンテナ | 6 | 6 MB |
| ボリューム | 8 | 609 MB |
| ビルドキャッシュ | 357 | 28.9 GB |
ビルドキャッシュだけで 28.9GB。 ディスク使用量37GBの、およそ8割です。
私はコードを更新するたびに、本番サーバーの上で next build を実行していました。測定時点ではビルドキャッシュが357個ありました。ただ、この集計値だけでは、それぞれがいつ、どのビルドでできたかまでは分かりません。
つまり、こういうことでした
2GBで「動かす」 → 46日目の平常時には余裕があった（合計333MiB、load 0.34）
2GBで「ビルドする」→ 8月13日時点では未測定（後日の結果は下の追記）
この時点では、サイトが落ちたことや表示が遅くなったことを確認したわけではありません。キャッシュの蓄積とスワップ使用量が気になり、ビルド時も別に測ることにしました。
プラン選びでは、稼働時に加えて、同じサーバーで行うビルド時のメモリも見たい。 平常時の数字だけでは更新時の余裕が分からなかったからです。
では、あなたは何GBを選べばいいか
ここから先は実測ではなく、上の数字からの推定です。4GBで動かして比べたわけではないので、そこは区別して読んでください。
実測から確実に言えるのは、次の2点です。
- 私の構成の46日目の平常時には余裕があった（合計333MiB、load 0.34）
- スワップが294MiB使われていた（その原因の内訳や、物理メモリが尽きたかは不明）
8月30日のビルドは1回成功し、その間にスワップは140MiB増えました（上の追記）。元の294MiBの原因や、負荷を増やしたときの限界は分かっていません。
そのうえで、選び方の手順としてはこうなります。
手順1：サーバーの上でビルドするかどうかを決める
サーバーの上でビルドするなら、稼働中のアプリとビルドが同時に使う分を考えます。私の2GB環境では1回通りましたが、同時アクセスや処理が増えた条件では試していません。
別環境でビルドして結果を配るなら、そのビルド処理はVPSから外せます。ただし、アプリやDBを動かすメモリは必要です。「外でビルドするなら2GBで足りる」とは一律に決められません。
手順2：余裕と、あとから変更する条件を考える
同じサーバーでビルドもしたい、これから処理を増やしたいなら、私は4GB以上も候補にします。これは余裕を取るための推定で、4GBが必要だと測って決めた結論ではありません。4GBなら足りるという保証もしていません。
止める時間が要ります。前の記述では「データがそのまま残るかどうかは公式に明記がありません」と書きましたが、ConoHa VPSの公式FAQには、プラン変更時のデータは引き継がれると明記されていました（2026年9月23日確認）。この点は訂正します。 ただし、私はプラン変更も復元も試していません。契約タイプ・世代ごとの手順を管理画面と公式案内で確認し、変更前にバックアップを取ってください。
公式のプラン変更手順には、VPS割引きっぷが設定されている場合、VPSと連動してきっぷもプラン変更されると書かれています。割引きっぷを使っているなら、変更後の料金も確認してください。
容量を上げる選択と、外部ビルドに分ける選択の両方を考え、運用の手間も含めて決めます。
手順3：ディスクにも、増えていくものの余裕を残す
私の場合、37GB使っているうちの28.9GBがビルドキャッシュでした。ただし、DB、画像、ログ、バックアップをどこに置くかで必要量は変わります。100GB前後あれば誰にでも足りるとは言えません。
掃除をするなら、まず削除対象と再作成への影響を確認します。共有ホストでDocker全体を一括削除したり、DBのボリュームまで消したりしないでください。この記事は削除コマンドの実行を勧める手順ではありません。
もう1つの選択肢：ビルドをサーバーから外す
プランを上げるほかに、ビルド自体をサーバーの外に出す方法があります。
まず、別PCやCIでサーバーアプリの成果物・Dockerイメージを作り、VPSへ配って動かす形があります。アプリは引き続きVPS上で動きます。Next.js 15のSelf-Hostingにもイメージの環境間配布が説明されていますが、私のVPSアプリで外部ビルドから配布・稼働まで試した記録はありません。動かす環境とビルド時・実行時の設定を合わせる必要があります。
もう1つは、静的ファイルを書き出して配信する形です。このサイト（prodnote.dev）はNext.jsの静的エクスポートを使い、Cloudflare Pagesがビルドと配信を行います。私のVPSには、このサイトを動かす処理も置いていません。
外でビルドすることと、静的配信だけで完結させることは別です。 静的エクスポートには、Next.js側で受信リクエストを処理できないという制約があります。
- 作るときにDBやAPIから読んだ内容を、HTMLへ書き出すことはできます
- ブラウザーから別のAPIを呼んで、表示する内容を変える構成も可能です
- リクエストごとのサーバー処理やServer Actionsなどは、静的ファイルだけでは実行できません
これはNext.js 15のStatic ExportsのServer Components、Client Components、Unsupported Featuresを確認した整理です（2026年9月8日）。
ログインや投稿フォームがある場合も、画面を静的配信し、認証や保存を別のAPIへ任せる設計はできます。そのAPIやDBの置き場所・運用は別途必要です。DBがあるだけで静的配信を除外したり、ビルドを外へ出しただけでVPSが不要だと考えたりしないようにします。
まとめ
- 私の構成の平常時には余裕があった。 46日目に6つ合わせて333MiB、load 0.34
- ビルド中にもメモリの動きを確認した。ただし限界は未測定。 8月13日のスワップ294MiB、ビルドキャッシュ28.9GB（ディスクの8割）とは分けて読む。
2026年8月30日に測り直したところ、ビルド中にスワップは140MiB増えましたが、
availableは470MiB残り、 ビルドは終了コード0で終わりました（上の追記を参照） - 容量は稼働時とビルド時を分けて考える。アクセスが増えたときの限界は未測定
- 4GB以上は余裕を取る候補という推定。 4GBでの比較実測はなく、外部ビルドなら2GBで足りるとも保証できない
- 外部でビルドしてVPSで動かす方法と、静的出力を配信する方法は別の選択肢
次にやること
はじめて借りるなら、次の順で条件を確認します。
- 動かすものとビルド場所を決め、容量の余裕を考える（この記事の実測だけで必要最小容量は決まらない）
- プラン変更・試用・解約の条件を確認して契約する（変更の可否や停止の要否は事業者・サービス世代による）
- 借りたらすぐ、セキュリティの初期設定をする ← ここを飛ばさないでください
3番目が特に大事です。ただし、どこまで外に開いた状態で始まるのかは、事業者と世代で違います。 ConoHa の現行世代（Ver.3）の公式ドキュメントには、「例外を除き」と断ったうえで、既定では同じテナント内のサーバーからの通信だけを通し、外部から届かせるには許可設定が要ると書かれています（2026年8月29日確認）。
だからこそ、思い込みではなく自分の環境で確かめるところから始めてください。 レンタルサーバーと違い、OSの設定も自分で面倒を見る必要があります。
（2026年8月29日訂正：この段落は当初「VPSは借りた瞬間から、インターネットに公開された状態になります」と断定していました。事業者と世代によって違うため、書き直しています。同じ書き方をしていた別の記事とトップページも直しました。）
私の場合、公開してしばらく経ってから、rootでのログインを禁止し、パスワードではなく鍵でログインする形に変更しました。最初にやっておくべきだったというのが正直なところです。その手順は別の記事にまとめました。