Update to Render

{
  "name": "render-docker",
  "description": "Builds and deploys Docker containers on Render—Dockerfiles, multi-stage builds, Blueprint Docker fields, private registries, layer caching, and platform constraints. Use when the user mentions Docker, Dockerfile, container images, multi-stage builds, container registry, GHCR, ECR, BuildKit, dockerContext, runtime docker or image, or optimizing Docker builds on Render.",
  "included_files": [
    {
      "relative_path": "references/dockerfile-patterns.md",
      "size_in_bytes": 5495
    },
    {
      "relative_path": "references/optimization-guide.md",
      "size_in_bytes": 3297
    },
    {
      "relative_path": "references/registry-setup.md",
      "size_in_bytes": 3118
    }
  ],
  "skill_md_contents": "---\nname: render-docker\ndescription: >-\n  Builds and deploys Docker containers on Render—Dockerfiles, multi-stage\n  builds, Blueprint Docker fields, private registries, layer caching, and\n  platform constraints. Use when the user mentions Docker,\n  Dockerfile, container images, multi-stage builds, container registry,\n  GHCR, ECR, BuildKit, dockerContext, runtime docker or image, or\n  optimizing Docker builds on Render.\nlicense: MIT\ncompatibility: >-\n  Any Render compute service (web, private, worker, cron) with runtime: docker\n  or runtime: image.\nmetadata:\n  author: Render\n  version: \"1.0.0\"\n  category: deployment\n---\n\n# Render Docker Deployments\n\nRender uses **BuildKit** for Docker builds. All compute service types that support custom runtimes can use **`runtime: docker`** (build from a Dockerfile in the repo) or **`runtime: image`** (pull a prebuilt image; no Dockerfile build on Render). Deeper patterns and copy-paste templates live under `references/`.\n\n## When to Use\n\n- Authoring or debugging a **Dockerfile** for a Render service\n- Choosing **`runtime: docker`** vs **`runtime: image`** in a Blueprint\n- Wiring **private base images** or **prebuilt images** with registry credentials\n- **Multi-stage builds**, **build args**, **secrets**, and **layer caching**\n- **Performance** and **security** hardening of container images on Render\n\nFor full Blueprint authoring, see **render-blueprints**. For end-to-end deploy flows, see **render-deploy**.\n\n## Render Docker Builds\n\n- **BuildKit** is used for Docker builds on Render.\n- **`runtime: docker`**: Render builds an image from your repo using `dockerfilePath`, `dockerContext`, and optional `dockerCommand` (overrides image `CMD`).\n- **`runtime: image`**: Render pulls **`image.url`**; no repo-based image build. Pair with **`registryCredential`** when the registry is private.\n\n## Blueprint Configuration\n\n| Field | Role |\n|-------|------|\n| `dockerfilePath` | Path to the Dockerfile (default `./Dockerfile`) |\n| `dockerContext` | Build context directory (what is sent to the daemon) |\n| `dockerCommand` | Overrides the container `CMD` after the image is built |\n| `image.url` | Image reference for `runtime: image` (registry/repo:tag or digest) |\n| `registryCredential` | Auth for private pulls; often `fromRegistryCreds` → Dashboard-stored credential |\n\nExample sketch (values illustrative):\n\n```yaml\nservices:\n  - type: web\n    name: api\n    runtime: docker\n    region: oregon\n    plan: starter\n    dockerfilePath: ./Dockerfile\n    dockerContext: .\n    dockerCommand: node server.js\n    envVars:\n      - key: PORT\n        value: 10000\n```\n\nFor `runtime: image`, set `image.url` and, if needed, `registryCredential` per **Registry Configuration** below.\n\n## Multi-Stage Builds\n\n**Recommended for production.** Use a **builder** stage for compilation and dependency installation, and a minimal **runner** stage that only copies artifacts and runtime files. Benefits:\n\n- Smaller images and faster pulls\n- Fewer tools and secrets in the final image (smaller attack surface)\n- Clear separation between build-time and run-time dependencies\n\nSee `references/dockerfile-patterns.md` for language-specific templates.\n\n## Build Args vs Secrets\n\n**Critical:** **Never pass secrets via `ARG`.** Build arguments are stored in image **layers** and can be recovered from the image history or intermediate layers.\n\n- Prefer **runtime environment variables** (Render **env vars** / secret files) for application secrets.\n- For **build-time** secrets (e.g. private package feeds), use **Docker BuildKit secret mounts** (`RUN --mount=type=secret,...`) rather than `ARG`.\n\nTreat anything sensitive as **runtime** or **BuildKit secret mount**, not as a build arg.\n\n## Registry Configuration\n\nPrivate **base images** (for `runtime: docker`) or **prebuilt images** (`runtime: image`) need authentication:\n\n- Store credentials in the Render Dashboard under **Registry Credentials**.\n- In Blueprint, reference them with **`registryCredential.fromRegistryCreds.name`** (match the Dashboard name).\n\nSupports common registries (Docker Hub, GHCR, ECR, Google Artifact Registry, and others). Step-by-step per provider: `references/registry-setup.md`.\n\n**Prebuilt image services** do **not** auto-deploy when the tag moves in the registry; trigger a **manual redeploy** or use a **deploy hook** when you publish a new image.\n\n## Layer Caching\n\n- Render **caches Docker layers** between builds; **order Dockerfile instructions** so that frequently unchanged layers stay early (see `references/optimization-guide.md`).\n- **Tags and caching:** mutable tags like **`latest`** can resolve to **stale cached** images. Prefer **immutable** references: **digest** (`repo/image@sha256:...`) or **version pins** (`v1.2.3`).\n\n## Platform Specifics\n\n- Render builds **linux/amd64**. Avoid assumptions about other architectures in production images.\n- **Port binding** matches native services: bind HTTP to **`0.0.0.0:$PORT`** (Render sets `PORT`).\n- **Health checks** behave like non-Docker web services (`healthCheckPath`, etc.).\n- **Secret files** from Render appear under **`/etc/secrets/`** — do not rely on repo-root secret paths inside the container unless you copy or mount them explicitly in the image.\n\n## `.dockerignore` and Start Commands\n\n- Always maintain a **`.dockerignore`** that excludes **`node_modules`**, **`.git`**, **`.env`**, build artifacts, logs, and OS junk. This shrinks context upload time and avoids leaking local files into layers. Lists and rationale: `references/optimization-guide.md`.\n- **Custom start command:** if you need multiple shell steps, use a single shell form, e.g. **`/bin/sh -c 'set -e; ./migrate && exec node server.js'`** (prefer **`exec`** so your app receives signals for graceful shutdown).\n\n## References\n\n| Document | Contents |\n|----------|----------|\n| `references/dockerfile-patterns.md` | Multi-stage templates (Node, Python, Go, Ruby, Rust, static sites) |\n| `references/registry-setup.md` | Docker Hub, GHCR, ECR, Artifact Registry + Blueprint wiring |\n| `references/optimization-guide.md` | Layer order, `.dockerignore`, BuildKit cache mounts, debugging |\n\n## Related Skills\n\n- **render-deploy** — Deploy flows, Blueprint vs Dashboard, operational steps\n- **render-blueprints** — Full `render.yaml` schema, wiring, and validation\n- **render-web-services** — Web service behavior, health checks, and HTTP edge cases\n"
}