render-deploy

Render へのデプロイ

Render は Git ベース のサービスと ビルド済み Docker イメージ のサービスをサポートしています。

このスキルでは Git ベース のフローを扱います:

1. Blueprint 方式 - Infrastructure-as-Code デプロイ用の render.yaml を生成
2. 直接作成 - MCP ツール経由で即座にサービスを作成

Blueprint でも runtime: image を使ってビルド済み Docker イメージを実行できますが、render.yaml は引き続き Git リポジトリ内に置く必要があります。

Git リモートがない場合は、作業を止めてユーザーに次のいずれかを選んでもらうよう依頼してください:

• Git リモートを作成してプッシュする(Blueprint だけが必要な場合は最小限の内容でかまいません)、または
• Render ダッシュボードまたは API を使ってビルド済み Docker イメージをデプロイする(MCP ではイメージベースのサービスを作成できません)。

前提条件

• サンドボックスによってデプロイのネットワーク通信がブロックされた場合は、sandbox_permissions=require_escalated を指定して再実行してください。
• デプロイには数分かかることがあります。適切なタイムアウト値を使用してください。

このスキルを使用するタイミング

ユーザーが次のことを行いたいときにこのスキルを有効にします:

• アプリケーションを Render にデプロイする
• render.yaml の Blueprint ファイルを作成する
• プロジェクトの Render デプロイを設定する
• Render のクラウドプラットフォームでアプリケーションをホスト・公開する
• データベース、cron ジョブ、その他の Render リソースを作成する

ハッピーパス(新規ユーザー向け)

詳細な分析の前に、この短いプロンプトの流れを使って手間を減らしてください:

1. Git リポジトリからデプロイするか、ビルド済み Docker イメージからデプロイするかを尋ねる。
2. アプリに必要なものを Render で全てプロビジョニングするか(ユーザーの説明から推測される内容に基づく)、アプリだけをデプロイして인프라は自前で用意するかを尋ねる。依存関係が不明確な場合は、データベース、ワーカー、cron、その他のサービスが必要かを確認する短い追加質問をする。

その後、以下の適切な方式に進みます。

ソースパスの選択

Git リポジトリパス: Blueprint と直接作成の両方で必要です。リポジトリは GitHub、GitLab、または Bitbucket にプッシュされている必要があります。

ビルド済み Docker イメージパス: イメージベースのサービスを通じて Render でサポートされています。ただし、MCP ではサポートされていないため、ダッシュボードまたは API を使用してください。次の情報を確認します:

• イメージの URL(レジストリ + タグ)
• レジストリの認証情報(プライベートの場合)
• サービスの種類(web/worker)とポート

ユーザーが Docker イメージを選択した場合は、Render ダッシュボードのイメージデプロイの手順を案内するか、Git リモートを追加してもらい(runtime: image を使った Blueprint を利用するため)ください。

デプロイ方式の選択(Git リポジトリ)

どちらの方式も、GitHub、GitLab、または Bitbucket にプッシュされた Git リポジトリが必要です。(runtime: image を使う場合、リポジトリは最小限で、render.yaml だけを含んでいてもかまいません。)

方式	最適な用途	利点
Blueprint	マルチサービスのアプリ、IaC ワークフロー	バージョン管理され、再現可能で、複雑な構成にも対応
直接作成	単一サービス、迅速なデプロイ	即座に作成でき、render.yaml ファイルが不要

方式選択のヒューリスティック

ユーザーが特定の方式を要求しない限り、既定でこの判断基準を使用してください。まずコードベースを分析し、デプロイの意図が不明確な場合(例: DB、ワーカー、cron)にのみ質問してください。

次の条件がすべて当てはまる場合は直接作成(MCP)を使用:

• 単一サービス(1 つの Web アプリまたは 1 つの静的サイト)
• 個別のワーカー/cron サービスがない
• 接続されたデータベースや Key Value がない
• 単純な環境変数のみ(共有の環境変数グループなし) この方式が適していて MCP がまだ設定されていない場合は、作業を止めて先に MCP の設定を案内してください。

