render-deploy

Name: render-deploy
Author: tech-leads-club

github.com/tech-leads-clubクラウド・DevOps7.1k193 回インストール今日更新

リポジトリ

render-deploy について

render-deployは、GitリポジトリからRenderへアプリをデプロイするためのスキルです。Blueprintの設定やサービスの直接作成に加え、事前確認、検証、認証情報の管理を案内します。

主な機能

01Blueprintまたは直接作成の選択
02render.yaml設定の生成
03リポジトリと前提条件の確認
04CLIによるBlueprint設定の検証
05APIキーとシークレットの安全な管理

活用シーン

01単一のWebサービスのデプロイ
02複数サービスのアプリ構成
03データベース、ワーカー、Cronジョブの設定

MCP 対応

単一サービスのデプロイでは、Render MCPツールを使ってワークスペースを確認し、サービスを作成できます。Render MCPサーバーの設定方法や、CLIを使う場面も説明します。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/tech-leads-club/agent-skills --skill render-deploy

インストール後、Claude Code で/render-deployを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

LICENSE.txt

references/

blueprint-spec.md

codebase-analysis.md

configuration-guide.md

deployment-details.md

direct-creation.md

error-patterns.md

post-deploy-checks.md

runtimes.md

service-types.md

troubleshooting-basics.md

詳細

Render へのデプロイ

Render は、Git に紐づくサービスとビルド済み Docker イメージのサービスに対応しています。

このスキルでは、Git に紐づく方法を扱います。

Blueprint 方式 - Infrastructure-as-Code デプロイ用の render.yaml を生成します
直接作成 - MCP ツールを使ってサービスをすぐに作成します

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

Git リモートがない場合は、作業を中止して、次のいずれかをユーザーに依頼してください。

Git リモートを作成してプッシュする（Blueprint だけが必要な場合は、最小限のリポジトリでも構いません）、または
Render Dashboard/API を使ってビルド済み Docker イメージをデプロイする（MCP ではイメージを使ったサービスを作成できません）

前提条件

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

API キーとシークレットのセキュリティ要件

重要 — ユーザーの認証情報を必ず保護してください。

Render API キーやシークレットを扱う場合：

API キーをチャットに直接貼り付けるよう、ユーザーに絶対に求めないでください。 代わりに、環境変数を設定するよう案内してください。
```
export RENDER_API_KEY="rnd_xxxxx"
```
実際の API キーを例に含めないでください。 常に <YOUR_API_KEY> や rnd_xxxxx などのプレースホルダーを使用してください。
安全な保管方法を案内してください。 次の方法を伝えてください。
- CLI 認証用の環境変数を設定する
- サービスのシークレットには Render Dashboard を使用する（sync: false と指定された環境変数）
- シークレットを Git にコミットしない
ユーザーが API キーを必要としている場合は、次の案内をしてください。
- 「API キーは https://dashboard.render.com/u/*/settings#api-keys から取得してください」
- 「環境変数として設定してください：export RENDER_API_KEY='your-key-here'」
- 「このキーを共有したり、コミットしたりしないでください」
MCP の設定を提示する場合は、構成を示しつつ、次の点を強調してください。
- <YOUR_API_KEY> を実際のキーに置き換える
- このファイルをバージョン管理にコミットしない
- キーを非公開にする
ユーザーが誤ってチャットにシークレットを共有した場合は、直ちに次の対応をしてください。
- キーが漏えいした可能性があると警告する
- Render Dashboard でキーを失効させるよう伝える
- 新しいキーの作成を案内する

このスキルを使う場面

ユーザーが次のことを希望している場合に、このスキルを有効にしてください。

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

推奨手順（新規ユーザー向け）

やり取りを簡潔にするため、詳細な分析を始める前に、次の短い順序で質問してください。

