Render Web Services

Render Web Services

This 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.

When to Use

• Configuring or debugging port binding, PORT, or multi-port web services
• TLS/HTTPS expectations at the edge vs inside the container
• Health checks blocking or rolling back deploys
• Custom domains, DNS, and certificate provisioning
• Auto-deploy, CI-gated deploys, and PR preview generation
• Persistent disks and their impact on scaling and zero-downtime
• Deploy lifecycle: build, pre-deploy, swap, drain, rollback, shutdown delay

Deeper patterns live under references/ (health checks, domains, deploy phases).

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.
• 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.
• Reserved ports (do not bind your application to these for normal traffic): 18012, 18013, 19099.

Multi-port Web Services

• Only one port receives public HTTP traffic: the port aligned with PORT.
• Additional open ports are reachable on Render’s private network only (not from the public internet through the same public URL pattern).

TLS and HTTPS

• TLS terminates at Render’s edge. The edge speaks HTTPS to clients; your process typically receives plain HTTP on PORT.
• HTTPS redirect for clients is handled by the platform; users hitting HTTP are redirected appropriately at the edge.
• 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.

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.

Custom Domains

• Point DNS with a CNAME to [service-name].onrender.com (use your service’s hostname from the Dashboard).
• Render automatically provisions and renews TLS certificates for verified domains.
• Apex (root) domains need provider-specific CNAME-like or flattened records where plain CNAME at @ is unsupported.
• Wildcard domains (e.g. *.example.com) are supported when configured and verified.
• Multiple custom domains per service are supported; Blueprints can list them under the domains field.

See references/custom-domains.md for Dashboard steps, verification, and troubleshooting.

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)
• 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.

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.

Free Tier Notes

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

Related Skills

• render-deploy — Blueprints, first-time deploy, render.yaml structure
• 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)