Skill: ivangdavila/render-deploy (version 1.0.0)

--- name: Render Deploy slug: render-deploy version: 1.0.0 homepage: https://clawic.com/skills/render-deploy description: Deploy applications on Render with codebase analysis, render.yaml Blueprint generation, MCP direct provisioning, and post-deploy verification. changelog: Added end-to-end Render deployment guidance with method selection, runtime checks, and practical troubleshooting flows. metadata: {"clawdbot":{"emoji":"🚀","requires":{"bins":["git","render"],"env":["RENDER_API_KEY"],"config":["~/render-deploy/"]},"primaryEnv":"RENDER_API_KEY","install":[{"id":"brew","kind":"brew","formula":"render","bins":["render"],"label":"Install Render CLI (Homebrew)"}],"os":["linux","darwin","win32"]}} --- ## Setup On first use, read `setup.md` for integration guidelines. If local memory is needed, ask for consent before creating `~/render-deploy/`. ## When to Use Use this skill when the user wants to deploy, publish, or host an application on Render and needs reliable deployment execution instead of generic advice. Activate for render.yaml Blueprint generation, MCP direct service creation, runtime configuration checks, and post-deploy triage. ## Architecture Memory lives in `~/render-deploy/`. See `memory-template.md` for setup. ```text ~/render-deploy/ |- memory.md # Stable preferences and integration choices |- deployment-notes.md # Project-level deployment decisions |- env-inventory.md # Required env vars and source of truth `- incident-log.md # Deploy failures and resolved fixes ``` ## Quick Reference Load only the minimum file needed for the current request. | Topic | File | |-------|------| | Setup process | `setup.md` | | Memory template | `memory-template.md` | | Codebase detection and commands | `codebase-analysis.md` | | Blueprint workflow and render.yaml rules | `blueprint-workflow.md` | | Authentication and MCP execution mapping | `direct-creation.md` | | Startup and healthcheck troubleshooting | `troubleshooting.md` | ## Authentication Model Before any provisioning command, confirm one of these is active: - `RENDER_API_KEY` is exported in the shell, or - Render CLI is authenticated (`render whoami -o json`) For git-backed flows, require `git` and a valid remote URL. Do not attempt opaque credential discovery or unrelated environment inspection. ## Core Rules ### 1. Classify the Deployment Path First Before proposing commands, decide which path applies: - Git-backed deploy (Blueprint or Direct Creation) - Prebuilt Docker image deploy via Dashboard/API If the repository has no remote, stop and ask the user to push a remote or switch to dashboard image deploy. ### 2. Choose Method by Complexity, Not Preference Default decision: - Direct Creation when it is one simple service and no extra infra - Blueprint when there are multiple services, datastores, cron, workers, or reproducibility requirements If uncertainty remains, ask one clarifying question and continue. ### 3. Verify Prerequisites Before Any Deploy Action Run checks in this order: - `git remote -v` for source availability - MCP availability (`list_services()`) - CLI fallback readiness (`render --version`, `render whoami -o json`) - Active workspace context (MCP or CLI) - Authentication presence (`RENDER_API_KEY` or authenticated CLI session) Do not proceed to deployment steps when prerequisites are missing. ### 4. Treat `render.yaml` as Executable Infrastructure When using Blueprint: - Declare all required env vars - Mark user-provided secrets with `sync: false` - Prefer `plan: free` unless user requests another plan - Match service type and runtime to the actual app behavior After creating the file, validate before push. ### 5. Require Push Before Deeplink Handoff Before sharing a Render Blueprint deeplink, confirm `render.yaml` is committed and pushed to the remote branch. If not pushed, the Dashboard flow will fail to discover the configuration. ### 6. Verify the Deployment and Close With Evidence After deployment: - Confirm latest deploy status is live - Check health endpoint response - Review recent error logs - Validate required env vars and port binding (`0.0.0.0:$PORT`) If failures exist, run one-fix-at-a-time triage from `troubleshooting.md`. ## Common Traps - Starting deploy without a git remote -> Blueprint and MCP git-backed flows fail immediately. - Picking Direct Creation for multi-service systems -> Missing workers/datastores and fragmented setup. - Forgetting `sync: false` on secrets -> Broken deploys or accidental secret exposure in config. - Using localhost binding instead of `0.0.0.0:$PORT` -> Health checks fail even when process is running. - Redeploying repeatedly without root-cause fix -> Noisy failures and delayed resolution. ## External Endpoints | Endpoint | Data Sent | Purpose | |----------|-----------|---------| | https://dashboard.render.com | Repository URL, service config, env key names | Blueprint apply flow and dashboard provisioning | | https://mcp.render.com | Service creation/config requests and workspace-scoped metadata | MCP direct provisioning | | https://api.render.com | Deployment metadata, logs, service status (via CLI/API) | Validation and operational checks | No other endpoints should be used unless the user requests an explicit integration. ## Security & Privacy **Data that leaves your machine:** - Repository URL and deployment metadata sent to Render services. - Environment variable names and provided values when the user explicitly sets them. **Data that stays local:** - Preferences and deployment history in `~/render-deploy/` if the user accepts memory. - Local codebase inspection outputs and interim analysis notes. **This skill does NOT:** - Read unrelated credentials outside the deployment context. - Scrape credentials from shell history, dotfiles, or unrelated config paths. - Send project files to undeclared third-party endpoints. - Run destructive infrastructure changes without explicit confirmation. ## Trust By using this skill, deployment metadata and selected configuration are sent to Render services. Only use it if you trust Render with this operational data. ## Related Skills Install with `clawhub install <slug>` if user confirms: - `deploy` - General deployment planning and release execution. - `devops` - CI/CD, infrastructure workflows, and ops coordination. - `docker` - Container packaging and runtime configuration. - `ci-cd` - Pipeline automation and release validation stages. - `nodejs` - Runtime-specific app configuration and startup tuning. ## Feedback - If useful: `clawhub star render-deploy` - Stay updated: `clawhub sync`

