render-cd-proxy

Parametric Render-side reverse-proxy for the Render → Cherry Deploy cutover.

When a service's provider-facing URL is a raw *.onrender.com (which can't be DNS-forwarded to Cherry Deploy without touching Render — onrender.com is Render's domain), the cutover swaps the Render service's code to this proxy. It then transparently forwards every path + query to the Cherry Deploy app: the onrender URL keeps working, content comes from CD, the visible URL is unchanged.

Transparent proxy (NOT a 301 redirect) so POST / API callers (Vapi tools, booking endpoints) keep working — method, body and headers are forwarded as-is.

Config

• TARGET (required) — the Cherry Deploy URL to forward to, e.g. https://revee-aesthetics-booking.withcherry.com.

Cutover (per Render service, at the owner's go — NOT during parallel run)

1. Point the Render service's repo at this one and set TARGET:

   PATCH /v1/services/<srv-id>            {"repo":"https://github.com/joinmason/render-cd-proxy","branch":"main"}
   PUT   /v1/services/<srv-id>/env-vars   [{"key":"TARGET","value":"https://<slug>.withcherry.com"}]
   POST  /v1/services/<srv-id>/deploys
   

2. The Cherry Deploy target MUST be machine_callable: true — otherwise Cloudflare's WAF returns a 403 "Cherry Blocked Page" to this server-to-server proxy. Create/recreate the CD app with machine_callable: true first.
3. Verify the onrender URL now serves CD (path + query preserved); test a POST path (booking / admin) too, not just GET /.
4. Rollback: PATCH the Render service's repo back to the original app.

One proxy repo serves all tenants — only TARGET differs per Render service.