← RenderCONTENT HISTORY

Update to Render

Snapshot Oct 24, 2026 · 12:46 UTC · version 1.0.2

Collection source: downloaded plugin package. These snapshots do not have a confirmed matching collection source. Differences in file lists alone do not establish changes to the package.

WHAT CHANGED

Instructions updated for render-web-services

Skill instructions — Now says: Before configuring or troubleshooting deploys and health checks, read `references/deployments.md`. Before attaching or changing a persistent disk, read...

Observed in instructions or declared skills. Runtime behavior has not been tested.

Save Render and check future changes in Following.

Up to 10 plugins free · no card required.

All fields and original values.

Skill instructions

Before

Sep 30, 2026 · 22:43 UTC

- Configure a path via **`healthCheckPath`** in a Blueprint or the **Health Check Path** field in the Dashboard. - Render issues **HTTP GET** requests to that path. Responses must be **`2xx` or `3xx`** for success. - **Failed health chec...

After

Oct 24, 2026 · 12:46 UTC

Before configuring or troubleshooting deploys and health checks, read `references/deployments.md`. Before attaching or changing a persistent disk, read `references/persistent-disks.md`. Before configuring or troubleshooting private conne...

Supporting files

Before

Sep 30, 2026 · 22:43 UTC

[{"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}]

After

Oct 24, 2026 · 12:46 UTC

[{"relative_path":"references/custom-domains.md","size_in_bytes":2579},{"relative_path":"references/deployments.md","size_in_bytes":9016},{"relative_path":"references/health-check-patterns.md","size_in_bytes":2311},{"relative_path":"refe...

Compare saved observations

Download comparison JSON

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -30,6 +30,10 @@
 
 Deeper patterns live under `references/` (health checks, domains, deploy phases).
 
+Before configuring or troubleshooting deploys and health checks, read `references/deployments.md`.
+Before attaching or changing a persistent disk, read `references/persistent-disks.md`.
+Before configuring or troubleshooting private connectivity or additional ports, read `references/private-networking.md`.
+
 ## Port Binding
 
 - 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.
@@ -49,11 +53,7 @@
 
 ## Health Checks
 
-- Configure a path via **`healthCheckPath`** in a Blueprint or the **Health Check Path** field in the Dashboard.
-- Render issues **HTTP GET** requests to that path. Responses must be **`2xx` or `3xx`** for success.
-- **Failed health checks** prevent a new deploy from **going live** (the deploy does not succeed in taking production traffic as expected).
-- 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.
-- Check frequency, timeouts, and tuning guidance in `references/health-check-patterns.md`.
+Follow `references/deployments.md` for current platform behavior. For endpoint implementations and common failure patterns, see `references/health-check-patterns.md`.
 
 ## Custom Domains
 
@@ -67,37 +67,24 @@
 
 ## Auto-Deploy and PR Previews
 
-- **`autoDeployTrigger`** (Blueprint) / auto-deploy settings control when production deploys run:
-  - **`commit`** — deploy on every push to the tracked branch
-  - **`checksPass`** — deploy only when required **Git checks** pass
-  - **`off`** — **manual** deploys only (Dashboard, CLI, hooks)
+- Follow `references/deployments.md` for auto-deploy behavior and manual triggers.
 - **PR previews** are configured under Blueprint **`previews.generation`** (and related preview settings); generation behavior depends on repo integration and plan.
 
 ## Persistent Disks
 
-- Attach disks via the **`disk`** field in a Blueprint (or equivalent Dashboard storage settings).
-- A service with an attached persistent disk is **single-instance** only: **horizontal scaling** is not available in that configuration.
-- **Zero-downtime deploys are disabled** when a persistent disk is attached—deploys follow a different rollout pattern.
-- **Disk size increases** are allowed; **decreases** are not.
-- The disk is **not mounted during the build phase**—only at **runtime** in the running service.
+- A disk-backed web service stays **single-instance** and cannot scale horizontally.
+- Attaching a disk disables **zero-downtime deploys**.
+- The disk is available only to the running service, not during builds or pre-deploy commands.
+- If the workload needs horizontal scaling or uninterrupted deploys, use shared external storage instead of a service-attached disk.
+- Follow `references/persistent-disks.md` for current support, configuration, mount-path, runtime-access, sizing, and snapshot behavior.
 
 ## Deploy Lifecycle
 
-Typical flow:
-
-1. **Build** — clone repo, run **`buildCommand`**, produce the runnable artifact/image.
-2. **Pre-deploy command** (optional) — runs in the **new** image **before** traffic switches; use for **migrations**. If it **fails**, the deploy is **canceled**.
-3. **Deploy** — new instances start; health checks must pass before traffic moves.
-4. **Zero-downtime swap** (when applicable) — traffic shifts to new instances; **old instances drain** in-flight work.
-
-- **`maxShutdownDelaySeconds`** (range **1–300**, **default 30**) bounds how long old instances may continue handling requests during drain before shutdown.
-- **Rollbacks** — revert to a **previous successful deploy** from the Dashboard.
-
-Full sequence, hooks, filters, and CLI notes: `references/deploy-lifecycle.md`.
+For paid web services, use `preDeployCommand` for database migrations and other release tasks that must succeed before the new version receives traffic. It runs after the build on separate compute; if it fails, the deploy is canceled and the previous live version continues serving. Follow `references/deployments.md` for the full build, readiness, traffic-switching, draining, rollback, restart, and deploy-hook behavior.
 
 ## Free Tier Notes
 
-Free 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.
+Free Web Services have **separate limits**: services **spin down after inactivity** (cold starts on the next request), and they do not support scaling beyond a single instance or persistent disks. Treat free-tier behavior as distinct from paid Web Service defaults when advising on uptime and scaling.
 
 ## References
 
@@ -105,7 +92,9 @@
 |--------|------|
 | Health check design, timeouts, pitfalls | `references/health-check-patterns.md` |
 | Domains, DNS, TLS verification | `references/custom-domains.md` |
-| Build, pre-deploy, drain, rollbacks, triggers | `references/deploy-lifecycle.md` |
+| Deploy lifecycle, health checks, rollback, triggers | `references/deployments.md` |
+| Persistent disk constraints and configuration | `references/persistent-disks.md` |
+| Private-network addressing, ports, discovery, and troubleshooting | `references/private-networking.md` |
 
 ## Related Skills
 
@@ -113,3 +102,16 @@
 - **render-docker** — Docker-based Web Services and image/runtime details
 - **render-networking** — Private network, internal URLs, multi-port private listeners
 - **render-scaling** — Instance counts, plans, and scaling constraints (including disk interactions)
+
+<!-- shared:documentation-retrieval -->
+## Current documentation retrieval
+
+Whenever this skill directs you to consult current Render documentation:
+
+1. 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.
+2. Confirm that retrieval succeeded and returned the expected document, then read its contents. Saving a file or printing its path is not sufficient.
+3. If the request fails or your tool cannot read the Markdown response, open and read the linked HTML version instead.
+4. 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.
+
+When a task requires multiple references, apply this workflow to each one and distinguish the documents you verified from those that remain unavailable.
+<!-- /shared:documentation-retrieval -->
Full technical diff · 2 changed fields

changed /included_files

BEFORE
[
  {
    "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
  }
]
AFTER
[
  {
    "relative_path": "references/custom-domains.md",
    "size_in_bytes": 2579
  },
  {
    "relative_path": "references/deployments.md",
    "size_in_bytes": 9016
  },
  {
    "relative_path": "references/health-check-patterns.md",
    "size_in_bytes": 2311
  },
  {
    "relative_path": "references/persistent-disks.md",
    "size_in_bytes": 3821
  },
  {
    "relative_path": "references/private-networking.md",
    "size_in_bytes": 4390
  }
]

changed /skill_md_contents

BEFORE
"---\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"
AFTER
"---\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\nBefore configuring or troubleshooting deploys and health checks, read `references/deployments.md`.\nBefore attaching or changing a persistent disk, read `references/persistent-disks.md`.\nBefore configuring or troubleshooting private connectivity or additional ports, read `references/private-networking.md`.\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\nFollow `references/deployments.md` for current platform behavior. For endpoint implementations and common failure patterns, see `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- Follow `references/deployments.md` for auto-deploy behavior and manual triggers.\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- A disk-backed web service stays **single-instance** and cannot scale horizontally.\n- Attaching a disk disables **zero-downtime deploys**.\n- The disk is available only to the running service, not during builds or pre-deploy commands.\n- If the workload needs horizontal scaling or uninterrupted deploys, use shared external storage instead of a service-attached disk.\n- Follow `references/persistent-disks.md` for current support, configuration, mount-path, runtime-access, sizing, and snapshot behavior.\n\n## Deploy Lifecycle\n\nFor paid web services, use `preDeployCommand` for database migrations and other release tasks that must succeed before the new version receives traffic. It runs after the build on separate compute; if it fails, the deploy is canceled and the previous live version continues serving. Follow `references/deployments.md` for the full build, readiness, traffic-switching, draining, rollback, restart, and deploy-hook behavior.\n\n## Free Tier Notes\n\nFree Web Services have **separate limits**: services **spin down after inactivity** (cold starts on the next request), and they do not support scaling beyond a single instance or persistent disks. Treat free-tier behavior as distinct from paid Web Service defaults when advising on 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| Deploy lifecycle, health checks, rollback, triggers | `references/deployments.md` |\n| Persistent disk constraints and configuration | `references/persistent-disks.md` |\n| Private-network addressing, ports, discovery, and troubleshooting | `references/private-networking.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\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"
Full snapshot data
{
  "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": 2579
    },
    {
      "relative_path": "references/deployments.md",
      "size_in_bytes": 9016
    },
    {
      "relative_path": "references/health-check-patterns.md",
      "size_in_bytes": 2311
    },
    {
      "relative_path": "references/persistent-disks.md",
      "size_in_bytes": 3821
    },
    {
      "relative_path": "references/private-networking.md",
      "size_in_bytes": 4390
    }
  ],
  "name": "render-web-services",
  "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\nBefore configuring or troubleshooting deploys and health checks, read `references/deployments.md`.\nBefore attaching or changing a persistent disk, read `references/persistent-disks.md`.\nBefore configuring or troubleshooting private connectivity or additional ports, read `references/private-networking.md`.\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\nFollow `references/deployments.md` for current platform behavior. For endpoint implementations and common failure patterns, see `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- Follow `references/deployments.md` for auto-deploy behavior and manual triggers.\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- A disk-backed web service stays **single-instance** and cannot scale horizontally.\n- Attaching a disk disables **zero-downtime deploys**.\n- The disk is available only to the running service, not during builds or pre-deploy commands.\n- If the workload needs horizontal scaling or uninterrupted deploys, use shared external storage instead of a service-attached disk.\n- Follow `references/persistent-disks.md` for current support, configuration, mount-path, runtime-access, sizing, and snapshot behavior.\n\n## Deploy Lifecycle\n\nFor paid web services, use `preDeployCommand` for database migrations and other release tasks that must succeed before the new version receives traffic. It runs after the build on separate compute; if it fails, the deploy is canceled and the previous live version continues serving. Follow `references/deployments.md` for the full build, readiness, traffic-switching, draining, rollback, restart, and deploy-hook behavior.\n\n## Free Tier Notes\n\nFree Web Services have **separate limits**: services **spin down after inactivity** (cold starts on the next request), and they do not support scaling beyond a single instance or persistent disks. Treat free-tier behavior as distinct from paid Web Service defaults when advising on 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| Deploy lifecycle, health checks, rollback, triggers | `references/deployments.md` |\n| Persistent disk constraints and configuration | `references/persistent-disks.md` |\n| Private-network addressing, ports, discovery, and troubleshooting | `references/private-networking.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\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"
}

SHA-256 of public snapshot: feec14d1549a6622b1959543e746340c475e5ae4985b8895240f2e6c8c20d379