Update to Render

{
  "name": "render-web-services",
  "description": "Configures Render web services—port binding, TLS, health checks, custom domains, auto-deploy, PR previews, persistent disks, and deploy lifecycle. Use when the user needs to set up a web service, fix health check failures, add a custom domain, configure zero-downtime deploys, or troubleshoot port binding issues.",
  "included_files": [
    {
      "relative_path": "references/custom-domains.md",
      "size_in_bytes": 2716
    },
    {
      "relative_path": "references/deploy-lifecycle.md",
      "size_in_bytes": 3814
    },
    {
      "relative_path": "references/health-check-patterns.md",
      "size_in_bytes": 3088
    }
  ],
  "skill_md_contents": "---\nname: render-web-services\ndescription: >-\n  Configures Render web services—port binding, TLS, health checks, custom\n  domains, auto-deploy, PR previews, persistent disks, and deploy lifecycle.\n  Use when the user needs to set up a web service, fix health check failures,\n  add a custom domain, configure zero-downtime deploys, or troubleshoot port\n  binding issues.\nlicense: MIT\ncompatibility: Render web services (native runtimes or Docker)\nmetadata:\n  author: Render\n  version: \"1.0.0\"\n  category: compute\n---\n\n# Render Web Services\n\nThis skill covers **Web Service** behavior on Render: how traffic reaches your process, how deploys go live, and how optional features (domains, disks, auto-deploy) interact. Use it alongside Blueprint and networking skills when wiring `render.yaml` or Dashboard settings.\n\n## When to Use\n\n- Configuring or debugging **port binding**, **PORT**, or **multi-port** web services\n- **TLS/HTTPS** expectations at the edge vs inside the container\n- **Health checks** blocking or rolling back deploys\n- **Custom domains**, DNS, and certificate provisioning\n- **Auto-deploy**, **CI-gated deploys**, and **PR preview** generation\n- **Persistent disks** and their impact on scaling and zero-downtime\n- **Deploy lifecycle**: build, pre-deploy, swap, drain, **rollback**, shutdown delay\n\nDeeper patterns live under `references/` (health checks, domains, deploy phases).\n\n## Port Binding\n\n- Listen on **`0.0.0.0`** (all interfaces). Binding only to **`localhost`** or **`127.0.0.1`** prevents Render’s proxy from reaching your app.\n- Use the **`PORT`** environment variable for the HTTP listen port. Render sets it for you; the **default is often `10000`** and you can change the configured value in the service **Settings** in the Dashboard.\n- **Reserved ports** (do **not** bind your application to these for normal traffic): **`18012`**, **`18013`**, **`19099`**.\n\n### Multi-port Web Services\n\n- Only **one** port receives **public** HTTP traffic: the port aligned with **`PORT`**.\n- **Additional** open ports are reachable on Render’s **private network** only (not from the public internet through the same public URL pattern).\n\n## TLS and HTTPS\n\n- **TLS terminates at Render’s edge.** The edge speaks HTTPS to clients; your process typically receives **plain HTTP** on `PORT`.\n- **HTTPS redirect** for clients is handled by the platform; users hitting HTTP are redirected appropriately at the edge.\n- **Do not terminate TLS inside the app** for the primary public listener unless you have a rare, explicit need—standard Web Services assume HTTP behind the proxy.\n\n## Health Checks\n\n- Configure a path via **`healthCheckPath`** in a Blueprint or the **Health Check Path** field in the Dashboard.\n- Render issues **HTTP GET** requests to that path. Responses must be **`2xx` or `3xx`** for success.\n- **Failed health checks** prevent a new deploy from **going live** (the deploy does not succeed in taking production traffic as expected).\n- Render probes on a **repeat interval** with a per-request **timeout**; both are **configurable** in service settings (see Dashboard). Failed checks during rollout prevent the new revision from receiving traffic.\n- Check frequency, timeouts, and tuning guidance in `references/health-check-patterns.md`.\n\n## Custom Domains\n\n- Point DNS with a **CNAME** to **`[service-name].onrender.com`** (use your service’s hostname from the Dashboard).\n- Render **automatically provisions and renews** TLS certificates for verified domains.\n- **Apex** (root) domains need provider-specific **CNAME-like** or flattened records where plain CNAME at `@` is unsupported.\n- **Wildcard** domains (e.g. `*.example.com`) are supported when configured and verified.\n- Multiple custom domains per service are supported; Blueprints can list them under the **`domains`** field.\n\nSee `references/custom-domains.md` for Dashboard steps, verification, and troubleshooting.\n\n## Auto-Deploy and PR Previews\n\n- **`autoDeployTrigger`** (Blueprint) / auto-deploy settings control when production deploys run:\n  - **`commit`** — deploy on every push to the tracked branch\n  - **`checksPass`** — deploy only when required **Git checks** pass\n  - **`off`** — **manual** deploys only (Dashboard, CLI, hooks)\n- **PR previews** are configured under Blueprint **`previews.generation`** (and related preview settings); generation behavior depends on repo integration and plan.\n\n## Persistent Disks\n\n- Attach disks via the **`disk`** field in a Blueprint (or equivalent Dashboard storage settings).\n- A service with an attached persistent disk is **single-instance** only: **horizontal scaling** is not available in that configuration.\n- **Zero-downtime deploys are disabled** when a persistent disk is attached—deploys follow a different rollout pattern.\n- **Disk size increases** are allowed; **decreases** are not.\n- The disk is **not mounted during the build phase**—only at **runtime** in the running service.\n\n## Deploy Lifecycle\n\nTypical flow:\n\n1. **Build** — clone repo, run **`buildCommand`**, produce the runnable artifact/image.\n2. **Pre-deploy command** (optional) — runs in the **new** image **before** traffic switches; use for **migrations**. If it **fails**, the deploy is **canceled**.\n3. **Deploy** — new instances start; health checks must pass before traffic moves.\n4. **Zero-downtime swap** (when applicable) — traffic shifts to new instances; **old instances drain** in-flight work.\n\n- **`maxShutdownDelaySeconds`** (range **1–300**, **default 30**) bounds how long old instances may continue handling requests during drain before shutdown.\n- **Rollbacks** — revert to a **previous successful deploy** from the Dashboard.\n\nFull sequence, hooks, filters, and CLI notes: `references/deploy-lifecycle.md`.\n\n## Free Tier Notes\n\nFree Web Services have **separate limits**: e.g. **no custom domains** on the free instance type, and services **spin down after inactivity** (cold starts on next request). Treat free-tier behavior as distinct from paid Web Service defaults when advising on domains, uptime, and scaling.\n\n## References\n\n| Topic | File |\n|--------|------|\n| Health check design, timeouts, pitfalls | `references/health-check-patterns.md` |\n| Domains, DNS, TLS verification | `references/custom-domains.md` |\n| Build, pre-deploy, drain, rollbacks, triggers | `references/deploy-lifecycle.md` |\n\n## Related Skills\n\n- **render-deploy** — Blueprints, first-time deploy, `render.yaml` structure\n- **render-docker** — Docker-based Web Services and image/runtime details\n- **render-networking** — Private network, internal URLs, multi-port private listeners\n- **render-scaling** — Instance counts, plans, and scaling constraints (including disk interactions)\n"
}