Update to Render

{
  "description": "Authors and validates render.yaml Blueprints for Render infrastructure. Use when the user needs to write or edit a render.yaml, wire services together with fromDatabase/fromService/fromGroup, set up projects and environments for multi-service apps, configure preview environments, validate against the schema, or fix immutable field errors. Trigger terms: render.yaml, Blueprint, IaC, fromDatabase, fromService, envVarGroups, previews, projects, environments.",
  "included_files": [
    {
      "relative_path": "references/blueprints.md",
      "size_in_bytes": 2850
    },
    {
      "relative_path": "references/common-mistakes.md",
      "size_in_bytes": 4576
    },
    {
      "relative_path": "references/compute-plans.md",
      "size_in_bytes": 2386
    },
    {
      "relative_path": "references/environment-variables.md",
      "size_in_bytes": 4653
    },
    {
      "relative_path": "references/field-reference.md",
      "size_in_bytes": 8948
    },
    {
      "relative_path": "references/persistent-disks.md",
      "size_in_bytes": 3821
    },
    {
      "relative_path": "references/preview-environments.md",
      "size_in_bytes": 4906
    },
    {
      "relative_path": "references/private-networking.md",
      "size_in_bytes": 4390
    },
    {
      "relative_path": "references/service-types.md",
      "size_in_bytes": 4703
    },
    {
      "relative_path": "references/wiring-patterns.md",
      "size_in_bytes": 3798
    }
  ],
  "name": "render-blueprints",
  "skill_md_contents": "---\nname: render-blueprints\ndescription: >-\n  Authors and validates render.yaml Blueprints for Render infrastructure. Use\n  when the user needs to write or edit a render.yaml, wire services together\n  with fromDatabase/fromService/fromGroup, set up projects and environments\n  for multi-service apps, configure preview environments, validate against\n  the schema, or fix immutable field errors. Trigger terms: render.yaml,\n  Blueprint, IaC, fromDatabase, fromService, envVarGroups, previews, projects,\n  environments.\nlicense: MIT\ncompatibility: >-\n  Git repository on GitHub, GitLab, or Bitbucket for Blueprint sync. Render CLI\n  v2.7.0+ recommended for `render blueprints validate`. IDEs can validate\n  against the public JSON Schema URL below.\nmetadata:\n  author: Render\n  version: \"1.0.0\"\n  category: configuration\n---\n\n# Render Blueprints (render.yaml)\n\nBlueprints define Render infrastructure as YAML (commonly `render.yaml` at the repo root). This skill focuses on **authoring**, **wiring**, **projects/environments**, **previews**, **validation**, and **immutable fields**. Heavy detail lives under `references/`.\n\nBefore creating or modifying a Blueprint, read `references/blueprints.md` for the current specification-fetch, validation, repository-sync, and safety workflow.\n\nFor current compute-plan terminology, Plan IDs, and availability, use `references/compute-plans.md` instead of relying on plan catalogs embedded in examples.\n\nBefore adding or changing a service-attached disk, read `references/persistent-disks.md` for current architectural constraints and configuration workflow.\n\nBefore wiring private-network addresses, ports, or discovery hostnames, read `references/private-networking.md`.\n\nBefore choosing a service type or translating its Dashboard name to Blueprint structure, read `references/service-types.md`.\n\n## When to Use\n\nApply this skill when the user:\n\n- Creates or edits a `render.yaml` / Blueprint\n- Wires databases, private services, or Key Value into app env vars\n- Groups services with **projects** and **environments**\n- Configures **preview environments** for pull requests\n- Validates YAML against Render’s schema or CLI\n- Asks what can or cannot change after a resource is created\n\nFor end-to-end deploy flows and MCP/CLI operations, see **render-deploy**. For env var strategy outside Blueprint syntax, see **render-env-vars**. For Docker-specific Blueprint fields, see **render-docker**.\n\n## Blueprint Structure\n\n### Top-level keys\n\n| Key | Purpose |\n|-----|---------|\n| `services` | Web, worker, cron, private service, Key Value, static (via `web` + `runtime: static`) |\n| `databases` | Managed PostgreSQL instances |\n| `envVarGroups` | Reusable env var sets attached to services |\n| `projects` | Optional grouping; contains `environments` and service lists |\n| `previews` | Defaults for PR preview environments |\n\nA Blueprint may also use patterns like **ungrouped** resources vs **environment-scoped** lists, depending on whether you adopt the projects model. See `references/common-mistakes.md` for duplication and naming pitfalls.\n\n### Minimal example: web + PostgreSQL\n\n```yaml\ndatabases:\n  - name: mydb\n    plan: basic-256mb\n    region: oregon\n\nservices:\n  - type: web\n    name: api\n    runtime: node\n    region: oregon\n    plan: starter\n    buildCommand: npm ci && npm run build\n    startCommand: npm start\n    envVars:\n      - key: DATABASE_URL\n        fromDatabase:\n          name: mydb\n          property: connectionString\n```\n\n## Service Types\n\n| `type` | Role |\n|--------|------|\n| `web` | Public HTTP service (use `runtime: static` for static sites) |\n| `pserv` | Private service (internal HTTP/TCP; not public) |\n| `worker` | Long-running background process |\n| `cron` | Scheduled job (`schedule` required) |\n| `keyvalue` | Managed Key Value (Redis-compatible); alias **`redis`** accepted in Blueprints |\n\n## Runtimes\n\nCommon `runtime` values: **`node`**, **`python`**, **`go`**, **`ruby`**, **`rust`**, **`elixir`**, **`docker`**, **`image`**, **`static`**.\n\n- **`docker`**: Build from `Dockerfile` (see `dockerfilePath`, `dockerContext`, `dockerCommand`).\n- **`image`**: Run a prebuilt container image with `image.url` and optional `image.creds.fromRegistryCreds`.\n- **`static`**: Static site; requires `staticPublishPath` and build output paths (see references).\n\n## Cross-Service Wiring\n\nBefore configuring variables, secrets, secret files, or environment groups, read `references/environment-variables.md`.\n\nService env vars under `envVars` can pull values from other resources instead of hardcoding secrets. Environment-group variables cannot reference services, databases, or other environment groups.\n\n### `fromDatabase`\n\nReference a database in `databases:` by `name`. Properties include:\n\n- `connectionString`, `connectionPoolString`, `host`, `port`, `user`, `password`, `database`\n\n### `fromService`\n\nReference a service by `name`. Typical properties:\n\n- `host`, `port`, `hostport`, `connectionString`, `envVarKey`\n\nWhich properties are valid depends on target service type (e.g. Key Value vs `pserv`). See `references/wiring-patterns.md`.\n\n### `fromGroup`\n\nAttach shared vars from `envVarGroups` (by group `name`).\n\nFull patterns and combinations: `references/wiring-patterns.md`.\n\n## Projects and Environments\n\nFor multi-service apps, use the **`projects`/`environments`** pattern instead of flat top-level `services`/`databases`. This groups all related resources into a single Render project, supports multiple environments (production, staging), and enables environment-scoped configuration.\n\n```yaml\nprojects:\n  - name: my-app\n    environments:\n      - name: production\n        services:\n          - type: web\n            name: api\n            runtime: node\n            plan: standard\n            buildCommand: npm ci && npm run build\n            startCommand: npm start\n            envVars:\n              - key: DATABASE_URL\n                fromDatabase:\n                  name: db\n                  property: connectionString\n              - key: REDIS_URL\n                fromService:\n                  type: keyvalue\n                  name: cache\n                  property: connectionString\n              - key: API_SECRET\n                sync: false\n\n          - type: worker\n            name: jobs\n            runtime: node\n            plan: starter\n            buildCommand: npm ci\n            startCommand: node worker.js\n            envVars:\n              - key: DATABASE_URL\n                fromDatabase:\n                  name: db\n                  property: connectionString\n              - key: REDIS_URL\n                fromService:\n                  type: keyvalue\n                  name: cache\n                  property: connectionString\n\n          - type: keyvalue\n            name: cache\n            plan: starter\n            maxmemoryPolicy: noeviction\n            ipAllowList: [] # Internal access only\n\n        databases:\n          - name: db\n            plan: basic-256mb\n```\n\nKey rules:\n\n- Each environment owns its `services` and `databases` lists.\n- Do not define the same resource at both the root level and inside an environment.\n- `envVarGroups` can be scoped to a project environment or shared across the workspace.\n- With a Pro workspace or higher, environment isolation can block cross-environment private network traffic.\n\nFor single-service apps, flat top-level `services`/`databases` is fine. Reach for the projects pattern when you have multiple services, need staging/production separation, or want environment-scoped env groups.\n\n## Preview Environments\n\nWhen a preview request is underspecified, first establish the desired generation mode, retention period, preview compute plans, and whether the user expects to exclude any resources.\n\nTop-level `previews` controls Blueprint preview environments:\n\n- **`previews.generation`**: `off` (default), `manual`, or `automatic`\n- **`previews.expireAfterDays`**: Auto-delete preview stacks after N days\n\nDo not confuse preview environments with service previews:\n\n- A top-level `previews.generation: automatic` creates the Blueprint's preview environment, including the resources declared by that Blueprint.\n- A service-level `previews.generation` controls that service's independent service previews. It does **not** override the Blueprint preview environment or exclude that service from it. It accepts only `manual` or `automatic`; omit it to disable independent service previews.\n- Use `previews.plan` and `previews.numInstances` on compute services to size their preview-environment instances. Key Value and Postgres use `previewPlan` instead.\n\nIf a user needs a worker or another resource omitted entirely from Blueprint preview environments, explain that service-level preview generation is not an exclusion mechanism; the Blueprint or application architecture must account for that requirement. Other limitations include autoscaling behavior, `sync: false` variables, and database plan compatibility—see `references/preview-environments.md`.\n\n## Immutable Fields\n\n**CRITICAL:** Some fields cannot change after the resource is created. Edits may be rejected or require replacement resources.\n\n### Services\n\n- **`type`**: Cannot change (e.g. web → worker).\n- **`runtime`**: Cannot change (e.g. node → docker).\n\n### Databases\n\nCannot change after creation:\n\n- `name` (logical Blueprint/database identifier in this context)\n- `databaseName`\n- `user`\n- `region`\n- `postgresMajorVersion`\n\nPlan other fields (disk, HA, replicas) carefully up front; consult Render docs for fields that can scale vs require recreation.\n\n## Key Fields (Quick Map)\n\n| Area | Fields |\n|------|--------|\n| Plans | `plan`; compute-service `previews.plan`; Key Value/Postgres `previewPlan` |\n| Build/run | `buildCommand`, `startCommand`, `preDeployCommand`, `rootDir` |\n| Deploy | `autoDeployTrigger`: `commit`, `checksPass`, or `off` |\n| Lifecycle | `maxShutdownDelaySeconds`: 1–300, default **30** |\n| HTTP | `healthCheckPath`, `domains` |\n| Storage | `disk` (`name`, `mountPath`, `sizeGB`) |\n| Scale | `scaling` / `numInstances` (see references) |\n| Monorepo | `buildFilter` (`paths`, `ignoredPaths`) |\n| Docker | `dockerfilePath`, `dockerContext`, `dockerCommand`, `registryCredential`; prebuilt `image.url` / `image.creds` |\n\nDeprecated names to avoid: `env` (use `runtime`), `redis` (use `keyvalue`), `autoDeploy` (use `autoDeployTrigger`), `previewsEnabled`, and `pullRequestPreviewsEnabled`. Use the appropriate top-level or service-level `previews.generation` replacement described in `references/common-mistakes.md`.\n\n## References\n\n| Document | Contents |\n|----------|----------|\n| `references/blueprints.md` | Current Blueprint specification, schema, validation, repository-sync, and safety workflow |\n| `references/compute-plans.md` | Current compute-plan terminology, Plan ID discovery, availability, and change behavior |\n| `references/environment-variables.md` | Current environment-variable documentation, secrets, groups, platform variables, and mutation safety |\n| `references/persistent-disks.md` | Service-attached disk constraints, current documentation, sizing, snapshots, and Blueprint workflow |\n| `references/private-networking.md` | Private-network scope, addresses, Blueprint references, discovery, ports, and isolation |\n| `references/service-types.md` | Service-type selection, execution models, and Blueprint naming |\n| `references/field-reference.md` | YAML fields by service type, database, groups, projects, previews, scaling, disk, static, Key Value |\n| `references/wiring-patterns.md` | `fromDatabase` / `fromService` / `fromGroup` examples and combined wiring patterns |\n| `references/common-mistakes.md` | Branch + previews, `buildFilter`, replicas, duplicates, preview plans, wiring mistakes |\n| `references/preview-environments.md` | `previews.generation`, expiry, `previews.plan`, `previewPlan`, disks, PR workflow |\n\n## Related Skills\n\n- **render-deploy** — Deploy flows, Blueprint vs direct create, MCP/deeplinks\n- **render-env-vars** — Env var strategy, secrets, Dashboard vs Blueprint\n- **render-docker** — Dockerfile-backed services and image runtime nuances\n\n<!-- shared:documentation-retrieval -->\n## Current documentation retrieval\n\nWhenever this skill directs you to consult current Render documentation:\n\n1. Retrieve the linked Markdown document directly with an available URL-fetching tool or HTTP client, such as `curl`. Do not substitute web-search summaries for the document.\n2. Confirm that retrieval succeeded and returned the expected document, then read its contents. Saving a file or printing its path is not sufficient.\n3. If the request fails or your tool cannot read the Markdown response, open and read the linked HTML version instead.\n4. If neither version can be retrieved, disclose that the current reference is unavailable and follow any topic-specific fallback in the skill. Use bundled guidance only for stable constraints, and do not guess at changeable platform details.\n\nWhen a task requires multiple references, apply this workflow to each one and distinguish the documents you verified from those that remain unavailable.\n<!-- /shared:documentation-retrieval -->\n"
}