Blueprint validation and AI tool integration

Two CLI surfaces sit a bit apart from the deploy/log/ssh core. They’re both quick wins that punch above their weight: render blueprints validate is the cheapest CI check you can add, and render skills is the one-command path to teaching your AI tools the right Render answers.

render blueprints validate

render.yaml is the file that describes your services declaratively. The validate command parses it, checks the schema, and runs semantic checks - broken fromService references, duplicate names, deprecated fields. Same checks Render runs before a Blueprint sync, so a green local run is a strong signal the sync will succeed.

render blueprints validate

Defaults to ./render.yaml. To validate a file elsewhere:

render blueprints validate path/to/render.yaml

Exit code is 0 on valid, non-zero on invalid. No API key required - it’s a pure schema check.

What it catches

Static, fast, free. Worth running every time you touch the file.

Run it in CI

The 14-line workflow that pays for itself the first time it catches a bad rename:

name: Validate render.yaml
on:
  pull_request:
    paths:
      - "render.yaml"
      - ".github/workflows/render-blueprint.yml"

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install the Render CLI
        run: |
          curl -fsSL https://raw.githubusercontent.com/render-oss/cli/main/bin/install.sh | sh
          echo "$HOME/.render/bin" >> "$GITHUB_PATH"
      - name: Validate Blueprint
        run: render blueprints validate

The paths: filter keeps it idle on PRs that don’t touch render.yaml. No API key needed - validate doesn’t talk to the Render API.

Wire the JSON schema into your editor

Editor diagnostics catch typos as you type, which is faster than waiting for render blueprints validate to tell you. Render publishes a stable schema URL - wire it up once per editor.

{
  "yaml.schemas": {
    "https://render.com/schema/render.yaml.json": [
      "render.yaml",
      "render.*.yaml"
    ]
  }
}

require("lspconfig").yamlls.setup({
  settings = {
    yaml = {
      schemas = {
        ["https://render.com/schema/render.yaml.json"] = {
          "render.yaml",
          "render.*.yaml",
        },
      },
    },
  },
})

The full validation loop is three layers - editor, CLI, CI - covered in depth in the Advanced Blueprint patterns tutorial.

render skills: AI tools that know Render

Render publishes a library of “skills” - short, structured guides that AI coding tools (Cursor, Claude Code, Codex, and others) load on demand. They cover the same surfaces this course does, but in a form your assistant can act on directly.

render skills install

The command writes skill files to the standard locations your AI tools already read (~/.claude/skills, ~/.codex/skills, ~/.agents/skills, etc.). After installation, when you ask your assistant “deploy this app to Render” or “how do I run a Render Postgres query from CI?”, it has the right reference material loaded automatically.

List and update

render skills list
render skills update

list shows what’s installed and which version; update pulls the latest skill content.

Pair with the MCP server

The skills tell your AI tool what to do. The Render MCP server gives it the ability to do it - list services, fetch logs, trigger deploys - without leaving the editor. Point your AI client at mcp.render.com with your API key and the loop closes: the model knows what to do (from skills) and can actually do it (via MCP).

The Render docs have the per-tool setup at render.com/docs/mcp. Setup is a one-time copy-paste per tool.

Custom shell wrappers (the runbook)

Tie everything from steps 02 to 08 into one personal runbook. Drop this in ~/.zshrc (or ~/.bashrc) and reload:

# Render power-user aliases and functions

alias r='render'
alias rs='render services'
alias rsj='render services -o json'

render-prod() {
  RENDER_API_KEY=$RENDER_PROD_API_KEY render "$@"
}

render-stg() {
  RENDER_API_KEY=$RENDER_STAGING_API_KEY render "$@"
}

render-id() {
  render services -o json \
    | jq -r --arg n "$1" '.[] | select(.service.name == $n) |.service.id'
}

render-describe() {
  render services -o json \
    | jq --arg n "$1" '.[] | select(.service.name == $n) |.service'
}

render-deploy() {
  local svc; svc=$(render-id "$1"); shift
  [[ -z "$svc" ]] && { echo "No service '$1'"; return 2; }
  render deploys create "$svc" --wait --confirm -o json "$@"
}

render-tail() {
  local svc; svc=$(render-id "$1")
  [[ -z "$svc" ]] && { echo "No service '$1'"; return 2; }
  render logs -r "$svc" --tail
}

render-q() {
  # render-q <db-name> "SQL..."
  local db; db=$(render-id "$1"); shift
  [[ -z "$db" ]] && { echo "No db '$1'"; return 2; }
  render psql "$db" -c "$*" -o json | jq
}

Now your day-to-day shape collapses to:

render-deploy api
render-tail api
render-q app-db "SELECT count(*) FROM users WHERE created_at > NOW() - INTERVAL '1 day';"
render-prod services
render-stg deploys list "$(render-stg services -o json | jq -r '.[0].service.id')"

You can read what’s running, ship a change, watch the boot, and query the database without typing more than the verb and the name. That’s the goal.

What’s not in the CLI

A few things the CLI deliberately doesn’t do (yet) - and where they live instead:

For the gaps, the Render API covers everything the CLI doesn’t - and an MCP-enabled AI tool can call it directly without you writing any HTTP code.