# VPS に Next.js をデプロイ: ビルドから HTTPS まで

アプリケーションはローカルで動作します。 VPS では、SSH 切断後も存続し、アセットを提供し、ドメインの背後でフォームを処理する必要があります。このガイドでは、実稼働ビルドから公開検証までのパスをたどります。

この例は、従来のビルドおよび開始スクリプトを使用する Next.js アプリケーション、systemd および既存の Nginx リバース プロキシを使用する Linux をターゲットとしています。パス、サービス アカウント、ドメインを環境に合わせて調整します。静的エクスポートとリクエストレンダリングされたアプリケーションには、異なるデプロイメントのニーズがあります。

## 識別可能なリリースを準備する

既知のコミット、そのロックファイル、およびインストールされている Next.js リリースと互換性のあるノード バージョンから開始します。 npm、npm の場合、ci はそのロックファイルから依存関係をインストールします。 pnpm または Yarn の既存のパッケージ マネージャーと再現可能なインストール モードを維持します。

実行中のサーバーの出力ディレクトリ内ではなく、リリース ディレクトリまたは CI 内にビルドします。ビルドではアプリケーション コードを実行し、サービスに接続できます。秘密を公開せずに、必要な変数を指定します。 NEXT_PUBLIC_ 値はブラウザ用であり、ビルド中に埋め込まれます。

```sh
node --version
npm ci
npm run build
```

## 実稼働サーバーをループバックで起動する

次回の起動時に起動スクリプトが実行されることを確認します。開発サーバーは実稼働環境に維持するプロセスではありません。 127.0.0.1 にバインドすると、サーバーとそのローカル プロキシへの直接アクセスが制限され、アプリケーション ポートがパブリック インターフェイスから切り離されます。

別の端末で、curl -i http://127.0.0.1:3000/ を使用して実際のページを検査します。そのコンテンツとアセットを確認してください。 [出力: スタンドアロン] を選択した場合は、生成されたserver.js とその予想されるディレクトリ構造 (public および .next/static を含む) を使用します。このモードには独自のエントリポイントがあります。

```sh
npm run start -- --hostname 127.0.0.1 --port 3000
```

## systemd にプロセスを管理させます

systemd ユニットは、セッションとは独立してサービスを実行します。この例では、既存の Web アプリ アカウントと /srv/my-next-app でのリリースを前提としています。コマンド -v node でノードのパスを確認し、ExecStart を調整します。アカウントはリリースを読み取り、それを必要とするアプリケーションの場所にのみ書き込む必要があります。

サービス アカウントに適切なアクセス許可を持つサーバー変数を環境ファイルに保持します。環境にユニットをインストールした後、systemd-analyze verify で検証し、systemd をリロードしてサービスを開始します。起動に失敗した場合は、ジャーナルを調べてください。自動再起動は、メモリ関連の終了の調査に代わるものではありません。

```ini
[Unit]
Description=My Next.js application
After=network.target

[Service]
Type=simple
User=webapp
WorkingDirectory=/srv/my-next-app
Environment=NODE_ENV=production
EnvironmentFile=/etc/my-next-app.env
ExecStart=/usr/bin/node /srv/my-next-app/node_modules/next/dist/bin/next start --hostname 127.0.0.1 --port 3000
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
```

## ドメインをアプリケーションにルーティングする

ドメインのサーバー ブロック内で、ロケーションはリクエストをローカル アプリケーションに転送できます。次のフラグメントでは、HTTP とストリーミングについて説明します。それを既存の構成と統合し、リロードする前に nginx -t を実行します。これは完全な TLS 構成ではありません。

ドメインは VPS に解決され、更新が有効な有効な証明書を持っている必要があります。アプリケーションのホストと元のプロトコルを保持します。共有動的応答キャッシュなしで開始します。プライベート ページ、Cookie、ナビゲーション バリアントには明示的なポリシーが必要です。アプリケーションが WebSocket を使用する場合は、適切な Nginx Upgrade ヘッダー処理を個別に追加します。

```nginx
location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_buffering off;
}
```

## 公開サイトを確認する

ホームページからの 200 応答では、アプリケーション全体が検証されるわけではありません。動的ルート、欠落ページ、ログイン、ログアウト、フォームを実行します。ブラウザーでリダイレクト、セキュア Cookie、画像、ナビゲーションを確認します。

ストリーミング ページもテストします。コンテンツがドメイン経由で一度に到着するが、ループバックで徐々に到着する場合は、すべての仲介者でのバッファリングを調べてください。トラフィックを切り替える前に、以前のリリースとその設定を保持します。アプリケーション コードを元に戻すには、データベース移行との互換性も必要です。

## 導入の規模を拡大し、進化させる

アイドル状態のメモリ、トラフィックのピーク、展開の重複を測定します。 2 つのリリースは一時的に共存でき、VPS 上に構築すると独自のピークが追加されます。データベースとプロキシも総予算に含まれます。

PRNext を評価するには、Next.js 参照を保持し、別のディレクトリに候補を構築します。ランタイムを変更する前に、アプリケーションの動作とパフォーマンスを確認してください。

[Next.js の VPS メモリのサイズを設定する](/ja/blog/nextjs-ram-vps-sizing)

[移行前に PRNext の互換性を確認してください](/ja/blog/prnext-nextjs-compatibility-migration)

## Sources

[Next.js: self-hosting](https://nextjs.org/docs/app/guides/self-hosting)

[Next.js: environment variables](https://nextjs.org/docs/app/guides/environment-variables)

[Next.js: standalone output](https://nextjs.org/docs/app/api-reference/config/next-config-js/output)

[systemd: service units](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html)

[Nginx: proxy module](https://nginx.org/en/docs/http/ngx_http_proxy_module.html)

発行済み: 2026-10-30

修正済み: 2026-10-30

著者: PRNext

---

言語: ja

Canonical: https://prnext.dev/ja/blog/deploy-nextjs-vps

Index: https://prnext.dev/llms.txt