path: blueprint-workflow.md
content: # Blueprint Workflow - render.yaml

Use this flow for multi-service or reproducible deployments.

## 1. Build a Complete render.yaml

Required baseline:

```yaml
services:
  - type: web
    name: app
    runtime: node
    plan: free
    buildCommand: npm ci
    startCommand: npm start
    envVars:
      - key: NODE_ENV
        value: production
      - key: JWT_SECRET
        sync: false
```

Rules:
- Use `plan: free` unless user requests another plan.
- Declare all env vars explicitly.
- Mark user-supplied secrets with `sync: false`.
- Use `fromDatabase` references when provisioning managed datastores.

## 2. Validate Before Push

If CLI is available:

```bash
render whoami -o json
render blueprints validate
```

Do not continue when validation fails.

## 3. Commit and Push

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

Blueprint deeplinks only work when the file is already in the remote repository.

## 4. Generate Dashboard Deeplink

Convert remote to HTTPS if needed and use:

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

## 5. Final Verification

After apply in dashboard:
- Confirm deploy status is live.
- Check health endpoint.
- Scan recent error logs.


path: codebase-analysis.md
content: # Codebase Analysis - Render Deploy

Use this file to detect runtime, build/start commands, and infra requirements before choosing a deploy method.

## Stack Detection Checklist

### Node.js
- Inspect `package.json` scripts and engines.
- Detect package manager by lock file.
- Confirm start command binds to `$PORT`.

Default command mapping:
- `pnpm-lock.yaml` -> `pnpm install --frozen-lockfile` + `pnpm start`
- `yarn.lock` -> `yarn install --frozen-lockfile` + `yarn start`
- `package-lock.json` -> `npm ci` + `npm start`

### Python
- Detect package manager from `uv.lock`, `poetry.lock`, `Pipfile.lock`, or `requirements.txt`.
- Identify framework (Django, Flask, FastAPI).
- Verify runtime pin from `runtime.txt`, `.python-version`, or `pyproject.toml`.

Default command mapping:
- `requirements.txt` -> `pip install -r requirements.txt` + `gunicorn app:app --bind 0.0.0.0:$PORT`
- FastAPI -> `uvicorn main:app --host 0.0.0.0 --port $PORT`

### Go
- Read `go.mod` for version and dependencies.
- Build with `go build -o bin/app .` unless repo structure requires a specific entrypoint.

### Static Site
- Detect output folder (`dist`, `build`, `out`, `public`).
- Prefer static runtime if no server-side rendering is required.

## Data and Infra Detection

Collect this before method selection:
- Required environment variables
- Database or key-value needs
- Need for worker/cron/private service
- Health endpoint availability

If the app needs web + worker + datastore, default to Blueprint.


path: direct-creation.md
content: # Direct Creation - MCP

Use this flow for simple single-service deployments.

## Preconditions

- Git repository is pushed to GitHub, GitLab, or Bitbucket.
- Render MCP is configured and workspace is selected.
- `RENDER_API_KEY` is available for MCP authentication.
- Service does not require complex multi-service orchestration.

## Execution Mapping

- `list_services`, `create_web_service`, `update_environment_variables`, and `list_deploys` map to Render MCP operations on `https://mcp.render.com`.
- If MCP is not available, switch to CLI fallback explicitly (`render services -o json`, `render deploys ...`) and keep the same safety checks.
- Never call undeclared endpoints or infer hidden credentials.

## Core Flow

### 1. Create service

```text
create_web_service(
  name: "my-app",
  runtime: "node",
  repo: "https://github.com/user/repo",
  branch: "main",
  buildCommand: "npm ci",
  startCommand: "npm start",
  plan: "free",
  region: "oregon"
)
```

### 2. Add environment variables

```text
update_environment_variables(
  serviceId: "<service-id>",
  envVars: [
    {"key": "NODE_ENV", "value": "production"},
    {"key": "JWT_SECRET", "value": "<secret>"}
  ]
)
```

### 3. Verify deploy

```text
list_deploys(serviceId: "<service-id>", limit: 1)
list_logs(resource: ["<service-id>"], level: ["error"], limit: 50)
```

If MCP calls fail due to auth/workspace errors, stop and resolve auth first:
- Ensure `RENDER_API_KEY` is set, then reconnect MCP.
- Verify workspace selection before retrying provisioning commands.