次のいずれかに当てはまる場合は Blueprint を使用:

• 複数サービス(Web + ワーカー、API + フロントエンドなど)
• データベース、Redis/Key Value、その他のデータストアが必要
• cron ジョブ、バックグラウンドワーカー、またはプライベートサービスがある
• 再現可能な IaC、またはリポジトリにコミットされた render.yaml が必要
• 一貫した構成が必要なモノレポまたはマルチ環境のセットアップ

判断に迷う場合は簡単な確認質問をしてもかまいませんが、安全のため既定では Blueprint を選んでください。単一サービスの場合は、MCP による直接作成を強く推奨し、必要に応じて MCP の設定を案内してください。

前提条件の確認

デプロイを開始するときは、次の要件を順番に確認してください:

1. ソースパスの確認（Git と Docker）

Git ベースの方法（Blueprint または Direct Creation）を使用する場合、リポジトリを GitHub/GitLab/Bitbucket にプッシュしておく必要があります。ビルド済みイメージを参照する Blueprint であっても、render.yaml を含む Git リポジトリが必要です。

git remote -v

• リモートが存在しない場合は、作業を中止し、ユーザーにリモートの作成とプッシュを依頼するか、Docker イメージでのデプロイに切り替えるかを確認してください。

2. MCP ツールの利用可否の確認（単一サービスの場合に推奨）

MCP ツールが最も快適に利用できます。次のコマンドを試して利用可否を確認してください:

list_services()

MCP ツールが利用可能であれば、ほとんどの操作で CLI のインストールを省略できます。

3. Render CLI のインストール確認（Blueprint の検証用）

render --version

インストールされていない場合は、次のインストールを提案してください:

• macOS: brew install render
• Linux/macOS: curl -fsSL https://raw.githubusercontent.com/render-oss/cli/main/bin/install.sh | sh

4. MCP のセットアップ（MCP が未設定の場合）

MCP が未設定のために list_services() が失敗する場合は、MCP をセットアップするか（推奨）、CLI によるフォールバックで続行するかをユーザーに確認してください。MCP を選択した場合は、使用している AI ツールを確認し、以下の該当する手順を案内してください。必ずユーザー自身の API キーを使用してください。

Cursor

ユーザーに次の手順を案内してください:

1. Render API キーを取得します:

https://dashboard.render.com/u/*/settings#api-keys

2. ~/.cursor/mcp.json に次の内容を追加します（<YOUR_API_KEY> を置き換えてください）:

{
  "mcpServers": {
    "render": {
      "url": "https://mcp.render.com/mcp",
      "headers": {
        "Authorization": "Bearer <YOUR_API_KEY>"
      }
    }
  }
}

3. Cursor を再起動し、list_services() を再実行します。

Claude Code

ユーザーに次の手順を案内してください:

1. Render API キーを取得します:

https://dashboard.render.com/u/*/settings#api-keys

2. Claude Code に MCP サーバーを追加します（<YOUR_API_KEY> を置き換えてください）:

claude mcp add --transport http render https://mcp.render.com/mcp --header "Authorization: Bearer <YOUR_API_KEY>"

3. Claude Code を再起動し、list_services() を再実行します。

Codex

ユーザーに次の手順を案内してください:

1. Render API キーを取得します:

https://dashboard.render.com/u/*/settings#api-keys

2. シェルに API キーを設定します:

export RENDER_API_KEY="<YOUR_API_KEY>"

3. Codex CLI で MCP サーバーを追加します:

codex mcp add render --url https://mcp.render.com/mcp --bearer-token-env-var RENDER_API_KEY

4. Codex を再起動し、list_services() を再実行します。

その他のツール

ユーザーが他の AI アプリを使用している場合は、そのツールのセットアップ手順とインストール方法について Render MCP のドキュメントを案内してください。