Git リポジトリからデプロイするか、ビルド済み Docker イメージからデプロイするかを尋ねます。
Render にアプリに必要なものをすべて用意させるか（ユーザーの説明から可能性が高いものを判断します）、ユーザーが独自のインフラを用意してアプリのみをデプロイするかを尋ねます。依存関係が不明な場合は、データベース、ワーカー、cron、その他のサービスが必要か、短く追加で確認します。

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

デプロイ元を選ぶ

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

ビルド済み Docker イメージを使う方法： Render ではイメージを使ったサービスに対応しています。MCP では対応していません。 Dashboard/API を使用してください。次の情報を確認します。

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

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

デプロイ方法を選択する（Git リポジトリ）

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

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

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

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

以下のすべてに当てはまる場合は、Direct Creation（MCP）を使用します：

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

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

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

判断に迷う場合は、簡単な確認質問をしてください。ただし、安全性を優先して Blueprint をデフォルトとします。単一サービスの場合は、MCP 経由の Direct Creation を強く推奨し、必要に応じて 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

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

Render API キーを取得します：

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

<YOUR_API_KEY> を置き換えて、これを ~/.cursor/mcp.json に追加します：

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

Cursor を再起動し、list_services() をもう一度実行します。

Claude Code

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

Render API キーを取得します：

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

<YOUR_API_KEY> を置き換えて、Claude Code で MCP サーバーを追加します：

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

Claude Code を再起動し、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()

ワークスペースを切り替える必要がある場合は、Dashboard または CLI（render workspace set）から切り替える必要があります。

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

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

Blueprint のワークフロー

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

コードベースを分析し、フレームワーク／ランタイム、ビルドコマンドと起動コマンド、必要な環境変数、データストア、ポートのバインドを特定します。references/codebase-analysis.md の詳細なチェックリストを使用します。

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

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

仕様の全文：references/blueprint-spec.md

主なポイント：

ユーザーが別途指定しない限り、常に plan: free を使用します
アプリに必要な環境変数をすべて含めます
シークレットには sync: false を指定します（ユーザーが Dashboard で入力します）
適切なサービスタイプ（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/

ステップ 2.5：直後に行う手順（必ず提示）

render.yaml の作成後、必ずユーザーに簡潔で具体的なチェックリストを提示し、CLI が利用可能な場合はすぐに検証を実行します。

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

ステップ 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: ユーザーに案内する

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

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

render.yaml がマージされていることを確認する - GitHub／GitLab／Bitbucket のリポジトリにファイルが存在することを確認します
ディープリンクをクリックして Render ダッシュボードを開きます
求められた場合は、Git プロバイダーの OAuth を完了します
Blueprint に名前を付けます（または render.yaml のデフォルト名を使用します）
シークレット環境変数（sync: false と指定されているもの）を入力します
サービスとデータベースの設定を確認します
「Apply」をクリックしてデプロイします

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

Step 7: デプロイを確認する

ユーザーがダッシュボードからデプロイした後、すべてが正常に動作していることを確認します。

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 ファイルが不要な場合
既存のプロジェクトにデータベースや cron ジョブを追加する場合

直接作成の前提条件

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

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

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

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

注： MCP は、イメージを使用するサービスの作成に対応していません。ビルド済み Docker イメージをデプロイする場合は、ダッシュボードまたは API を使用してください。

直接作成のワークフロー

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

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

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

ステップ 2：MCP を使用してリソースを作成する

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

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

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

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

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

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

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

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

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

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

最新のデプロイが live で、トラフィックを処理していることを確認します
ヘルスエンドポイント（またはルート）にアクセスし、200 レスポンスを確認します
最近のエラーログを確認し、明確な失敗の兆候がないか調べます
必要な環境変数とポートのバインド（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 スキルのインストールを提案してください。基本的なデプロイの手順には必要ありません。

Markdown 対応

ログインしてコメント

基本情報

作者: tech-leads-club
リポジトリ: tech-leads-club/agent-skills
カテゴリ: クラウド・DevOps
インストール数: 193
GitHub スター: 7,120

問題を報告