PostgreSQL を使って Cursor アプリをデプロイする方法

PostgreSQL を使って Cursor アプリをデプロイするには、アプリケーションをホスト上で実行し、データベースを作成し、サーバーサイドの DATABASE_URL を通じて接続し、スキーマのマイグレーションを適用します。Cursor のエージェントは、Lizard CLI を通じてこれを実行できます。デプロイ後は、公開 URL を確認し、レコードが新しいブラウザセッションと再デプロイ後も保持されることを確かめてください。

このガイドは、すでにローカルで動作している Next.js アプリケーションを対象としています。アプリには Lizard、データベースには Managed Postgres を使用します。Cursor のデスクトップエージェントでプロンプトを使い、そのプランを確認し、承認した手順を実行させることができます。

ノート PC から移す必要があるものは？

タスクアプリを考えてみましょう。タスクを追加し、完了にして、後でまた戻ってきます。ページを公開することは、デプロイの一部にすぎません。サーバーがデータベースに到達できること、テーブルが存在すること、新しいリクエストが保存済みデータを読み取れることが必要です。

ローカルのデータベースと .env.local ファイルは、GitHub push では一緒に移動しません。保持する必要があるデータを決めてください。新しいアプリには新しいデータベースが適していますが、既存のデータベースを移行するには、別途エクスポートとインポートの計画が必要です。

1. Cursor で本番ビルドを確認する

Cursor でアプリケーションフォルダーを開きます。デプロイ設定を変更する前に、エージェントにプロジェクトを確認するよう依頼してください。

Prepare this Next.js app for deployment with PostgreSQL. Read its package.json,
lockfile, Next.js configuration, database client, and migration files.

Run the existing checks and production build using this project's package
manager. Identify the start command, port, required environment-variable
names, and production migration command. Do not print secret values.

Check whether any page queries the database during the build. Explain what
must be available at build time and what the app can read at request time.
Show any fixes needed before deploying.

本番ビルドが失敗していても、開発サーバーは動作することがあります。標準的な Next.js の Node.js デプロイでは、ビルドには next build を使い、サーバーには next start を使います。静的エクスポートと standalone 出力では、異なる起動設定が必要です。アプリで使用している構成については、Next.js デプロイガイド に従ってください。

lockfile はソース管理に含めてください。データベース認証情報はそこに含めないでください。NEXT_PUBLIC_DATABASE_URL のような変数は、ブラウザにシークレットを公開してしまいます。Next.js はビルド時に NEXT_PUBLIC_* の値をクライアント JavaScript に含めるためです。サーバー専用の DATABASE_URL を使用してください。Next.js 環境変数ドキュメント でその違いが説明されています。

2. 現在のデプロイ手順を Cursor に渡す

Cursor のエージェントは ターミナル コマンドを実行 できます。まだ利用できない場合は、Cursor のターミナルに Lizard CLI をインストールしてください。

npm install -g @lizard-build/cli

次に、エージェントにこれを実行して読ませてください。

lizard skills get core --json

このコマンドは、インストールされている CLI に一致するガイドを返します。このワークフローでは CLI を直接使用するため、MCP サーバーを設定する必要はありません。Lizard が認証を要求した場合は、続行する前にサインイン用リンクを完了してください。

このデプロイ用プロンプトを Cursor に貼り付けます。

Deploy this app with Lizard and Managed Postgres. First read the full output
of `lizard skills get core --json`. Check the current project link and git
remote, then show me the target project, service, region, and resources.
Wait for approval before creating resources or changing a live service.

If this app has a GitHub remote, connect that repository without starting
the first build. If it has no GitHub remote, use local source upload.

Create or select the intended database. Set DATABASE_URL on the app service
using a reference to that database's actual name. Configure the app's other
required variables and its reviewed production migration command before
deploying. Keep secret values out of the chat and repository.

Use the build settings this project needs. Read build and runtime logs,
check the final deployment status, and return the public URL. Test the
app's database-backed action and report what passed or failed.

コーディング エージェント ガイド には、両方のソースパス向けの完全なコマンドが含まれています。エージェントの作業を確認する間、そのガイドを手元に置いておいてください。

3. 最初のデプロイ前に Postgres を接続する

サービスは正常にビルドできても、最初のデータベースリクエストで失敗することがあります。最初のビルドやリリースを始める前に接続を構成してください。

意図したリンク済みプロジェクト内で、web という名前の新しいサービスを使い、アプリが GitHub リポジトリのルートにある場合、接続手順は次のようになります。YOUR_ORG/YOUR_REPO はあなたのリポジトリに置き換えてください。

lizard add --repo YOUR_ORG/YOUR_REPO --name web --no-deploy --json
lizard add postgres --json
lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service web --json

それが意図した対象であれば、既存のサービスやデータベースを再利用してください。この例では、新しいデータベース名が postgres であることを前提としています。Lizard が別の名前を返した場合は、その名前を参照に使用してください。単一引用符は、シェルが ${{...}} を解釈しないようにするためのものです。

--no-deploy により、データベース、マイグレーションコマンド、その他の必要な設定を構成する時間が確保されます。モノレポや別のブランチの場合は、デプロイ前にアプリディレクトリとブランチも設定してください。接続の詳細は Managed Postgres を参照してください。

GitHub リモートがない場合、エージェントは空のサービスを作成し、lizard up でローカルソースをアップロードできます。GitHub サービスの場合、後続の更新にはその GitHub デプロイフローを使用してください。lizard up はサービスをアップロード済みソースに変更します。これら 2 つの方法は別々の選択肢です。

4. アプリが想定するスキーマを適用する

