Platforms

Render

Run Rivet workers on Render.

Workers run in runner mode here: the service 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 Render account
A GitHub repository containing your app
A control plane, either Rivet Cloud or your own

Steps

Add the service

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

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

sync: false keeps both values out of the blueprint so you set them as secrets in the dashboard.

Set the endpoints

Set RIVET_ENDPOINT and RIVET_PUBLIC_ENDPOINT on the service in the Render dashboard. Both values are described in Workers.

Deploy

Push to the connected branch, or click Manual Deploy.

Verify

The service log should show the worker connecting. Open the dashboard and confirm it appears under Runners.

Runner-mode workers 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 appear under Runners. 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

Actors drain for up to 30 minutes, which is longer than Render waits between SIGTERM and SIGKILL. 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.