Next.jsをVercel以外で動かすには？

Next.jsで作ったアプリは、Render、Railway、Google Cloud Run、Cloudflare Workers、KamuiDashなどにも公開できます。ただし、選ぶサービスによって実行方式や、自分で設定する範囲が変わります。

まず、静的なページだけで足りるのか、リクエストごとのサーバー処理が必要なのかを分けます。その上で、主要な公開先の方式と選び方を比較し、Node.jsで動かす具体例としてKamuiDashの設定を説明します。

サンプル一式をダウンロードできます。画面に生成時刻を表示するだけの小さなApp Routerのアプリで、DBやログインは含みません。後半の手順は、このサンプルをNode.jsサーバーで公開する場合のものです。

最初に、必要な実行方式を選ぶ

Next.jsの公式デプロイ資料では、Node.jsサーバー、Docker、静的出力などの方式が案内されています。

会社紹介や作品一覧など、ビルド時点でHTMLを作れば足りるサイトは静的出力を検討できます。一方、リクエストごとの認証やDB読み取りなど、サーバー側の実行が必要なアプリはNode.jsサーバーが候補です。静的出力には利用できない機能があるため、リクエスト時のCookie参照やISR（増分静的再生成）を使う場合は静的出力できません。Next.js公式の制約一覧で、利用中の機能を確認できます。静的出力を使う場合は output: 'export' を設定し、ビルドで生成された out/ を配信します。

Cloudflare Workersのように、通常のNode.jsサーバーとは異なる実行環境へ合わせる方法もあります。この場合は、利用中の機能やライブラリの互換性を、選ぶ実行方式に沿って確認します。

Vercel以外の主な公開先を比較する

ここでは、GitHubから配置するPaaS、コンテナーを使うクラウド、Workersの5サービスを取り上げます。すべての公開先を網羅した一覧ではなく、実行方式と運用の条件を見分けるための比較です。

この表の「選ぶ理由」は用途に応じた判断の入口です。どのサービスも、同じNext.jsアプリが同じ設定・料金で動くと考えず、必要な機能と運用を照合します。

Node.jsの構成を使うなら、Render・Railway・KamuiDash

next buildとnext startを使う構成を考える場合の候補です。Renderの公式ガイドは、サーバー処理を使うWebサービスと、静的出力を配る静的サイトを分けています。Railwayにも、GitHubリポジトリからの配置と環境変数の移行を説明する公式ガイドがあります。

この3つから選ぶときは、必要なリージョン、スリープの条件、ビルドと実行のリソース、DBの置き場所、継続費用を揃えて比べます。たとえば初回アクセスの待ちが困るなら、無料Webサービスのスリープまで含めて構成を選びます。

KamuiDashは東京リージョンのNode.jsサーバーとマネージドPostgreSQLを使う場合の候補です。ただし、最小プランのメモリで自分のアプリが足りるかや、必要なビルド時環境変数を渡せるかは確認が必要です。後半の設定例で、その確認項目を具体化します。

Google Cloudの運用へ組み込むなら、Cloud Run

Cloud Runはコンテナーを実行する方式で、公式には既存のNext.jsアプリをソースからビルドして配置する手順もあります。自分でDockerfileを用意する方法だけに限られません。

利用にはプロジェクト、課金、IAMなどの準備が必要です。アクセスに応じたインスタンスの自動スケーリングもあるため、起動待ち、同時処理数、最大インスタンスとDB接続数を一緒に考えます。すでにGoogle Cloudを使っているなら、その運用と統合できるかが選ぶ理由になります。

Workersを使うなら、Cloudflareの対応方式を確認する

Cloudflareの現在の公式ガイドは、Workers向けの公開経路としてvinextを推奨しています。vinextはNext.jsのAPIをVite上で実装する方式で、通常のNode.jsでnext startする構成と同じ扱いにはしません。

