Render: Env Vars, Networking & Scaling

Environment Variables & Groups

• Env vars are configured per service (dashboard or render.yaml envVars) and injected at runtime -- the standard 12-factor-app pattern.

• Sensitive values can be marked as secrets so they're hidden in the dashboard UI.

• An Environment Group centralizes a shared set of variables across multiple services -- update the group once instead of duplicating a value (like a shared API key) across each service's individual config.

• Disks attach persistent storage at a specified path -- necessary because a service's regular filesystem is ephemeral and resets on each deploy.

Health Checks & Scaling

// Express example -- a health check endpoint the platform pings
// repeatedly to know when an instance is actually ready for traffic
app.get('/healthz', (req, res) => {
  // check DB connectivity, etc. before reporting healthy
  res.status(200).send('ok');
});

// An instance failing its health check isn't routed traffic yet
// (or may be restarted if it was previously healthy and stopped
// responding) -- avoids sending real requests to a not-yet-ready
// or unhealthy instance.

// Horizontal scaling: configure multiple instances of the same
// service -- Render load-balances traffic across them automatically.
// Autoscaling (paid plans) adds/removes instances based on CPU/memory
// thresholds, no manual reverse-proxy configuration needed.

Private Networking

# A service without a public port -- reachable only by other services
# in the same Render account/project via an internal address, not the
# public internet. Appropriate for an internal API only your own
# frontend/worker calls.
services:
  - type: pserv   # private service
    name: internal-api
    runtime: node
    startCommand: node server.js
    # Other services reference it internally, e.g.
    # http://internal-api:10000

Free Tier Gotchas

• Free Web Services spin down after ~15 minutes without traffic -- the next request triggers a cold start with noticeable added latency.

• A webhook receiver on the free tier can miss deliveries if the sender's timeout is shorter than the cold-start time -- production integrations typically need an always-on paid plan.

• Free tier is fine for demos/side projects; anything depending on consistent low-latency response should budget for a paid instance.