Adding a custom domain now:
- creates a Cloudflare Custom Hostname (SSL for SaaS) automatically,
returning the ownership + SSL validation TXT records to show the
restaurant owner alongside the CNAME instruction
- adds the domain to the Coolify app's fqdn and triggers a restart
(Coolify only regenerates Traefik labels on deploy, not on a bare
fqdn PATCH — coollabsio/coolify#6281)
- /verify now checks Cloudflare's actual ssl.status instead of doing
a DNS CNAME lookup, which is structurally blind on proxied hostnames
Tested end-to-end against the real Cloudflare zone and Coolify app
(create, verify data, then clean up) before this push — see
docs/PROGRESS.md.
Requires CLOUDFLARE_API_TOKEN, CLOUDFLARE_ZONE_ID, COOLIFY_API_TOKEN,
COOLIFY_BASE_URL, COOLIFY_WEB_APP_UUID in the API's environment.
Without them, domain add/verify falls back to DB-only bookkeeping.
- domains.ts: a proxied Cloudflare custom hostname's real CNAME target
is never visible to a plain DNS lookup, so a re-verify always fails
and was silently downgrading already-verified domains back to
pending. Only a first-time check can now land on pending.
- restaurants.ts: PUT /restaurants/:id/theme referenced an undeclared
themeData variable (pre-existing tsc error on main, not introduced
here) — added the missing themes-by-key lookup it depended on.
Default 1 MiB limit rejected base64-encoded camera photos before the
request handler ever ran ("Request body is too large"), unrelated to
the OpenAI model. Also adds the public domains RLS policy needed for
custom-domain resolution on the public menu page (already applied
manually via SQL Editor, committing for history).
AyrisAI