Nuxtアプリをデプロイする方法｜公開手順と設定の注意点

Nuxtアプリのデプロイには2つの方式があり、どちらもビルドの成果物は.outputに出ます。ただ、npm run devで動いているアプリを公開しようと調べ始めると、記事ごとに置き場所も設定もばらばらで、しかもnitro.presetという見慣れない設定を書き換えろと書いてある。自分のアプリにも要るのだろうか、と手が止まりませんか。この記事では、2つの公開方式の違いと、公開URLが手に入るまでの手順、そしてNuxt特有のつまずきどころを解説します。

目次

• Nuxtのビルド方式は2通り。どちらも出力先は同じ
• 【手順】Nuxtアプリをデプロイして公開する
• Nuxtのデプロイでつまずきやすいポイント
• AIエージェントにデプロイを任せる
• Nuxtアプリの公開ならロリポップ！デプロイナウ
• よくある質問（FAQ）
• まとめ

Nuxtのビルド方式は2通り。どちらも出力先は同じ

nuxt buildとnuxt generate、自分はどちらを打てばいいのか。ここが最初の分かれ目です。なお、この記事が対象にしているのはNuxt 3以降で、Nuxt 4でも手順は同じです。答えを先に言うと、サーバー側の機能を使うならnuxt build、全員に同じページを返すだけならnuxt generate。そして、どちらを選んでも成果物は.outputディレクトリに出ます。ビルドした成果物をサーバーに置いてURLでアクセスできる状態にする作業そのものについては、デプロイとは？意味・仕組みの記事で整理しています。

Node.jsサーバーとして動かす（nuxt build）

Nuxt公式のデプロイガイドによると、Nodeサーバープリセットでnuxt buildを実行すると、そのまま起動できるNodeサーバーのエントリーポイントが出力されます。同ガイドが起動コマンドとして示しているのはNODE_ENV=production node .output/server/index.mjsで、この1ファイル（.output/server/index.mjs）がアプリの入口になります。

筆者の手元のNuxt 4.5.1のプロジェクトで実際にnuxt buildを走らせたところ、.outputの下にserverとpublicの両方が作られ、合計2.5MBになりました。アクセスのたびにHTMLを組み立てるSSRも、server/apiに置いたAPIも、この方式ならそのまま動きます。

静的に書き出す（nuxt generate）

同じガイドに、nuxt generateは.output/public/index.htmlというエントリーポイントとJavaScriptのバンドルを出力する、と書かれています。ssr: trueのままなら各ルートがビルド時に事前レンダリングされ、ssr: falseにした場合は<div id="__nuxt"></div>が空のHTMLが出力されます。

こちらも手元で試すと、できあがったのは.output/publicだけで、serverディレクトリは作られませんでした。サイズは264KBでした。

どちらを選ぶ？判断の分かれ目

分かれ目は、ページの内容が閲覧する人や時点によって変わるかどうかです。ログイン機能や問い合わせフォーム、自前のAPIがあるならnuxt build。プロフィールサイトや作品置き場のように、誰に対しても同じページを返すだけならnuxt generateで足ります。

方式で出力ディレクトリ自体が分かれるフレームワークもありますが、Nuxtは.outputという同じ入れ物の中身が変わるだけです。ビルドまわりの差をNitroが吸収しているためで、置き場所の考え方はどちらでも共通に扱えます。出力先をdistと書いている解説記事もありますが、公式が案内している出力先は.outputです。

【手順】Nuxtアプリをデプロイして公開する

方式が決まったら、次は置き場所です。デプロイ先には、サーバーの用意と運用をサービス側に任せられるホスティングサービス、自前のサーバー、クラウドの3系統があり、ビルドの設定を整えてツールでデプロイし、環境変数とドメインを設定するという流れはどこを選んでも共通です。ここでは、作ったWebアプリやサイトをコマンドひとつで公開できて、画面もドキュメントも日本語で確認できる「ロリポップ！デプロイナウ」を例に進めます。

事前確認：nitro.preset は変更しない

Nuxtのデプロイ記事の多くは、置き場所に合わせてnitro.presetを書き換えるところから始まります。ところがデプロイナウの場合、やることは逆で、公式のクイックスタートには「nitro.preset をデフォルト（node-server）のままにしてください」と書かれています。設定を足すのではなく、触らないことが条件です。

デフォルトのままでいい理由は、Nitroの既定の本番プリセットがそもそもNode.jsサーバーだからです。Nitro公式のデプロイのページにもそう明記されています。実際、設定を何も足さずにビルドした.output/nitro.jsonを開くと、"preset": "node-server"と入っていました。すでにnuxt.config.tsへnitro.presetを書き足している場合は、その行を外してからデプロイに進んでください。

ステップ1：CLIを用意する

ターミナルで次のコマンドを実行すると、デプロイの操作を文字入力で進めるCLIツールのlolipopコマンドが入ります。動作にはNode.js 22.12.0以上が必要なので、先にnode -vで手元のバージョンを確かめておくと確実です。

npm i -g lolipop