2026年11月2日時点で、vinextはbeta段階です。既存の本番アプリで採用する前に、公式が案内するnpx vinext checkと互換性の対応表で、使用する機能とパッケージを確認します。推奨方式という説明だけで、必要な機能がすべて同じように使えるとは判断しません。

既存OpenNextアプリのための案内も残されていますが、古い記事のOpenNext手順をそのまま現在の推奨方法だと受け取らず、公式の現行ガイドを起点にします。静的出力だけを配信する場合は、別の経路としてCloudflare Pagesの手順があります。

自分のアプリで、移行前に確かめること

サービス名を選ぶ前に、次の条件を書き出すと候補を絞れます。

1. SSR、Route Handlers、Server Actions、画像最適化、ISRなど、使用中の機能は何か。
2. DBや外部APIがどこにあり、接続方式やリージョンに制約があるか。
3. ビルドと実行に必要なNode.jsの版・メモリ・CPUを用意できるか。
4. GitHubのプレビュー環境、キャッシュ、監視など、現在の公開先で使っている機能をどう引き継ぐか。
5. アプリに加え、DB・通信・ビルド・ドメインを含む継続費用が予算に合うか。

Vercel固有の周辺サービスを使っている場合は、その接続やデータの移行も別に必要です。Next.jsのコードを配置できることだけで、すべての機能の移行が済むわけではありません。

ここからは、Node.jsサーバーで動かす構成を選んだ場合の具体例として、KamuiDashでの設定を見ます。リクエスト時にページを生成するサンプルなので、静的WebページではなくNode.jsのWebサーバーとして配置します。

ビルドと起動を、ローカルでも分けて試す

サンプルは次の構成です。フォルダーの中身をリポジトリのルートへ置く想定です。

package.json
package-lock.json
app/
  layout.js
  page.js
  healthz/route.js

package.jsonは次のとおりです。掲載版ではNext.js 16.4.3を使用し、このバージョンのNode.js要件は20.9以上です。実際の配置先でも対応するNode.jsのバージョンを確認してください。enginesを書くだけで、すべての環境のNode.jsを切り替えられるわけではありません。

固定バージョンはローカル検証時の記録です。インターネットに公開する前に、Next.jsの2026年11月セキュリティ更新のお知らせを確認し、修正済みバージョンに更新してロックファイルを反映し、再ビルドしてください。

{
  "name": "next-node-hosting-demo",
  "version": "1.0.0",
  "private": true,
  "scripts": {
    "dev": "next dev -H 0.0.0.0",
    "build": "next build",
    "start": "next start -H 0.0.0.0"
  },
  "dependencies": {
    "next": "16.4.3",
    "react": "19.2.0",
    "react-dom": "19.2.0"
  },
  "engines": { "node": ">=20.9.0" }
}

next devは開発用です。公開時は、ローカルでも本番と同じbuildとstartを試します。Next.jsのCLIはPORTによるポート指定をサポートします。公式CLI資料が確認先です。

npm ci
NEXT_PUBLIC_DEMO_LABEL='build-example' npm run build
PORT=3000 DEMO_SERVER_MESSAGE='runtime-example' npm run start

http://127.0.0.1:3000/と/healthzを開きます。前者には生成時刻と2つのラベル、後者には{"ok":true}が表示される想定です。生成時刻が再読込で変わるよう、ページは次の設定にしています。

export const dynamic = 'force-dynamic';
export default function Page() {
  return <main><h1>Next.jsをNode.jsで動かす</h1><p>このページはリクエスト時にサーバーで描画します。</p><p>生成時刻：{new Date().toISOString()}</p><p>公開用ラベル：{process.env.NEXT_PUBLIC_DEMO_LABEL || '未設定'}</p><p>サーバー専用の設定：{process.env.DEMO_SERVER_MESSAGE || '未設定'}</p></main>;
}

ここで表示しているDEMO_SERVER_MESSAGEは、公開してよい説明用の文字列です。サーバーで読んだ値も、HTMLやJSONに出せば閲覧者に渡ります。DBの接続情報や秘密のキーを同じように画面へ表示してはいけません。