ワークスペースの選択

MCP の設定後、次のようなプロンプトでアクティブな Render ワークスペースを設定するようユーザーに依頼してください:

Set my Render workspace to [WORKSPACE_NAME]

5. 認証の確認（CLI によるフォールバックの場合のみ）

MCP が利用できない場合は、CLI を使用してアカウントにアクセスできることを確認してください:

# Check if user is logged in (use -o json for non-interactive mode)
render whoami -o json

render whoami が失敗する、または空のデータを返す場合、CLI は認証されていません。CLI は自動的にプロンプトを表示するとは限らないため、認証を明示的にユーザーに促してください。

どちらも設定されていない場合は、ユーザーにどの方法を希望するかを確認してください:

• API キー（CLI）: export RENDER_API_KEY="rnd_xxxxx"（取得先: https://dashboard.render.com/u/*/settings#api-keys）
• ログイン: render login（OAuth のためブラウザが開きます）

6. ワークスペースのコンテキストの確認

アクティブなワークスペースを確認します:

get_selected_workspace()

または CLI で確認します:

render workspace current -o json

利用可能なワークスペースを一覧表示するには:

list_workspaces()

ユーザーがワークスペースを切り替える必要がある場合は、ダッシュボードまたは CLI（render workspace set）で行う必要があります。

前提条件が満たされたら、デプロイのワークフローに進みます。

---

方法 1: Blueprint によるデプロイ（複雑なアプリに推奨）

Blueprint のワークフロー

ステップ 1: コードベースの分析

コードベースを分析し、フレームワーク/ランタイム、ビルドコマンドと起動コマンド、必要な環境変数、データストア、ポートバインディングを特定します。詳細なチェックリストは references/codebase-analysis.md を参照してください。

Step 2: render.yaml を生成する

Blueprint 仕様に従って render.yaml Blueprint ファイルを作成します。

完全な仕様: references/blueprint-spec.md

重要なポイント:

• ユーザーが指定しない限り、常に plan: free を使用する
• アプリに必要な環境変数はすべて含める
• シークレットには sync: false を付ける（ユーザーがダッシュボードで値を入力します）
• 適切なサービスタイプを使用する: web、worker、cron、static、または pserv
• 適切なランタイムを使用する: references/runtimes.md

基本構造:

services:
  - type: web
    name: my-app
    runtime: node
    plan: free
    buildCommand: npm ci
    startCommand: npm start
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: postgres
          property: connectionString
      - key: JWT_SECRET
        sync: false  # User fills in Dashboard

databases:
  - name: postgres
    databaseName: myapp_db
    plan: free

サービスタイプ:

• web: HTTP サービス、API、Web アプリケーション（公開アクセス可能）
• worker: バックグラウンドジョブのプロセッサー（公開アクセス不可）
• cron: cron スケジュールで実行されるスケジュールタスク
• static: 静的サイト（HTML/CSS/JS を CDN で配信）
• pserv: プライベートサービス（同じアカウント内の内部専用）

サービスタイプの詳細: references/service-types.md ランタイムのオプション: references/runtimes.md テンプレートの例: assets/

Step 2.5: 直ちに行う次のステップ（必ず提示する）

render.yaml を作成したら、必ずユーザーに短く明確なチェックリストを提示し、CLI が利用可能であればただちに検証を実行します:

1. 認証（CLI）: render whoami -o json を実行する（ログインしていない場合は render login を実行するか RENDER_API_KEY を設定する）
2. 検証（推奨）: render blueprints validate を実行する
   • CLI がインストールされていない場合は、インストールを提案し、そのコマンドを示します。
3. コミットとプッシュ: git add render.yaml && git commit -m "Add Render deployment configuration" && git push origin main
4. ダッシュボードを開く: Blueprint のディープリンクを使用し、求められた場合は Git OAuth を完了する
5. シークレットを入力する: sync: false が付いた環境変数を設定する
6. デプロイ: 「Apply」をクリックし、デプロイを監視する

