Render Deployment

The Hono API (apps/api) deploys to Render as a Node.js web service. The project includes a render.yaml blueprint that defines the service configuration.

Prerequisites

A Render account
The folksbase repository connected to Render
All external services configured (Neon, Upstash, Supabase, etc.)

Using the Blueprint (`render.yaml`)

The easiest way to deploy is using Render’s blueprint feature. The render.yaml at the repository root defines everything Render needs:

services:
  - type: web
    name: folksbase-api
    runtime: node
    region: oregon
    plan: starter
    buildCommand: pnpm install && pnpm --filter @folksbase/api build
    startCommand: node apps/api/dist/index.js
    healthCheckPath: /health

1. Connect the Repository

Go to dashboard.render.com
Click New → Blueprint
Connect your GitHub repository
Render will detect render.yaml and create the service

2. Set Environment Variables

The blueprint declares all required env vars with sync: false, meaning you need to set their values manually in the Render dashboard. Go to your service’s Environment tab and add:

Variable	Description
`DATABASE_URL`	Neon Postgres connection string
`REDIS_URL`	Upstash Redis REST URL
`REDIS_REST_TOKEN`	Upstash Redis token
`SUPABASE_URL`	Supabase project URL
`SUPABASE_PUBLISHABLE_KEY`	Supabase anon key
`SUPABASE_SECRET_KEY`	Supabase service role key
`SUPABASE_WEBHOOK_SECRET`	Supabase webhook secret
`BLOB_READ_WRITE_TOKEN`	Vercel Blob token
`INNGEST_EVENT_KEY`	Inngest event key
`INNGEST_SIGNING_KEY`	Inngest signing key
`ANTHROPIC_API_KEY`	Anthropic API key
`RESEND_API_KEY`	Resend API key
`ENCRYPTION_KEY`	64-char hex string for AES-256-GCM
`APP_URL`	The Render service URL
`FRONTEND_URL`	The Vercel frontend URL(s) for CORS

The blueprint pre-sets these with fixed values:

NODE_VERSION=24
PNPM_VERSION=10.32.1
RESEND_FROM_EMAIL=noreply@folksbase.dev
PORT=3001

3. Deploy

Push to main or trigger a manual deploy from the Render dashboard. The build command installs dependencies and compiles the API with tsup.

Health Check

The API exposes a /health endpoint that Render uses to verify the service is running. It checks both the database (Neon) and cache (Redis) connections:

// Healthy
{ "status": "ok", "checks": { "db": "ok", "redis": "ok" } }

// Degraded (503)
{ "status": "degraded", "checks": { "db": "ok", "redis": "error" } }

If the health check fails, Render will restart the service automatically.

Build Process

The build command runs two steps:

pnpm install — installs all monorepo dependencies
pnpm --filter @folksbase/api build — compiles the API using tsup

The start command runs the compiled output directly: node apps/api/dist/index.js.

Why the HTTP Driver?

The database package uses Neon’s HTTP driver (drizzle-orm/neon-http) instead of the WebSocket driver. This is intentional — Render’s infrastructure makes persistent WebSocket connections to Neon unreliable. The HTTP driver works over standard HTTPS requests, which is simpler and more compatible. Do not switch to the WebSocket driver without testing on Render first.

Rollback

Go to your service’s Events tab in the Render dashboard
Find the last successful deploy
Click Rollback to redeploy that version

Getting Started

Features

Architecture

Background Jobs

API

Deployment

Contributing

Prerequisites

Using the Blueprint (`render.yaml`)

1. Connect the Repository

2. Set Environment Variables

3. Deploy

Health Check

Build Process

Why the HTTP Driver?

Rollback

​Prerequisites

​Using the Blueprint (render.yaml)

​1. Connect the Repository

​2. Set Environment Variables

​3. Deploy

​Health Check

​Build Process

​Why the HTTP Driver?

​Rollback

Prerequisites

Using the Blueprint (`render.yaml`)

1. Connect the Repository

2. Set Environment Variables

3. Deploy

Health Check

Build Process

Why the HTTP Driver?

Rollback