環境変数は、いつ読む値なのかを区別する

NEXT_PUBLIC_で始まる値は、ビルド時にブラウザ用のJavaScriptへ埋め込まれます。公開してよい値に限定し、変更したら再ビルドします。単にアプリを再起動するだけでは、すでに作った成果物の値は変わりません。

サーバー側の環境変数でも、静的に生成するページがビルド時に読む値なら、実行時だけ設定しても間に合いません。「サーバー用だからすべて起動時に読まれる」とまとめず、コードがいつ実行されるかで分けます。セルフホストの環境変数の説明にも、この区別があります。

KamuiDashでビルド時の値を渡す場合

ビルド時に環境変数を使うアプリは、利用中のKamuiDashの設定がその工程へ値を渡せるか確認してから進めます。実行時環境変数が、ビルド時にも自動で利用できると仮定しません。

このサンプルのNEXT_PUBLIC_DEMO_LABELは省略可能です。指定しなければ「未設定」と表示されるので、秘密値やビルド時変数を使わない最小構成で公開手順を確かめられます。

KamuiDashに設定する項目

KAMUIDASH · SCREENSHOT

この配置はKamuiDashのNode.js設定を、Next.js用のビルド処理に合わせた例です。モノレポではapps/webなど対象のディレクトリを指定し、その中にあるpackage.jsonからコマンドを実行する構成に揃えます。

公開後に、ページとAPIの両方を見る

デプロイが完了したら、発行されたURLの/と/healthzを確認します。ステータスコードと画面の内容を分けて見てください。HTMLが返っていても、画像・スクリプト・APIの一部だけ失敗することがあります。

KAMUIDASH · SCREENSHOT

安いプランで起動できることと、自分のアプリが安定して処理できることは別です。小さな例が動いても、実際のページ、画像処理、同時アクセスを含めて必要なメモリやCPUを確認します。

複数台へ増やす前に、状態の置き場所を見る

Next.jsのセルフホストは、単一のNode.jsプロセスから始められます。ただし複数のレプリカでは、キャッシュや再検証の情報をどう共有するか、デプロイ中に異なる版が混在したらどうなるかなどを考えます。Vercel固有の周辺サービスを利用している場合も、置き換えが必要です。

ログイン状態やアップロードファイルを1台のメモリ・一時ディスクだけへ置く構成は、そのまま台数を増やせません。セッションは用途に合う共有先へ、構造化データはDBへ、永続ファイルはオブジェクトストレージへ分けます。

よくある疑問

Next.jsはVercelでないと使えませんか？

Node.jsサーバーなど、公式に案内されている公開方法があります。ただし、使っている機能と周辺サービスの移行まで自動で済むわけではありません。

output: 'standalone'は必須ですか？

この例のnext buildとnext startの構成には必須ではありません。standalone出力を使う場合は、成果物のコピー範囲と起動方法が変わるため、ここで示すコマンドと混ぜずに別の配置として確認します。

DB付きのアプリにもできますか？

できますが、サーバー側でDBへ接続する処理と、マイグレーション管理が増えます。接続情報をNEXT_PUBLIC_で始まる変数へ入れず、ブラウザへ渡さない構成にします。

公開先は、利用中のNext.jsの機能、DBの接続先、運用したい方式、費用から選びます。Node.jsサーバーを使う場合は、本番用ビルド、PORTでの起動、公開URLの確認という小さな構成を先に通します。その後にDBや認証を足すと、配置先の問題とアプリ固有の問題を分けて調べられます。

検証範囲：掲載サンプルのビルドとNode.jsでの起動をローカルで確認しています。各サービスの比較は公式資料に基づくもので、全サービスでの同一アプリのデプロイ・性能比較は行っていません。KamuiDashへの新規デプロイも未実施です。仕様確認日：2026年11月2日。

KamuiDashは、GitHubやAI連携からWebアプリを公開できる東京リージョンのPaaSです。