fix(deploy): make the Render blueprint deployable (verified against the image)

[adamXbot]

Summary

Pre-deploy verification of deploy/render.yaml.example for a both-in-Render (web service + Postgres) deployment. The blueprint could not have provisioned as written, and had two silent defects that matter specifically for a tripwire service. Every fix is verified against the production Docker image, not just the docs.

Blocking defects (blueprint would not provision)

• plan: starter on the database — Render now classes starter/standard/pro as legacy Postgres instance types that cannot be used for new databases. → basic-256mb (current flexible type, ~$6/mo).
• No database region — the DB region defaulted independently of the web service's oregon. Private-network connection strings only resolve within the same region, and since ipAllowList: [] disables public ingress, a region mismatch leaves the app with no route to Postgres at all. Both are now pinned together with a comment saying they must move as a pair.

Silent defects

• Null client IPs — same bug as fixed for Fly in feat(deploy): one-command Fly.io launch + fix null client IPs on Fly #58: the image sets NODE_ENV=production, where mantis distrusts forwarding headers unless TRUST_PROXY_HEADERS=1. Without it every hit records ip = null. Also pins TRUSTED_IP_HEADER=x-forwarded-for since Render does not strip an inbound CF-Connecting-IP (forgeable with one request header otherwise). Comment covers the cf-connecting-ip switch if fronted by Cloudflare later.
• PUBLIC_BASE_URL vs the global onrender.com namespace — <name>.onrender.com is shared by all Render customers; plain mantis is taken, and when a name is taken Render silently serves at <name>-<suffix>.onrender.com. The hardcoded base URL would then mint canary URLs pointing at another customer's app — handed-out canaries would trigger someone else's server. Usage now: pick a unique name, verify the served URL after first deploy, fix it in this file (the blueprint is the source of truth; dashboard edits to synced vars are overwritten on sync).
• 15 GB default disk — Basic-tier databases get 15 GB when diskSizeGB is omitted, ~3× the storage cost for nothing. Pinned to 5 GB (disks grow but never shrink).

Improvements

• MANTIS_API_KEY_PEPPER uses generateValue: true — generated once at create, never rotated on later deploys, which is exactly the write-once property the pepper needs; the operator never handles the value. (Recreating the service from scratch requires copying it across first — documented.)
• postgresMajorVersion: "18" — parity with docker-compose, CI, and the tier-2 suite, all on postgres:18.
• Documented the first-boot admin-key flow, including the trap that a bare grep for mantis_live_ returns an 18-char prefix from a structured log line that 401s — take the key from the banner.
• Optional blocks for BOOTSTRAP_API_KEY, retention (MANTIS_*_RETENTION_DAYS), and SMTP; sharper free-tier warning (a tripwire is idle by definition, so spin-down means nearly every real hit pays the cold start).

Verification

Booted the production image with exactly the blueprint's env against Postgres 18.4 (and previously 17.10):

• migrations applied automatically; /api/health → {"status":"ok","db":"ok"}
• first-boot banner key authenticates: 200 with it, 401 without
• trigger with X-Forwarded-For: 198.51.100.42 + forged CF-Connecting-IP: 6.6.6.6 records 198.51.100.42
• YAML parses; regions match; fromDatabase reference resolves; diskSizeGB satisfies the 1-or-multiple-of-5 rule; version is a quoted string
• 217/217 unit tests pass on the branch

Not verifiable without a Render account: live blueprint parsing on Render's side. Everything checkable locally has been checked.

🤖 Generated with Claude Code