Update to Render

{
  "name": "render-networking",
  "description": "Connects Render services over the private network—internal DNS, service discovery, and cross-service communication. Use when the user needs to wire services together, resolve internal hostnames, troubleshoot connectivity between services, configure environment isolation, or understand which services can reach each other.",
  "included_files": [
    {
      "relative_path": "references/communication-patterns.md",
      "size_in_bytes": 3143
    },
    {
      "relative_path": "references/troubleshooting.md",
      "size_in_bytes": 3063
    }
  ],
  "skill_md_contents": "---\nname: render-networking\ndescription: >-\n  Connects Render services over the private network—internal DNS, service\n  discovery, and cross-service communication. Use when the user needs to wire\n  services together, resolve internal hostnames, troubleshoot connectivity\n  between services, configure environment isolation, or understand which\n  services can reach each other.\nlicense: MIT\ncompatibility: Render services in the same region and workspace\nmetadata:\n  author: Render\n  version: \"1.0.0\"\n  category: networking\n---\n\n# Render private networking\n\nRender’s **private network** lets services talk to each other without exposing traffic on the public internet. Use this skill when users need internal connectivity, discovery across scaled instances, or correct URL/port behavior for Blueprints and the Dashboard.\n\n## When to Use This Skill\n\n- Designing or debugging **service-to-service** traffic on Render\n- Questions about **internal hostnames**, **internal URLs**, or **Connect > Internal** in the Dashboard\n- **Service discovery** across multiple instances (custom load balancing, mesh-style setups)\n- **Port limits**, reserved ports, or **multi-port** web services (public vs private)\n- **Free-tier** web services and **who can send vs receive** private traffic\n- **Environment isolation** (Professional+) or **AWS PrivateLink** for private egress/ingress patterns\n\nFor step-by-step architecture examples and Blueprint patterns, see `references/communication-patterns.md`. For failure modes and fixes, see `references/troubleshooting.md`.\n\n## Private Network Basics\n\nPrivate connectivity is available only when **all** of the following hold:\n\n- Services are in the **same region**\n- Services are in the **same workspace**\n\nIf either differs, private DNS and internal routing will not connect those services.\n\n### Who can communicate\n\n| Resource | Private inbound | Private outbound | Internal hostname |\n|----------|-----------------|------------------|-------------------|\n| **Web Service** | Yes (paid tiers; see Free tier below) | Yes | Yes |\n| **Private Service** | Yes | Yes | Yes |\n| **Background Worker** | No | Yes | No |\n| **Cron Job** | No | Yes | No |\n| **Workflow Run** | No | Yes | No |\n| **Static Site** | — | — | **Not on private network** |\n| **Managed Postgres** | Via internal URL (from allowed clients) | N/A (datastore) | Via internal URL |\n| **Key Value** | Via internal URL (from allowed clients) | N/A (datastore) | Via internal URL |\n\n**Free-tier Web Services:** They may **send** private traffic to other services, but they **cannot receive** inbound private traffic. Plan upgrades or topology changes apply if a free web service must accept private connections.\n\nWorkers, crons, and workflow runs initiate outbound connections (e.g., to internal URLs or private service hostnames) but are **not** reachable by internal hostname for inbound calls.\n\n## Internal Addresses\n\n- Open the service in the Render Dashboard → **Connect** → **Internal** tab for the canonical internal hostname, URL, and connection details.\n- Clients often need an **explicit scheme** in code or config, e.g. `http://service-name:port` or `https://...` when TLS applies—do not assume a bare hostname alone is enough for every HTTP client.\n- **URL shape:** `http://[internal-hostname]:[port]/path` (adjust scheme/port per service).\n\n## Service Discovery\n\nFor services with **multiple instances**, Render exposes a **discovery DNS** name that resolves to **all instance IPs** for that service. The pattern is **`[hostname]-discovery`** (see Dashboard docs for the exact hostname shown for your service).\n\n- **`RENDER_DISCOVERY_SERVICE`** is set in environments where discovery applies; use it with the discovery hostname pattern for scripts and app code that need instance lists.\n- **Use case:** Custom load balancing, health aggregation, or any logic that must fan out or pick among instances explicitly instead of a single internal hostname.\n\nSee `references/communication-patterns.md` for discovery-oriented patterns.\n\n## Port Rules\n\n- **Maximum 75 open ports** per service.\n- **Reserved ports** (do not bind your app to these for normal use): **10000** (public HTTP proxy path), **18012**, **18013**, **19099**.\n- **Multi-port Web Services:** Only **one** port receives **public** HTTP traffic; that port must align with the **`PORT`** environment variable. **Additional** ports are for **private network** access only.\n\nWhen something fails to connect, verify the target is listening on the expected port and that the port is not reserved or blocked by misconfiguration.\n\n## Environment Isolation\n\nOn **Professional and higher** workspaces, you can configure **per-environment** rules so private traffic does **not** cross certain environment boundaries. If private calls work in one environment but not another, check workspace **environment isolation** settings before assuming DNS or app bugs.\n\n## AWS PrivateLink\n\n**Professional+** workspaces can use **AWS PrivateLink** to extend private connectivity to or from external AWS VPCs and approved endpoints. This is separate from default service-to-service private DNS; use it when the architecture requires **private** access to Render or from Render to specific AWS resources without the public internet.\n\n## Common Patterns\n\nShort summaries; full diagrams and Blueprint notes live in `references/communication-patterns.md`.\n\n1. **Web gateway + private backends** — Public Web Service terminates HTTP; internal calls use private hostnames and ports to Private Services or internal URLs.\n2. **Worker to database** — Background Worker (no internal hostname) connects **outbound** to Postgres or Key Value **internal URLs**.\n3. **Microservices** — Private Services (and eligible Web Services) call each other by **internal hostname:port** on the private network.\n\n## References\n\n| Document | Purpose |\n|----------|---------|\n| `references/communication-patterns.md` | Gateway, worker→DB, mesh, URL construction, Blueprint `fromService`, discovery load balancing, private health checks |\n| `references/troubleshooting.md` | DNS, ports, region/workspace, free tier, protocol, resolver, environment isolation |\n\n## Related Skills\n\n- **render-web-services** — Public web services, `PORT`, and HTTP behavior\n- **render-private-services** (planned) — Private Service–specific setup and scaling\n- **render-blueprints** — `render.yaml`, `fromService`, and multi-service wiring\n"
}