Platforms

Render

Run Rivet nodes on Render.

Your service runs as a node: it opens a connection out to the control plane on startup. It needs no public URL, so a Render Background Worker suits it as well as a Web Service.

Requirements

A namespace and a node pool created with PUT /pools/{pool} (see Nodes & Node Pools). In local development, RivetKit creates the default pool for you.

A Render account
A GitHub repository containing your app
A running control plane

Steps

Add the service

services:
  - type: worker
    name: rivet-node
    runtime: docker
    dockerfilePath: ./Dockerfile
    plan: starter
    envVars:
      - key: RIVET_ENDPOINT
        sync: false

type: worker is a Background Worker: no public URL and no HTTP port, which is exactly what a node needs. Use type: web instead only if the same service also serves your application traffic.

sync: false keeps the value out of the blueprint so you set it as a secret in the dashboard.

Set the endpoint

Set RIVET_ENDPOINT on the service in the Render dashboard. The value is described in Deploy Nodes.

Deploy

Push to the connected branch, or click Manual Deploy.

Verify

The service log should show the node connecting. Call one of your Rivet Actors to confirm it responds.

Nodes are interchangeable, so instance count can be raised, or driven by Render’s autoscaling on a CPU target. Target 60% CPU, matching the rest of the guides. Nothing needs re-registering; new instances dial out and start serving Rivet Actors. See Render’s scaling docs.

Scaling in is bounded by the drain below, so an instance being removed keeps serving its actors well past the point Render stops routing to it.

Graceful shutdown

Each Rivet Actor gets up to 15 seconds to save its state when the process stops. Set Render’s shutdown delay to 60 seconds, plan deploys so a new instance is up before the old one goes away, and keep the process itself signal-aware: a wrapper such as npm start becomes PID 1 and swallows SIGTERM. Invoke the binary directly, or use dumb-init or tini.