Price Beacon: Cloudflare Migration

The catch

Two goals pulling in different directions

You want to fully own the stack, but without a developer and staying low-code. Those don't fully reconcile in one step — a genuine "no Lovable, no Supabase, all-Cloudflare" rebuild means rewriting the database schema and the AI quote-scanning function as Cloudflare Workers code, which is real developer work.

The resolution below: two phases you can do yourself right now, low-code, that fix the actual fault (the lockouts) and move hosting to Cloudflare as asked — plus an optional Phase 3 to go fully native later, once you have developer support. You end up owning the infrastructure either way; Phase 3 just decides who owns the database engine underneath it.

Why it keeps locking out

Two different things can pause a hosted database, and Price Beacon has hit the more annoying one.

Backend	Pauses when…	Resume
Lovable Cloud (current)	Lovable workspace credit balance hits zero — a billing trigger, not a usage one.	Blocked until credits are topped up or the plan is upgraded. This is what's caused the two lockouts so far.
Self-managed Supabase (Phase 1)	7 straight days with no activity at all on the free tier.	One click in the Supabase dashboard, data untouched. A tool the team opens daily is unlikely to ever trip this.

Where each phase lands you

Layer	Today	After Phase 1 + 2	Phase 3 (optional, later)
Hosting	Lovable preview infra	Cloudflare Pages	Cloudflare Pages
Database	Lovable Cloud (Supabase, Lovable-billed)	Supabase, BRW-owned account	Cloudflare D1, or Supabase via Hyperdrive
Quote-scanning function	Supabase Edge Function	Supabase Edge Function (unchanged)	Rewritten as a Cloudflare Worker
Day-to-day editing	Lovable AI chat	Lovable AI chat (unchanged)	Needs a developer
Who's billed	Lovable	Supabase + Cloudflare, both BRW's own accounts	Cloudflare only

The plan

Phase 1 · Do this first

Stop the lockouts — own the database

Moves the data off Lovable's credit-based hosting onto a Supabase project BRW controls directly. Entirely inside Lovable's normal interface — no code.

0 / 9

1.1Create a Supabase account for Border Rock Walls (if you don't have one) — this is the account that will own the data going forward, separate from Lovable.
1.2Back up first: export the current materials, suppliers, units, equipment_types and price_entries tables (CSV, or ask Lovable support how to pull a full project dump). Lovable is explicit there's no automatic migration path — treat this as a manual cutover.
1.3In Lovable: Workspace → Connectors → Supabase, and link the new BRW Supabase account.
1.4Create a fresh, empty project inside that Supabase account for Price Beacon to move into.
1.5In Lovable: More → Cloud → "Already have a Supabase project? Connect it here" → select the new project.
1.6Ask Lovable's AI chat directly: "Recreate the current database schema, tables and the Scan Quote AI edge function in the newly connected Supabase project." It already knows the schema — this saves you writing any SQL.
1.7Re-import the backed-up data (Supabase's table editor accepts CSV import directly), then re-enter the access code and stale-days threshold in Settings — these don't carry over automatically.
1.8Test end to end: log in, search a material, run one Scan Quote upload, and confirm the duplicate-detection warning still fires correctly.
1.9Leave the old Lovable Cloud project untouched for a week as a rollback net before archiving it. Once real usage settles, decide whether Supabase's free tier is enough or a $25/mo Pro upgrade (removes pausing entirely) is worth it.

Phase 2 · Do this next

Move hosting to Cloudflare Pages

Puts the app itself on Cloudflare while you keep editing it in Lovable exactly as before — Lovable's GitHub sync and Cloudflare's Git integration do the handoff.

0 / 8

2.1In Lovable project settings, connect GitHub. This creates a repo with the full codebase and keeps it synced both ways, free on every plan.
2.2Create a Cloudflare account for BRW (separate from any personal one).
2.3Paste the prompt below into Lovable's AI chat so it adds Cloudflare's official deployment config to the codebase before Cloudflare tries to build it.
2.4Ask Lovable's chat directly afterwards: "What build command and output directory should I enter in Cloudflare Pages?" — note the exact answer down for the next step.
2.5In Cloudflare: Workers & Pages → Create → Pages → Connect to Git → select the Lovable-created repo, then enter that build command and output directory.
2.6Copy the Supabase URL, Supabase anon key and any AI vision API key from Lovable's environment settings into Cloudflare Pages' environment variables.
2.7Deploy. Cloudflare gives you a *.pages.dev address immediately — run the same login / search / scan-quote test as Phase 1 on it.
2.8Once it checks out, point a real domain at it if you want one (e.g. a subdomain of borderrockwalls.com.au) via a CNAME in Cloudflare's DNS settings. Day-to-day editing in Lovable doesn't change — every save still syncs to GitHub and redeploys automatically.

Paste into Lovable's AI chat

This project needs to be deployable on Cloudflare Pages/Workers, in addition to Lovable's own hosting — keep everything else the same. Please add Cloudflare's official TanStack Start deployment support to this codebase: install and configure the @cloudflare/vite-plugin, add a wrangler.jsonc with compatibility_flags: ["nodejs_compat"] and the correct server entry point (@tanstack/react-start/server-entry), following https://developers.cloudflare.com/workers/framework-guides/web-apps/tanstack/. Then tell me exactly what build command and output directory to enter when I set this repo up in Cloudflare Pages. Don't change any existing features, data, or the Supabase connection — this should only add the ability to deploy to Cloudflare alongside what already works.

Phase 3 · Optional, later, needs a developer

Go fully Cloudflare-native

Only worth doing if you want zero dependency on Supabase or Lovable at all. This is a genuine rebuild, not a config change — hold off until there's developer time budgeted for it.

Rebuild the schema (materials, suppliers, units, equipment_types, price_entries, app_settings) in Cloudflare D1 — a SQLite database, so the Postgres schema needs re-modelling, not a straight copy.
Rewrite the Scan Quote AI-vision extraction as a Cloudflare Worker function, calling an AI vision API directly instead of a Supabase edge function.
Rebuild the access-code check (currently a SHA-256 hash in Supabase, checked via a session cookie) as Worker logic against D1.
Alternative that avoids re-modelling the data: keep the existing Postgres schema in Supabase, but connect to it from a Cloudflare Worker via Hyperdrive instead of D1 — same database, Cloudflare only handles the connection pooling. Less "fully native," considerably less rework.
From this point, changes to the app need to be written as Worker/Vite code directly — Lovable's AI builder is no longer the one making the changes.

Running cost, roughly

Setup	Hosting	Database	Notes
Today	$0	$0	Free, but the credit-pause risk is exactly what this plan fixes.
Phase 1 + 2	$0	$0–25/mo	Cloudflare Pages free tier easily covers a team tool this size. Supabase Pro (~US$25/mo) is optional — only needed to remove inactivity pausing entirely.
Phase 3	~$5/mo	Usage-based	Cloudflare's paid Workers plan plus D1/Hyperdrive usage — plus developer time, which will be the real cost here.

Before you touch anything

Rollback safety net

Don't cancel or downgrade the current Lovable Cloud project until Phase 1 has been tested end to end and run for at least a few days without issue. Keep the old *.lovable.app preview link working as a fallback until the Cloudflare Pages URL has proven itself with real daily use — password-checked login, a real search, and one real Scan Quote upload, not just a homepage load.