How to deploy a static site on Render — from a site that did it

This site you are reading runs on Render's free static hosting, and so does its 500-page sibling. Everything below is first-hand, not documentation paraphrase.

The three decisions that matter

1. Build command vs publish directory. Render runs your build command, then serves whatever directory you name as the publish directory. Ours is npm run build publishing public/. The classic mistake is testing locally, deploying, and looking at a stale page — because the publish directory points at the source folder instead of the build output. Point it at generated output, always.

2. The build can fail and the site still serves. A static host serves the last good deploy. That is resilience, but it hides breakage: your build can be red for days while the site looks fine. Wire a status notification (Render's dashboard hooks or a simple build-badge check) — trust the build log, not the homepage.

3. Redirects live with the host. A _redirects file works on some hosts and is ignored on others; Render static sites use a redirects file format of their own (_redirects in the publish directory), and dashboard-level redirect rules shadow everything. When a path "mysteriously" serves the wrong page, check the dashboard rules first.

The free tier, honestly

Free static hosting on Render does not sleep — static sites are served from CDN edges, so there is no cold start (that applies to free web services, a different product). The real limits are build minutes and bandwidth. For a text-first site with system fonts and no framework, both are a rounding error: this deployment serves hundreds of thousands of internal links across ~500 pages on the free tier.

The checklist

• Build command tested locally, byte-identical output.
• Publish directory = generated output only.
• Custom redirects declared once, in the file the host actually reads.
• After the first deploy: curl every critical URL. Never sample — verify.