PostgreSQL を作成しても、アプリのテーブルは作成されません。接続エラーとテーブル不足エラーでは、必要な対処が異なります。

すでにプロジェクト内で使っているマイグレーションツールを使用してください。コミット済みの migration ファイルがある Prisma プロジェクトでは、prisma migrate deploy により保留中のマイグレーションが本番環境に適用されます。Prisma は、これをデプロイプロセスを通じて実行することを推奨しています。これは Prisma Client を生成しないため、ビルドでは引き続きプロジェクトに必要な生成手順が必要です。この設定については Prismaのデプロイメント ドキュメント を参照してください。

確認済みのマイグレーションコマンドで、サービスの preDeployCommand を Cursor に設定させてください。ビルド済みイメージに migration ファイル、必要な CLI パッケージ、その設定が含まれていることを確認してください。マイグレーションにデータベース接続が必要な場合、そのコマンド実行時に接続が利用可能でなければなりません。保持が必要なデータに対して、開発用のリセットコマンドを実行しないでください。

Next.js は、ページのビルド中にもデータを読み取ることがあります。実行中サーバー向けに構成されたデータベース接続があっても、ビルド時クエリが成功するとは限りません。各クエリがいつ実行されるかを Cursor に確認させ、そのページに必要なレンダリング動作を使用してください。Next.jsセルフホスティングガイド では、実行時とビルド時の動作を扱っています。

5. 公開 URL で保存済みデータを確認する

デプロイ結果を確認し、その HTTPS URL を開いてください。ホームページが読み込まれた時点で止めず、Postgres を必要とする機能をテストしてください。

タスクアプリなら、次の手順を使います。

1. deployment-check-0909 のように識別しやすい名前でタスクを作成します。
2. ページを再読み込みして、そのタスクが表示されることを確認します。
3. プライベートブラウザーウィンドウを開き、必要なら同じアカウントにサインインして、もう一度そのタスクを確認します。これは、ブラウザーストレージにしか保存していないアプリを見つけるのに役立ちます。
4. 同じソースパスで小さなコード変更をデプロイします。タスクがまだ存在し、更新できることを確認します。

この確認はアプリに合わせて調整してください。予約、メモ、フォーム送信でも同じ目的を果たせます。ユーザーを招待する前に、テストデータを使い、各アカウントが自分のレコードにのみアクセスできることを確認してください。

確認が失敗した場合は、失敗した操作を Cursor に渡し、サービスログを調べるよう依頼してください。

lizard logs --build --service web --json
lizard logs --service web --json
lizard ps --json

最初のコマンドはビルドログを読み取り、2 つ目はアプリケーションログを読み取ります。フィルターやトラブルシューティングについては、logs reference を開いたままにしておいてください。

Cursor アプリがローカルでは動くのに、デプロイ後に失敗するのはなぜですか？

デプロイ済みアプリでは、変数、データベース、または起動コマンドが異なる可能性があります。症状に応じて、関連する確認項目を見てください。

ログに示された原因をエージェントに修正させてください。同じ構成でデプロイを繰り返しても、変数やテーブルの不足は解決しません。

アプリと Postgres のホスティング費用はいくらですか？

Lizard は 月額サブスクリプションなしの pay as you go を採用しています。新規アカウントには 31 日間有効な $10 の無料クレジット が付与されます。購入したクレジットに有効期限はありません。リソース使用量はアカウント残高から差し引かれます。チャージ画面には、確認前に支払い手数料が表示されます。現在の料金と支払い条件 を参照してください。

アプリケーションと Managed Postgres の両方がリソースを消費します。Lizard では、プラン条件に基づき、CPU、メモリ、ストレージ、送信トラフィックに対して、アクティブなリソースにのみ課金が行われます。アプリを停止しても別個のデータベースは停止せず、保持されたボリュームストレージには引き続き課金が発生することがあります。

想定する負荷のもとで、アプリとデータベースを一緒に計測してください。トライアルクレジットはデプロイを試す手段であり、永続的な無料ホスティングや、あらゆるアプリで固定の月額費用を約束するものではありません。

デプロイ前の質問

Cursor からアプリを書き出す必要はありますか？

ローカルプロジェクトでは、ソースファイルはすでにプロジェクトフォルダー内にあります。そのコードを、接続された GitHub リポジトリまたはローカルアップロードを通じてデプロイしてください。ビルドと実行に必要なファイルがソースに含まれていることを確認してください。

Cursor のサブスクリプションで Lizard のホスティング料金は支払われますか？

いいえ。Cursor と Lizard は別々のサービスです。このワークフローでは、Cursor を使って Lizard CLI を操作します。デプロイされたアプリとデータベースの料金は、Lizard アカウントがその独自のプランに従って支払います。

既存の PostgreSQL データベースを使い続けられますか？

はい。デプロイされたサーバーがそのデータベースに到達でき、接続設定がデータベースプロバイダーの要件を満たしていれば可能です。サーバーサイド接続文字列を構成し、ネットワークアクセスを確認し、同じアプリケーションテストを実行してください。このワークフローを使うためだけに、別のデータベースを作成する必要はありません。

デプロイ前にカスタムドメインは必要ですか？

まず、Lizard が Web サービス用に返す公開アドレスを確認してください。正常に動作したら、カスタム ドメイン手順 に従ってホスト名を接続し、DNS レコードを確認してください。アプリがログインコールバックを使う場合は、それらの URL も更新してください。

Cursor でプロジェクトを開き、まずは上記の準備プロンプトから始めてください。正確なデプロイ手順については、コーディング エージェント ガイド を使用してください。