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 Dashboard/API を使ってビルド済み Docker イメージをデプロイする（MCP ではイメージベースのサービスを作成できません）。

このスキルを使う場面

ユーザーが次のことを希望する場合に、このスキルを有効にします。

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

スムーズな進め方（新規ユーザー向け）

不足している情報を補うためだけに、次の短い質問を順に行います。ユーザーがすでに伝えた内容を繰り返し尋ねないでください。ソースと必要なリソースが明確な場合は、方法の選択とデプロイに進んでください。

1. Git リポジトリからデプロイするか、ビルド済み Docker イメージからデプロイするかを尋ねます。
2. Render にアプリケーションに必要なものをすべてプロビジョニングさせるか（ユーザーの説明から想定される内容に基づきます）、アプリケーションだけを用意してインフラはユーザー側で用意するかを尋ねます。依存関係が不明な場合は、データベース、ワーカー、cron、その他のサービスが必要かどうかを確認する短い質問を追加します。

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

ソースの選択

Git リポジトリを使う場合： Blueprint と直接作成のどちらにも必要です。リポジトリは GitHub、GitLab、または Bitbucket にプッシュされている必要があります。

ビルド済み Docker イメージを使う場合： Render はイメージベースのサービスで対応しています。これは MCP では サポートされていません。Dashboard/API を使用してください。次の情報を確認します。

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

ユーザーが Docker イメージを選んだ場合は、Render Dashboard のイメージデプロイフローを案内するか、Git リモートを追加してもらい、runtime: image を使った Blueprint を利用できるようにします。

デプロイ方法の選択（Git リポジトリ）

どちらの方法でも、Git リポジトリを GitHub、GitLab、または Bitbucket にプッシュする必要があります。（runtime: image を使う場合、リポジトリは最小限でよく、render.yaml のみを含めることもできます。）

方法	最適な用途	メリット
Blueprint	複数サービスのアプリ、IaC ワークフロー	バージョン管理、再現性、複雑な構成への対応
直接作成	単一サービス、迅速なデプロイ	すぐに作成でき、render.yaml ファイルが不要

方法選択の目安

ユーザーが特定の方法を希望しない限り、デフォルトでは次の判断ルールを使用します。まずコードベースを分析し、デプロイの意図が不明な場合（例：DB、ワーカー、cron）のみ質問します。

以下の条件をすべて満たす場合は、直接作成（MCP）を使用します。

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

以下のいずれかに該当する場合は、Blueprint を使用します。

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

判断に迷う場合は、簡単な確認質問をします。ただし、安全性を優先してデフォルトでは Blueprint を選択してください。単一サービスの場合は、MCP 経由の直接作成を強く推奨し、必要に応じて MCP のセットアップを案内してください。

前提条件の確認

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

1. ソースの場所を確認する（Git と Docker）

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

git remote -v

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

2. Render へのアクセスを確立する

Render のリソースを読み取ったり変更したりする前に、references/render-access.md に従ってアクセス方法を選択し、認証を行い、対象のワークスペースを確認して、必要な機能が利用できることを確認してください。Blueprint の検証には、MCP を利用できる場合でも Render CLI が必要です。

前提条件を満たしたら、デプロイのワークフローに進んでください。

デプロイを開始、監視、再起動、またはロールバックする前に、references/deployments.md を読み、最新のライフサイクル、ヘルスチェック、検証のワークフローを確認してください。

リソースが Render のプライベートネットワーク経由で通信する場合は、リージョンの選択やアドレスとポートの接続設定を行う前に、references/private-networking.md を読んでください。

サービスタイプを選択または変更する前に、references/service-types.md を読んでください。

---

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

Blueprint のワークフロー

ステップ 1：コードベースを分析する

コードベースを分析し、フレームワーク／ランタイム、ビルドおよび起動コマンド、必要な環境変数、データストア、ポートのバインドを特定してください。references/codebase-analysis.md に記載された詳細なチェックリストを使用してください。

ステップ 2：render.yaml を生成する

Blueprint の仕様に従って render.yaml Blueprint ファイルを作成してください。

ファイルを作成または変更する前に、references/blueprints.md を読み、仕様の取得、検証、リポジトリとの同期、安全性確保に関する最新のワークフローに従ってください。

変数、シークレット、シークレットファイル、または環境グループを扱う場合は、references/environment-variables.md も読んでください。

主なポイント：

• リソースとワークロードに適したコンピュートプランを選択してください。現在の Plan ID、デフォルト、利用可能状況、料金に関するガイダンスについては、このスキルの例を参考にするのではなく、references/compute-plans.md を参照してください。
• ユーザーがリージョンを指定していない場合は、プライベートネットワーク接続を維持できるよう、新しいリソースを関連する既存のサービスと同じリージョンに配置してください。
• アプリに必要な環境変数をすべて含め、references/environment-variables.md にある適切な信頼できる情報源とシークレットの仕組みを使用してください。
• 適切なサービスタイプを使用してください：web、worker、cron、keyvalue、または pserv（静的サイトの場合は runtime: static を指定した type: web）
• 適切なランタイムを使用してください：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、ウェブアプリケーション（パブリックアクセス可能）
• worker：バックグラウンドジョブプロセッサー（パブリックアクセス不可）
• cron：cron スケジュールに従って実行されるスケジュールタスク
• pserv：プライベートサービス（同じアカウントおよびリージョン内でのみ利用可能）
• keyvalue：Redis 互換のキーバリューストア