続けてlolipop loginを実行し、画面の案内に沿ってアカウント認証を済ませます。ターミナルでの作業と聞くと構えるかもしれませんが、ここで自分の判断で打つのは数個のコマンドだけで、残りは表示された案内に答えていく形です。

ステップ2：デプロイする

事前確認とログインまで済んだら、アプリのディレクトリで次のコマンドを実行します。

lolipop deploy --name <プロジェクト名> --framework nuxt

実行するとアップロードとビルドが自動で進み、完了すると公開URLが表示されます。フレームワークにnuxtを指定すると、Nuxt向けのドキュメントにあるとおり、インストールコマンドはnpm ci --ignore-scripts、ビルドコマンドはnpm run build、出力ディレクトリは.outputが既定で入るため、追加の指定は通常いりません。

表示されたURLをブラウザで開いて、ローカルと同じ画面が出れば公開完了です。コードを直したあとの反映も同じ流れで、lolipop project linkでディレクトリとプロジェクトを紐付けておけば、2回目からはlolipop deployだけで新しいバージョンが公開されます。

ステップ3：環境変数を設定する

外部APIのキーなど、コードに直接書きたくない値はプロジェクトの環境変数として登録します。ターミナルからならlolipop env create API_URL https://api.example.comのような形で、ダッシュボードからならプロジェクト詳細画面の「環境変数」タブから追加できます。

注意したいのは、ローカルの.envに書いた値がそのままでは引き継がれない点です。環境変数のドキュメントには「.env の内容は、ビルド時、公開時ともに参照されません。」と明記されています。

ステップ4：独自ドメインを設定する（任意）

発行されたサブドメインのままでも運用できます。自分のドメインで公開したい場合は、ダッシュボードのプロジェクト詳細画面にある「ドメイン」タブからドメインを追加すると、設定すべきDNSレコードが表示されます。独自ドメインのドキュメントによると、表示されたレコードをDNSプロバイダー側で設定し、反映後に検証を実行する流れです。SSL証明書は自動で発行されます。

設定する値はプロジェクトごとに違うので、自分の画面に出たものをそのまま写してください。ここまでの操作はCLIでも完結し、lolipop domain createでドメインを追加してDNSレコードを表示し、設定後にlolipop domain verifyで検証を開始します。

独自ドメインをこれから取るなら、ムームードメインのMCPサーバーを使う手もあります。AIエージェントから外部のサービスをそのまま操作できるようにする仕組みで、ドメインの空き検索から取得、DNSレコードの設定までを任せられます。公式ページによると、AレコードやCNAMEレコードの作成・更新・削除もAIが実行し、用意されているツールは全11種です。対応しているのはClaude Code、Claude Desktop、OpenAI Codex、Gemini CLIで、MCPサーバー自体の利用は無料です（ドメインの取得・更新には通常の料金がかかります）。デプロイナウのCLIと合わせれば、ドメインを取ってDNSを整え、Nuxtアプリを公開するまでを、AIエージェントとの会話やターミナル上で進められます。

Nuxtのデプロイでつまずきやすいポイント

デプロイしたのに思ったとおり動かない。そんなときは、nitro.preset、ロックファイル、制限を受ける機能、環境変数の順に見ていくと原因にたどり着けます。前の2つはデプロイ自体が通らないとき、あとの2つは公開されたのに挙動がおかしいときに効いてきます。

nitro.preset を書き換えてしまう

nitro.presetを書き換えると、成果物の形そのものが変わります。どのくらい変わるのか確かめたくて、筆者は先ほどのプロジェクトのnuxt.config.tsに別のプリセットを1行足し、ビルドし直してみました。すると.outputが見当たりません。ls .outputを叩くとNo such file or directoryと返り、代わりにdistというディレクトリができていました。中身も.output/server/index.mjsではなく、プリセット先の実行形式に合わせたファイル群に入れ替わっています。

デプロイナウ側の既定の出力ディレクトリは.outputで、公式はプリセットをデフォルトのままにするよう案内しています。他のデプロイ先向けの記事を見ながら設定を足していた場合は、まずnuxt.config.tsのnitroの項目を確認してください。

ビルドが npm ci で止まる

デプロイの途中でビルドが落ちるときに多いのが、package-lock.jsonのずれです。デプロイナウの既定のインストールコマンドはnpm ci --ignore-scriptsで、npm ciはロックファイルがpackage.jsonと厳密に一致していないと処理を止めます。手元のnpm installはずれを自動で吸収してくれるので、「ローカルでは問題ないのにデプロイだけ落ちる」という形で表に出ます。

筆者が今回用意したNuxtプロジェクトも、初期化した直後の状態でこれに当たりました。ビルドログに出ていたのは「npm ci can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync.」というエラーで、そのあとにロックファイル側とパッケージ側でバージョンが食い違っている行が続いていました。手元でnpm installを実行してロックファイルを作り直してから、もう一度デプロイすると通ります。

制限を受けるNuxtの機能がある

Nuxtの機能のうち、デプロイナウでは扱いが変わるものが公式ドキュメントに一覧で示されています。動かしてから気づくと切り分けに時間がかかるため、公開前に自分のアプリで使っていないかを見ておくと安心です。

