2026年10月30日ブログ

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

PRNext

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

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

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

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

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

Terminal

node --version
npm ci
npm run build

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

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

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

Terminal

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

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

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

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

my-next-app.service

[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.conf

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、画像、ナビゲーションを確認します。

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