type: web と runtime: static を指定したサービスは、グローバル CDN 経由で配信される静的サイトです。静的サイトには plan がありません。

Postgres データベースは services キーではなく、databases キーの下に定義します。type はありません。

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

Step 2.5：直ちに行う次の手順（必ず提示）

render.yaml を作成したら、必ずユーザーに明確で簡潔なチェックリストを提示し、CLI が利用可能な場合は直ちに検証を実行してください。

1. アクセスを確認：references/render-access.md に従います
2. 検証：render blueprints validate render.yaml を実行します
   • CLI がインストールされていない場合は、インストールを提案し、コマンドを提示します。
3. コミットしてプッシュ：git add render.yaml && git commit -m "Add Render deployment configuration" && git push origin main
4. ダッシュボードを開く：Blueprint のディープリンクを使い、求められた場合は Git OAuth を完了します
5. シークレットの設定を完了：選択した環境変数のワークフローで必要な値を指定します
6. デプロイ：「Apply」をクリックし、デプロイを監視します

Step 3：設定を検証

references/blueprints.md の検証ワークフローに従います。CLI がインストールされている場合はコマンドを直接実行し、CLI がない場合にのみユーザーに確認してください。

render blueprints validate render.yaml

Blueprint が現在のディレクトリから見て render.yaml にない場合は、実際のファイルパスを指定します。

続行する前に、検証エラーをすべて修正してください。よくある問題：

• 必須フィールド（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：ユーザーを案内

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

次の手順とともに、ディープリンクをユーザーに提示してください。

1. render.yaml がマージされていることを確認 - GitHub／GitLab／Bitbucket のリポジトリにファイルがあることを確認します
2. ディープリンクをクリックして Render ダッシュボードを開きます
3. 求められた場合は Git プロバイダーの OAuth を完了します
4. Blueprint に名前を付けます（または render.yaml のデフォルトを使用します）
5. 値を公開せずに、必要なシークレット設定を完了します
6. サービスとデータベースの設定を確認します
7. 「Apply」をクリックしてデプロイします

デプロイは自動的に開始されます。ユーザーは Render ダッシュボードで進行状況を確認できます。

Step 7：デプロイを確認

ユーザーがダッシュボードからデプロイした後、references/deployments.md に従って、ターミナルでのステータス確認を通じて該当するデプロイを監視し、結果のワークロードを検証します。

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

---

Method 2：サービスを直接作成（単一サービスの迅速なデプロイ）

Infrastructure-as-Code を使わないシンプルなデプロイでは、MCP ツールからサービスを直接作成します。

直接作成を使用するタイミング

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

直接作成の前提条件

リポジトリは 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 を参照してください。

ステップ 1：コードベースを分析する

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

ステップ 2：MCP 経由でリソースを作成する

サービス（ウェブまたは静的）と、必要なデータベースやキーバリューストアを作成します。references/direct-creation.md を参照してください。

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

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

サービス設定を変更する前に、references/environment-variables.md を読んでください。作成後、references/direct-creation.md を使用して、MCP 経由で必要な環境変数を追加します。

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

ステップ 4：デプロイを検証する

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

---

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

---

デプロイ後の検証と基本的なトリアージ（すべての方法）

デプロイ状態の解釈と稼働後の検証については、references/deployments.md に従ってください。いずれかの確認に失敗した場合は、再デプロイする前に修正してください。

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

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

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

最新のドキュメントの取得

このスキルで最新の Render ドキュメントを参照するよう指示された場合は、必ず次の手順に従ってください。

1. 利用可能な URL 取得ツールまたは curl などの HTTP クライアントを使って、リンク先の Markdown ドキュメントを直接取得してください。ウェブ検索の要約でドキュメントの代わりにしないでください。
2. 取得に成功し、想定したドキュメントが返されたことを確認してから、その内容を読んでください。ファイルを保存したり、そのパスを表示したりするだけでは不十分です。
3. リクエストに失敗した場合、またはツールで Markdown の応答を読めない場合は、リンク先の HTML 版を開いて読んでください。
4. どちらの版も取得できない場合は、最新の参照資料を利用できないことを明示し、そのスキルに記載されたトピック別の代替手順に従ってください。安定した制約についてのみ同梱のガイダンスを使用し、変更される可能性のあるプラットフォームの詳細を推測しないでください。

複数の参照資料が必要なタスクでは、それぞれについてこの手順を適用し、確認済みのドキュメントと取得できなかったドキュメントを区別してください。