目次（13項目）
本記事には広告（アフィリエイトリンク）を含みます。
掲載しているスペックや使用感は、実際に自分が契約・構築して運用しているサーバーで確認したものです。数値はスペック表の転記ではなく、稼働中のサーバーで計測した実測値を載せています。
「WordPressのブログと、自作のNext.jsアプリを両方公開したい。でもサーバーを2台借りるのはもったいない」
自分がまさにこれで悩みました。結論から言うと、XServer VPSの1台にDocker Composeで6サービスを立てて同居させています。月額費用はVPS1台分だけです。
この記事では、実際に動いている構成をそのまま書きます。とくにLet's Encryptの証明書とnginxの起動順は、順番を間違えると起動すらできなくなる箇所です。自分は運よく踏まずに済んだので、なぜ踏まなかったのかも含めて書きました。
—
使っているサーバーと構成
| 項目 | 内容 |
|---|---|
| VPS | XServer VPS 6GBプラン（Ubuntu 24.04 LTS） |
| CPU | 仮想4コア（実機は AMD EPYC-Milan） |
| メモリ | 6GB（`free -h` の実測で 5.8GiB） |
| ディスク | NVMe SSD 150GB（`df` の表示は145GB。現在31GB使用 / 22%） |
| swap | 2GB |
| 構築時間 | 半日 |
| Docker | Docker Engine + Compose plugin（apt の公式リポジトリから導入） |
| 稼働サービス | nginx / Next.js / PostgreSQL / Redis / WordPress / MariaDB の6つ |
数値はスペック表の転記ではなく、稼働中のサーバーで実際に計測した値です。構築は半日で終わりました。
ドメインは1つ取って、サブドメインで振り分けています。
- `example.jp` → WordPress（ブログ）
- `app.example.jp` → Next.js（管理画面）
なぜXServer VPSにしたか（さくら・ConoHaも使ってきました）
まず前提として、共有レンタルサーバーではDockerが動かないのでVPSは必須でした。
そのうえでVPSは、これまでにさくらのVPS（Webアプリ用）とConoHa（Webアプリとブログ）を使ってきて、今はXServer VPSに落ち着いています。
決め手は安定性でした。
誤解のないように書いておくと、さくらやConoHaに明確な不満があって乗り換えたわけではありません。 どれもちゃんと動きます。移った理由を強いて挙げるなら「今回の構成に合っていたから」という程度です。
そのうえで、3社を触ってきて自分がはっきり違いを感じたのは管理画面の分かりやすさの一点です。
- XServer: 目的の設定画面にすぐたどり着ける。迷わない
- ConoHa: 自分には少し分かりづらく感じた（慣れの問題かもしれません）
サーバーそのものの性能差より、毎回触る画面のストレスのほうが長く効いてきます。とくにVPSは自分で全部管理するので、管理画面を開く回数が多いです。ここは地味ですが選定基準に入れていい部分だと思います。
スペック面では、メモリ6GB / 4vCPUがこの用途にちょうど良かったです。常用メモリは2GB前後なので、ビルド時のピークも吸収できます。
🖥 XServer VPS
公式の案内では 4コア/4GBメモリ 月額1,700円〜。root権限が付くので、Docker・Minecraftサーバー・アプリ開発など用途を選びません。
※ 価格・プラン構成は変更されることがあります。最新は公式サイトでご確認ください。
—
メモリは6GBで足りるのか（実測値）
6サービスも立てて足りるのか不安でしたが、結論から言うと余ります。
稼働中のサーバーで `free -m` を叩いた実測がこれです。
“` total used free Mem: 5919MB 1616MB 1200MB ← 使用率 27% Swap: 2048MB 55MB “`
6GBに対して常用1.6GB、使用率27%です。 swapもほぼ使っていません（55MB）。
内訳の目安はこうなります。
| サービス | 常用メモリの目安 |
|---|---|
| nginx | 30〜60MB |
| WordPress（php-fpm） | 256〜512MB |
| MariaDB | 400〜600MB |
| Next.js | 256〜512MB |
| PostgreSQL | 256〜512MB |
| Redis | 64〜128MB |
これだけ余裕があるなら1つ下のプランでも動きそうに見えますが、ピークは常用値では測れません。 WordPressの更新とNext.jsのビルドが重なると跳ねます。うちでは各サービスに `mem_limit` を設定して暴走を防いでいます。
Redisは `maxmemory 128mb` + `allkeys-lru` で上限を切っています。
—
ネットワークは2つに分ける
ここは最初から分けておいて正解でした。
- edge: nginx ↔ 各アプリ
- internal: アプリ ↔ DB / Redis（`internal: true` で外部到達不可）
そしてDBのポートはホストに公開しません（compose に `ports:` を書かない）。PostgreSQLもMariaDBもnginx経由でしか触れない状態にしています。
VPSは立てた瞬間から総当たりを食らうので、DBを外に出さないのは最低限の防御です。実際、うちのアクセスログにも `/wp-config.php` や `/config/database.php` を狙うリクエストが毎日来ています。
—
nginxの振り分け設定
`app.example.jp` はNext.jsへプロキシします。
“`nginx server { listen 443 ssl; http2 on; server_name app.example.jp;
ssl_certificate /etc/letsencrypt/live/app.example.jp/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/app.example.jp/privkey.pem;
location / { proxy_pass http://nextjs:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; } } “`
`example.jp` 側はWordPress（php-fpm）へfastcgiで渡します。
“`nginx server { listen 443 ssl; server_name example.jp; root /var/www/html;
location ~ \.php$ { fastcgi_pass wordpress:9000; include fastcgi_params; }
location ~* /(wp-config\.php|xmlrpc\.php|\.ht|\.git) { deny all; } } “`
最後の `deny all` は入れておいてください。前述のとおり、狙ったリクエストが実際に来ます。
そして知らないホスト名で来たリクエストは444で切る設定も入れています。IPアドレス直打ちのスキャンをまとめて落とせます。
—
最大の落とし穴：nginxと証明書の順番
ここは事前に知らないと詰みます。
443のserverブロックは証明書ファイルが存在しないとnginxが起動しません。 しかしLet's Encryptで証明書を取るには `/.well-known/acme-challenge/` にHTTPでアクセスできる必要がある。つまり証明書入りのconfigを置いた状態でいきなり `docker compose up -d` すると、nginxが起動せず証明書も取れないという詰み方をします。
自分はここを踏まずに済みました。443のconfigを最初から置かなかったからです。
実際にやった順番
1. まず80番だけで起動する（443のserverブロックはまだ書かない） 2. certbotでhttp-01チャレンジを通し、証明書を取得する 3. 証明書ができてから443のserverブロックを追加し、nginxをreloadする
この順番なら詰まりません。半日で終わったのはこれが理由です。
作り直すならスクリプト化を推奨
ただし、この手順は手作業だと再現性がありません。 サーバーを作り直すたびに同じ順番を思い出す必要があります。
なので次に作るなら、「ダミーの自己署名証明書を置いてnginx起動 → certbotで本物取得 → 置き換えてreload」をスクリプト1本にまとめます。こうすれば443入りのconfigを最初から置いたままで一発で通ります。
—
証明書の自動更新は最初に入れておく
構築そのものは詰まらなかったのですが、ここだけはやらかしました。
証明書の取得までが順調にいったので満足してしまい、自動更新のcronを入れ忘れました。 Let's Encryptの有効期限は90日です。
気づいたのは期限の45日前。切れていたらブログと管理画面が同時に落ちていました。
“`cron 0 3,15 * * * cd /opt/myapp && bash scripts/renew-certs.sh >> /var/log/le-renew.log 2>&1 “`
証明書を取った直後に、同じ作業の中でcronまで登録してください。 「後でやる」は本当に忘れます。
—
地味にハマったこと：psqlにSQLファイルを流せない
DBマイグレーションを流すときに詰まりました。
“`bash
これは動かない
docker compose exec -T postgres psql -U user -d db -f /root/migration.sql “`
`-f` に渡したパスがコンテナ内のパスとして解決されるため、ホスト側のファイルは見つかりません。
“`bash
標準入力に流す
docker compose exec -T postgres psql -U user -d db < /root/migration.sql “`
こう書けば通ります。エラーメッセージが「そんなファイルはない」としか言わないので、原因に気づくまで少し時間を使いました。
—
ログでディスクを埋めない
Dockerのログはデフォルトだと無制限に増えます。VPSのディスクは有限なので、compose側で上限を切っておきます。
`json-file` ドライバの `max-size` と `max-file` を各サービスに設定すれば、古いログから自動で捨ててくれます。
うちのnginxは7日間で5万行以上のアクセスログが出ています（大半はヘルスチェックとクローラですが）。放置すると確実に効いてきます。
—
デメリット・注意点（正直に書きます）
いいことばかりではないので、実際に運用していて負担に感じる点も書いておきます。
OSとセキュリティの管理が全部自分の責任になる 共有レンタルサーバーなら業者がやってくれる部分を、自分でやることになります。前述のとおり、公開した瞬間から `/wp-config.php` を狙うスキャンが毎日届きます。ufwの設定、SSHの鍵認証化、不要ポートを開けない、といった基本は自分で担保する必要があります。
証明書の更新を自分で回す必要がある これは前述のとおりです。共有サーバーなら自動でやってくれます。
1台に集約している分、落ちるときは全部落ちる ブログとアプリを同居させているので、ホストに障害が出れば両方止まります。分けていれば片方は生きます。コストと引き換えのリスクです。
バックアップは自分で用意する必要がある これは正直に言うと、自分もまだ十分に整備できていません。DBのダンプを定期取得して別の場所へ退避する仕組みは、VPSを使うなら最初に入れるべきです（自戒を込めて）。
—
FAQ
共有レンタルサーバーではできませんか？
メモリ6GBは過剰ではないですか？
WordPressとアプリを同じサーバーに置いて大丈夫ですか？
構築にどれくらいかかりますか？
—
まとめ：この構成をおすすめできる人
- WordPressと自作アプリの両方を公開したい
- サーバー代は1台分に抑えたい
- Dockerの基本的な操作ができる
逆に、WordPressだけしか使わないなら共有レンタルサーバーで十分です。VPSはOSの管理もセキュリティ対策も自分の責任になるので、必要ないなら選ぶ理由はありません。
自分の場合はNext.jsアプリを動かす必要があったのでVPSを選びました。メモリ6GBあれば6サービス動かしても余裕があります。
構築は半日で終わりました。80番で起動 → 証明書取得 → 443を追加、この順番さえ守れば証明書まわりで詰まることはありません。あとは自動更新のcronを、証明書を取った直後に必ず登録すること。自分が唯一やらかしたのがここです。
—
🖥 この構成で使っているサーバー：XServer VPS
4コア/4GBメモリ 月額1,700円〜（公式の案内より）。root権限が付くのでDockerがそのまま動きます。自分は6GBのプランで、WordPressとNext.jsを含む6サービスを1台で動かしています。
※ 価格・プラン構成は変更されることがあります。最新は公式サイトでご確認ください。