機能	対応	備考・代替
@nuxt/image	△	v2以上を推奨（npm install @nuxt/image@^2）
useStorageのfsドライバ	×	外部DBやKVSに保存する
routeRulesのisr	×	swrを使用する

この内容は執筆時点のもので、対応状況は変わります。最新はNuxt向けのドキュメントで確認してください。

環境変数が反映されない

ローカルでは動くのに公開後だけAPI呼び出しが失敗する場合、原因の多くはステップ3で触れた.envです。プロジェクトの環境変数として登録し直すと解消します。登録済みの値はlolipop env listで一覧でき、値は伏字で表示されます。

サイズにも上限があり、1つの環境変数の値は4,000バイトまで、プロジェクト全体では名前と値を合わせて4KBまでです。APIキーのような秘匿情報は、この環境変数の側に置いてリポジトリには含めないでおくと、コードを公開したときの事故を防げます。

AIエージェントにデプロイを任せる

アプリを作るのを手伝ってもらったAIに、公開もそのまま頼めないか。これはできます。AIエージェントでデプロイするというドキュメントがあり、対象はClaude Code、Codex、Cursor、Antigravityなどです。

準備はlolipop skill installを実行して、スキルを入れるエージェントを選ぶだけです。これでlolipop CLIの使い方がエージェント側に追加され、あとは「このアプリをlolipopにデプロイして」と頼めば、プロジェクトの作成からビルド、公開まで進みます。省けるのはコマンドを自分で組み立てる工程で、Node.js 22.12.0以上という前提と、nitro.presetを触らないというNuxt側の条件は変わりません。AIエージェントと会話しながらNuxtアプリを組み上げたなら、同じ会話の続きでlolipop skill installから始められます。

Nuxtアプリの公開ならロリポップ！デプロイナウ

設定を書き換える不安、費用の読めなさ、英語のドキュメント。デプロイを後回しにする理由の多くは、置き場所の選び方で解消できます。デプロイナウはNuxtアプリをサーバーとして動かす公開から独自ドメイン、SSL証明書までを一通りそろえたうえで、次の3つに特徴があります。

• コマンドひとつで公開できる：lolipop deployでビルドから公開まで自動で進みます。Claude CodeなどのAIエージェントに「デプロイして」と自然言語で頼む使い方にも対応しています
• 無料から始められる定額制：執筆時点で、Freeプランは無料、Personalプランは月額980円です。どちらのプランでも商用利用ができます
• 日本語でそのまま完結する：画面もドキュメントも日本語で読めて、Personalプランには有人メールサポートが付きます

Freeプランの上限は執筆時点で月間リクエスト1,000,000回、CPU実行時間4時間、メモリ512MiBです（最新の内容はプランのページを参照）。個人開発のアプリを公開して反応を見るには十分な枠なので、まず無料で出して、足りなくなったらPersonalへ切り替える使い方ができます。

よくある質問（FAQ）

Nuxtのデプロイに nitro.preset の設定は必要ですか？

デプロイナウでは不要です。公式のクイックスタートに、デフォルトのnode-serverのままにするよう案内があります。別のデプロイ先に置く場合は、その提供元のドキュメントで指定を確認してください。

nuxt generate で書き出した静的サイトも公開できますか？

nuxt generateで書き出した静的サイトの扱いについて、デプロイナウの公式ドキュメントに記載は執筆時点で確認できませんでした。サーバー側の機能を使わないアプリでもnuxt buildで公開できるため、まずはそちらの手順で試すのが確実です。

Nuxt 2 のアプリも同じ手順でデプロイできますか？

公式ドキュメントに対応バージョンの明示がないため、この記事では断定できません。Nuxt向けのドキュメントで最新の記載を確認してください。なお、この記事の手順とコマンドはNuxt 3以降を前提にしています。

Gitにpushしたら自動でデプロイされますか？

Gitのpushに連動した自動デプロイと、プルリクエストごとのプレビューURLの発行は、現在提供されておらず、公式のお知らせで順次提供が予定されています。現時点ではlolipop deployの再実行で新しいバージョンを公開します。

Nuxtのデプロイ先はどこを選べばいいですか？

サーバー管理に時間を使いたくない個人開発なら、ホスティングサービスが向いています。OSやミドルウェアの構成から自分で決めたい場合は、自前のサーバーやクラウドが選択肢です。手元に残る作業量が3系統でどう変わるかは、Webアプリを公開する方法に一覧があります。

まとめ

• Nuxtの公開方式は2つあるが、成果物はどちらも.outputに集約される
• デプロイナウで必要なのは設定の追加ではなく、nitro.presetをデフォルトのままにすること
• 動かないときはnitro.presetとロックファイル、次に制限を受ける機能と環境変数を確認する

ローカルで動くところまで作れたなら、公開までに残っているのはコマンド数回分です。設定を足す作業がない分、Nuxtアプリの公開はむしろ短い手順で終わります。

→ ロリポップ！デプロイナウを見てみる

npm run devのターミナルを閉じたあともアプリはURLの先で動き続けて、リンクを送るだけで誰にでも見てもらえるようになります。

---