Step 3: 設定を検証する

デプロイ前にエラーを検出するため、render.yaml ファイルを検証します。CLI がインストールされている場合は直接コマンドを実行し、CLI がない場合のみユーザーに確認します:

render whoami -o json  # Ensure CLI is authenticated (won't always prompt)
render blueprints validate

先に進む前に、検証エラーをすべて修正してください。よくある問題:

• 必須フィールド（name、type、runtime）の欠落
• 無効なランタイムの値
• YAML 構文の誤り
• 無効な環境変数の参照

設定ガイド: references/configuration-guide.md

Step 4: コミットしてプッシュする

重要: デプロイの前に、render.yaml ファイルをリポジトリにマージしておく必要があります。

render.yaml ファイルがコミットされ、Git リモートにプッシュされていることを確認します:

git add render.yaml
git commit -m "Add Render deployment configuration"
git push origin main

まだ Git リモートがない場合は、ここで止めて、ユーザーが GitHub/GitLab/Bitbucket のリポジトリを作成し、origin として追加してからプッシュするよう案内してください。

これが重要な理由: ダッシュボードのディープリンクは、リポジトリ内の render.yaml を読み込みます。ファイルがマージされてプッシュされていなければ、Render は設定を見つけられず、デプロイは失敗します。

次のステップに進む前に、ファイルがリモートリポジトリにあることを確認してください。

Step 5: ディープリンクを生成する

Git リポジトリの URL を取得します:

git remote get-url origin

これは Git プロバイダーからの URL を返します。URL が SSH 形式の場合は、HTTPS に変換してください:

SSH 形式	HTTPS 形式
[email protected]:user/repo.git	https://github.com/user/repo
[email protected]:user/repo.git	https://gitlab.com/user/repo
[email protected]:user/repo.git	https://bitbucket.org/user/repo

変換パターン: git@<host>: を https://<host>/ に置き換え、.git の接尾辞を削除します。

HTTPS のリポジトリ URL を使用して、ダッシュボードのディープリンクを整形します:

https://dashboard.render.com/blueprint/new?repo=<REPOSITORY_URL>

例:

https://dashboard.render.com/blueprint/new?repo=https://github.com/username/repo-name

Step 6: ユーザーをガイドする

重要: deeplink をクリックする前に、render.yaml ファイルがユーザーのリポジトリにマージおよびプッシュされていることを必ず確認してください。ファイルがリポジトリに存在しない場合、Render は Blueprint の設定を読み取れず、デプロイは失敗します。

ユーザーには、以下の手順とともに deeplink を提供してください:

1. render.yaml がマージされていることを確認 - GitHub/GitLab/Bitbucket 上のリポジトリにファイルが存在することを確認する
2. deeplink をクリックして Render Dashboard を開く
3. 求められた場合は Git プロバイダーの OAuth を完了する
4. Blueprint に名前を付ける(または render.yaml のデフォルトを使用する)
5. シークレットの環境変数(sync: false で指定されたもの)に値を入力する
6. services と databases の設定を確認する
7. "Apply" をクリックしてデプロイする

デプロイは自動的に開始されます。ユーザーは Render Dashboard で進行状況を監視できます。

Step 7: デプロイを検証する

ユーザーが Dashboard からデプロイした後、すべてが正常に動作しているか検証します。

MCP でデプロイステータスを確認:

list_deploys(serviceId: "<service-id>", limit: 1)

status: "live" が表示されれば、デプロイが成功していることを確認できます。

ランタイムエラーを確認(デプロイ後 2〜3 分待ってから):

list_logs(resource: ["<service-id>"], level: ["error"], limit: 20)

サービスのヘルスメトリクスを確認:

get_metrics(
  resourceId: "<service-id>",
  metricTypes: ["http_request_count", "cpu_usage", "memory_usage"]
)

