Update to Render

{
  "name": "render-blueprints",
  "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/common-mistakes.md",
      "size_in_bytes": 4396
    },
    {
      "relative_path": "references/field-reference.md",
      "size_in_bytes": 8470
    },
    {
      "relative_path": "references/preview-environments.md",
      "size_in_bytes": 3837
    },
    {
      "relative_path": "references/wiring-patterns.md",
      "size_in_bytes": 4436
    }
  ],
  "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\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. Avoid duplicating the same logical resource in multiple places (see `references/common-mistakes.md`).\n\n### Schema and IDE validation\n\n- **JSON Schema URL:** `https://render.com/schema/render.yaml.json`\n- Configure your editor to associate `render.yaml` with that schema for completions and diagnostics.\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 (registry + optional `registryCredential`).\n- **`static`**: Static site; requires `staticPublishPath` and build output paths (see references).\n\n## Cross-Service Wiring\n\nEnv vars under `envVars` (and analogous patterns in groups) can pull values from other resources instead of hardcoding secrets.\n\n### `fromDatabase`\n\nReference a database in `databases:` by `name`. Properties include:\n\n- `connectionString`, `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\n### Other env var keys\n\n- **`value`**: Literal string.\n- **`generateValue`**: Let Render generate a random secret (password/API key).\n- **`sync`**: Set `sync: false` for secrets that should not sync from repo on every update (see edge cases in wiring reference).\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:\n              - source: 0.0.0.0/0\n                description: everywhere\n\n        databases:\n          - name: db\n            plan: starter\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- Environment isolation (Professional+) 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\nTop-level `previews` controls PR previews:\n\n- **`previews.generation`**: `off` (default), `manual`, or `automatic`\n- **`previews.expireAfterDays`**: Auto-delete preview stacks after N days\n\nServices can override preview behavior (e.g. service-level `previews.generation`). Limitations: autoscaling behavior, `sync: false` vars, `previewPlan` / flexible instance constraints—see `references/preview-environments.md`.\n\n## Validation\n\n```bash\nrender blueprints validate\n```\n\nRequires **Render CLI v2.7.0+**. Run from the repo root (or pass the appropriate path options your CLI version supports). Fix schema and semantic errors before merging Blueprint changes.\n\nOfficial schema: `https://render.com/schema/render.yaml.json`\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`, `previewPlan` (previews), database `plan` |\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` |\n\nDeprecated names to avoid: `env` (use `runtime`), `redis` (use `keyvalue`), `autoDeploy` (use `autoDeployTrigger`), `pullRequestPreviewsEnabled` (use `previews.generation`). Details: `references/common-mistakes.md`.\n\n## References\n\n| Document | Contents |\n|----------|----------|\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, `sync: false`, `generateValue`, combinations |\n| `references/common-mistakes.md` | Branch + previews, `buildFilter`, replicas, duplicates, preview plans, wiring mistakes |\n| `references/preview-environments.md` | `previews.generation`, expiry, overrides, `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"
}