## Escalate to Blueprint When

Switch methods if any of these appear:
- Additional worker/cron/private services
- Datastore wiring across multiple services
- Need for reproducibility and infra-as-code handoff


path: memory-template.md
content: # Memory Template - Render Deploy

Create `~/render-deploy/memory.md` with this structure:

```markdown
# Render Deploy Memory

## Status
status: ongoing
version: 1.0.0
last: YYYY-MM-DD
integration: pending

## Context
<!-- Preferred deployment method and Render workspace scope -->
<!-- Git provider, branch conventions, and rollout expectations -->

## Deployment Preferences
<!-- Blueprint vs Direct Creation defaults -->
<!-- Preferred validation depth and handoff style -->

## Environment Inventory
<!-- Required env var names, ownership, and source (dashboard, generated, db reference) -->

## Notes
<!-- Durable observations only -->

---
*Updated: YYYY-MM-DD*
```

## deployment-notes.md Template

Create `~/render-deploy/deployment-notes.md`:

```markdown
# Deployment Notes

## YYYY-MM-DD - Project
Method: blueprint | direct-creation | dashboard-image
Workspace: ...
Repo: ...
Services: ...
Datastores: ...
Result: success | blocked | failed
Summary: ...
```

## env-inventory.md Template

Create `~/render-deploy/env-inventory.md`:

```markdown
# Environment Inventory

| Variable | Scope | Source | Secret | Last Checked |
|----------|-------|--------|--------|--------------|
| DATABASE_URL | web | fromDatabase | no | YYYY-MM-DD |
| JWT_SECRET | web | dashboard | yes | YYYY-MM-DD |
```

## incident-log.md Template

Create `~/render-deploy/incident-log.md`:

```markdown
# Incident Log

## INC-001
Date: YYYY-MM-DD
Failure class: build | startup | health | runtime
Signature: ...
Root cause: ...
Fix: ...
Verification: pending | passed | failed
```

## Status Values

| Value | Meaning | Behavior |
|-------|---------|----------|
| `ongoing` | Default mode | Keep learning deploy constraints over time |
| `complete` | Stable context | Reuse known method/workspace defaults |
| `paused` | User wants fewer prompts | Apply known defaults with minimal setup questions |
| `never_ask` | User rejected setup prompts | Stop integration prompts and run only on explicit requests |


path: setup.md
content: # Setup - Render Deploy

Read this when `~/render-deploy/` is missing or empty.

## Your Attitude

Act as a deployment engineer focused on safe execution. Keep guidance concrete, sequence-driven, and tied to verifiable results.

## Priority Order

### 1. First: Activation and Scope

Within the first exchanges, clarify:
- Should this skill activate for every deployment request or only when Render is explicit?
- Should it proactively check deploy readiness (git remote, env vars, health endpoint) during related tasks?

Before creating local memory files, request consent and explain what will be stored.

### 2. Then: Deployment Context

Capture only context that changes decisions:
- Git provider and branch strategy
- Preferred method (Blueprint vs Direct Creation)
- Expected services (web, worker, cron, static, private)
- Datastore needs (Postgres, Key Value) and secret management constraints

### 3. Finally: Operational Preferences

Calibrate delivery style:
- Fast path: minimal viable deploy and smoke test
- Robust path: reproducible Blueprint plus validation checkpoints
- Incident path: triage-first workflow with clear rollback-safe changes

Infer preference from behavior before asking extra questions.

## What You Save Internally

Store durable context only:
- Integration preference and activation boundaries
- Workspace and method preference
- Stable env var inventory (names and ownership, not secret values unless user asks)
- Recurrent failure signatures and validated fixes

Store only in `~/render-deploy/` after explicit user consent.

## Golden Rule

Optimize for successful, observable deployments with minimal risk and clear verification evidence.


path: troubleshooting.md
content: # Troubleshooting - Render Deploy

Use this when build, startup, or health checks fail. Fix one issue at a time.

## Failure Classes

1. Build failure
- Wrong build command
- Missing dependencies
- Missing build-time env vars

2. Startup failure
- Wrong start command
- App not binding to `0.0.0.0:$PORT`
- Missing runtime secrets

3. Health/runtime failure
- No healthy endpoint response
- Runtime exceptions after startup
- Downstream dependency failure

## Quick Signature Map

| Signature | Likely cause | First fix |
|----------|--------------|-----------|
| `Cannot find module` | Missing dependency | Add dependency and rebuild |
| `ModuleNotFoundError` | Missing Python package | Update requirements and rebuild |
| `EADDRINUSE` or bind error | Wrong port strategy | Bind to `0.0.0.0:$PORT` |
| `connection refused` | DB unavailable or bad URL | Verify DB state and connection string |
| health check timeout | App not healthy on expected path | Add/verify health endpoint |

## Minimal Triage Loop

1. Confirm latest deploy status.
2. Read top runtime errors.
3. Apply smallest safe fix.
4. Redeploy and re-check health.

Avoid repeated redeploys without an actual fix.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (MEDIUM)