エラーが見つかった場合は、以下の デプロイ後の検証と基本的なトリアージ セクションに進んでください。

---

方法 2: 直接サービス作成(シングルサービスの簡易デプロイ)

Infrastructure-as-Code を使用しない簡単なデプロイでは、MCP ツールを使ってサービスを直接作成します。

直接作成を使用する場面

• 単一の Web サービスまたは静的サイト
• 簡単なプロトタイプやデモ
• リポジトリに render.yaml ファイルを置く必要がない場合
• 既存プロジェクトにデータベースやクーロンジョブを追加する場合

直接作成の前提条件

リポジトリが Git プロバイダーにプッシュされている必要があります。 Render はリポジトリをクローンして、サービスをビルドおよびデプロイします。

git remote -v  # Verify remote exists
git push origin main  # Ensure code is pushed

対応プロバイダー: GitHub、GitLab、Bitbucket

リモートが存在しない場合は、作業を停止し、ユーザーにリモートの作成とプッシュを依頼するか、Docker イメージのデプロイに切り替えるよう求めてください。

注意: MCP はイメージベースのサービスの作成に対応していません。事前ビルド済みの Docker イメージをデプロイする場合は、Dashboard または API を使用してください。

直接作成のワークフロー

以下の簡潔な手順を使用し、MCP コマンドの完全な例と後続の設定については references/direct-creation.md を参照してください。

Step 1: コードベースを分析する

references/codebase-analysis.md を使用して、ランタイム、ビルド/起動コマンド、環境変数、データストアを特定します。

Step 2: MCP でリソースを作成する

サービス(Web またはスタティック)と、必要なデータベースやキーバリューストアを作成します。references/direct-creation.md を参照してください。

Git の認証情報やリポジトリへのアクセスに関するエラーが MCP から返された場合は、作業を停止し、Render Dashboard で Git プロバイダーを接続するようユーザーに案内してから、再試行してください。

Step 3: 環境変数を設定する

作成後に、MCP を使って必要な環境変数を追加します。references/direct-creation.md を参照してください。

MCP 経由で渡したくない場合は、シークレットを Dashboard で設定できることをユーザーに伝えてください。

Step 4: デプロイを検証する

デプロイのステータス、ログ、メトリクスを確認します。references/direct-creation.md を参照してください。

---

サービスの検出、設定の詳細、クイックコマンド、よくある問題については、references/deployment-details.md を参照してください。

---

デプロイ後の検証と基本的なトリアージ(すべての方法に共通)

簡潔に、繰り返し実行できる形で行います。いずれかのチェックに失敗した場合は、再デプロイする前に修正してください。

1. 最新のデプロイが live であり、トラフィックを処理していることを確認する
2. ヘルスエンドポイント(またはルート)にアクセスし、200 レスポンスが返ることを確認する
3. 最近のエラーログを確認し、明確な失敗の兆候がないかスキャンする
4. 必要な環境変数とポートバインディング(0.0.0.0:$PORT)を確認する

詳細なチェックリストとコマンド: references/post-deploy-checks.md

サービスの起動に失敗した場合やヘルスチェックがタイムアウトする場合は、基本的なトリアージガイドを使用してください: references/troubleshooting-basics.md

トラブルシューティング

エスカレーションされたネットワークアクセス

デプロイがネットワークの問題（タイムアウト、DNS エラー、接続リセット）で失敗した場合は、エスカレーションされた権限を使ってデプロイを再実行してください（sandbox_permissions=require_escalated を使用します）。サンドボックスのネットワーク機能が外向きのリクエストをブロックしている場合、デプロイにはエスカレーションされたネットワークアクセスが必要です。

ユーザーへの案内例：

The deploy needs escalated network access to deploy to Render. I can rerun the command with escalated permissions—want me to proceed?

任意：より詳細な診断（メトリクス／DB チェック／エラーカタログ）が必要な場合は、render-debug スキルのインストールを提案してください。コアのデプロイフローには必須ではありません。