How to Deploy a Lovable Frontend to DeployHQ Static Hosting

By Alex M · Posted on

AI, Devops & Infrastructure, Frontend, and Tutorials

How to Deploy a Lovable Frontend to DeployHQ Static Hosting

DeployHQ Static Hosting serves pre-built static assets from Cloudflare's global edge — a clean fit for a Lovable project, where the React + Vite frontend compiles to a flat directory and the heavy lifting (auth, database, file storage, business logic) lives on Supabase. This guide walks through deploying a Lovable app end to end: sync the project to GitHub, line up the Supabase configuration, provision Static Hosting, configure the build pipeline, and ship the first deploy.

A pattern is showing up in the Lovable community: users hit a wall around iteration cost — credit usage climbing, fixes that break adjacent code, the AI going in circles on what should be simple corrections. The migration pattern users share in r/lovable is some variation of keep Lovable for the initial scaffold, then continue in your own editor with Claude Code or Cursor, with Supabase still handling the backend, and free hosting on top. That fourth bullet — the hosting — most often defaults to Vercel because it's the most visible free option. This guide is for the version of that playbook where the hosting is DeployHQ Static Hosting on Cloudflare's edge instead — same Cloudflare edge, different workflow, with the trade-offs laid out in our DeployHQ Static Hosting vs Vercel comparison.

The framing matters: Static Hosting replaces the <project>.lovable.app URL Lovable provisions by default, not the Supabase backend behind it. Auth still flows through Supabase. Data still lives in Supabase. Storage and Edge Functions still run on Supabase. Static Hosting is the public face — a faster, lock-in-free home for the React bundle that calls all of it. If you've extended a Lovable project with your own custom Node server beyond what Supabase Edge Functions cover, that code needs a runtime Static Hosting doesn't provide — point it at DeployHQ Managed VPS or any backend you already run.

What you'll build

By the end of this guide:

  • A Lovable project synced to your own GitHub repository
  • A DeployHQ project with Static Hosting connected to that repo
  • A working build pipeline that runs vite build and uploads the output to Cloudflare's edge
  • Supabase Auth redirect URLs updated to point at the new domain
  • The site serving over HTTPS at <subdomain>.deployhq-sites.com (and optionally a custom domain)
  • Atomic deploys on every push to main, with one-click rollback to any previous version

Expected time: under 20 minutes from a Lovable project you already have generated.

Prerequisites

  • A Lovable project — generated at lovable.dev — connected to Supabase and working at its *.lovable.app URL
  • A GitHub account Lovable can sync to
  • Access to the Supabase project's dashboard (you'll update Auth redirect URLs in Step 6)
  • A DeployHQ account with beta features enabled (enable under Settings > Beta Features)
  • Node.js installed locally if you want to test the build before pushing (optional but recommended)

If you don't have a DeployHQ account yet, you can start a free trial in the next step — the trial includes one Static Hosting site at no charge while the feature is in beta.

Step 1: Sync your Lovable project to GitHub

Lovable has built-in GitHub sync — every change you make in the Lovable editor commits to a GitHub repo you control, and you can push from your own editor too.

In Lovable:

  1. Open the project you want to deploy
  2. Click GitHub in the project menu (top right)
  3. Authorize Lovable to access your GitHub account if you haven't already
  4. Either Create new repository for a fresh export, or Connect existing repository if you've already set one up
  5. Confirm the sync — Lovable pushes the current state of the project to the main branch

The repository now mirrors the Lovable project: src/, package.json, vite.config.ts, tailwind.config.ts, index.html, and the supabase/ directory containing migrations and Edge Function code if you've used them.

Open the repo in GitHub and confirm the project structure is intact. The next steps assume you're working from this repo — Lovable's two-way sync means changes you push from your own editor flow back into the Lovable UI, and vice versa.

Step 2: Verify the Supabase configuration

Lovable apps consume Supabase via the @supabase/supabase-js SDK. Two environment variables drive the connection:

  • VITE_SUPABASE_URL — your project's URL, e.g., https://abcxyz.supabase.co
  • VITE_SUPABASE_ANON_KEY — the public anon key (it's safe in client bundles thanks to Row Level Security)

These are normally pulled from .env in the Lovable editor. In production they need to be set in DeployHQ's environment-variable UI (covered in Step 4) — .env files never deploy with the build artifact.

Open src/integrations/supabase/client.ts (Lovable's default location) and confirm it reads from import.meta.env.VITE_SUPABASE_URL and import.meta.env.VITE_SUPABASE_ANON_KEY. If it does, you're set — those are the two variables that travel into the static bundle at build time. If you've hardcoded the values, swap them back to env reads before pushing to production.

If your project uses Supabase Edge Functions for things like Stripe webhooks, transactional email, or scheduled jobs, those continue to run on Supabase — Static Hosting doesn't host them and doesn't need to. The frontend just calls them via supabase.functions.invoke(...) the same way it always has.

Step 3: Provision a Static Hosting site in DeployHQ

In your DeployHQ project (or create one and connect it to the Lovable repository), click New Server:

  1. Enter a name for the server — internal reference only, doesn't affect the public URL
  2. Select Static Hosting from the protocol picker under Hosting
  3. Choose a subdomain — your site serves at <subdomain>.deployhq-sites.com. Subdomains are unique across all DeployHQ accounts; lowercase letters, numbers, and hyphens only
  4. Set the subdirectory to deploy from to dist (the default Vite output directory Lovable uses)
  5. Toggle SPA mode on — Lovable apps use React Router for client-side routing, so unknown paths need to be rewritten to index.html for routes to resolve on direct page load
  6. Click Create Server

DeployHQ runs framework detection against the connected repository. For a stock Lovable project, the detector picks up Vite + React and suggests these exact settings — accept them unless you've made non-default changes.

Provisioning takes under a minute. Once the status flips to active, the site exists on Cloudflare's edge — but no code has shipped yet.

Step 4: Configure the build pipeline

DeployHQ runs your build before transferring artifacts to the edge. For a Lovable project, the build pipeline is two stages: install, then build.

In the project's build settings, add:

npm ci
npm run build

Lovable uses npm by default, so the standard commands work. If you've switched to pnpm or bun, swap accordingly.

Environment variables to set in DeployHQ's environment-variable UI:

  • VITE_SUPABASE_URL — your Supabase project URL
  • VITE_SUPABASE_ANON_KEY — your Supabase anon key
  • Any other VITE_* variables your project uses (Stripe publishable key, public API endpoints, feature flags)

The VITE_ prefix is critical — Vite only inlines variables with that prefix into the client bundle. Anything without it gets stripped at build time, which is the right behavior for secrets but a footgun if you accidentally omit the prefix on something that needs to reach the browser.

What you should not put here: Supabase service-role keys, Stripe secret keys, any API token that grants more than public access. Those belong in Supabase Edge Function secrets (set via the Supabase CLI or dashboard), never in a static bundle.

Ready to take it live? Sign up free for DeployHQ if you don't have an account, and the beta-tier Static Hosting site is enough to ship this guide end to end.

Step 5: First deploy

Push any change to the configured branch (typically main), or trigger a manual deployment from the DeployHQ dashboard. DeployHQ:

  1. Clones the repo at the head of the configured branch
  2. Runs the build pipeline (npm ci && npm run build)
  3. Uploads the contents of dist/ to object storage atomically
  4. Flips Cloudflare's edge routing to serve the new version

The deployment log streams each step in real time. When it completes, visit https://<subdomain>.deployhq-sites.com — the site loads but auth will not yet work end-to-end. That's Step 6.

If the build fails, the log shows the exact error. Most common failures for Lovable projects:

  • A missing VITE_* env var the client bundle references at build time
  • A path alias in vite.config.ts pointing somewhere that exists in the Lovable editor but not the repo
  • A dependency Lovable expects to be available but isn't in package.json (rare; usually surfaces as a missing-module error)

Fix the issue in the repo, commit, push — DeployHQ runs the next build automatically.

Step 6: Update Supabase Auth redirect URLs

Supabase Auth has an allowlist of redirect URLs — sign-in flows redirect users back to one of those URLs after authentication. Until your new domain is on that list, OAuth and magic-link sign-ins will fail with a redirect-mismatch error.

In the Supabase dashboard:

  1. Open the project that backs this Lovable app
  2. Navigate to Authentication > URL Configuration
  3. Add https://<subdomain>.deployhq-sites.com to the Site URL field (or whatever custom domain you'll use from Step 7)
  4. Add https://<subdomain>.deployhq-sites.com/** to the Redirect URLs allowlist (the /** wildcard covers post-sign-in paths)
  5. Save

You can keep the existing *.lovable.app URL in the allowlist if you want to leave the Lovable preview environment working — Supabase allows multiple Site URLs and redirect entries.

Sign out, sign back in, and confirm the auth flow round-trips correctly on the new domain.

Step 7: Add a custom domain

To serve from your own domain (e.g., app.example.com):

  1. In your DNS provider, add a CNAME record pointing your subdomain to <subdomain>.deployhq-sites.com
  2. Wait for DNS propagation (usually minutes; depends on your TTL)
  3. Cloudflare provisions an HTTPS certificate automatically once the CNAME resolves
  4. Repeat the Supabase Auth allowlist update (Step 6) with the new custom domain so OAuth flows from app.example.com round-trip correctly

Your site now serves from app.example.com over HTTPS via Cloudflare's edge, talking to the same Supabase backend Lovable provisioned for you.

For an apex domain (example.com with no subdomain), use an ALIAS or ANAME record if your DNS provider supports them — Cloudflare DNS, DNSimple, and Route 53 all do. Otherwise, host the apex elsewhere and CNAME a www subdomain to DeployHQ.

Common gotchas

OAuth provider rejects the new domain. Google, GitHub, and other OAuth providers have their own allowlists in addition to Supabase's. Open each provider's app/credentials page (Google Cloud Console, GitHub OAuth Apps, etc.) and add the new Supabase callback URL to the authorized redirect URIs. The error usually appears as redirect_uri_mismatch in the OAuth provider's response.

VITE_* variables aren't picked up. Vite reads env vars at build time, not runtime. If you set the env vars in DeployHQ but they don't appear in the bundle, double-check (a) the variable names match exactly (no typos in VITE_SUPABASE_URL), (b) you triggered a new build after setting them, and (c) you're checking the live bundle, not a cached one.

Routes 404 on direct page load. SPA mode is off in DeployHQ. Toggle it on — Static Hosting will rewrite unknown paths to index.html so React Router takes over.

Database queries return empty in production but worked in preview. Almost always a Row Level Security policy mismatch. The Lovable preview environment sometimes uses a different Supabase user context. Check the RLS policies on the relevant tables and confirm they allow the production user's auth role.

Edge Function calls fail with CORS errors. Supabase Edge Functions have a per-function CORS allowlist. Add the new domain to the CORS configuration in the function's source (Deno.serve handler) and redeploy the function via supabase functions deploy <name>.

Tailwind classes look broken in production. Lovable's Vite + Tailwind setup uses the default content paths in tailwind.config.ts. If you've moved components into nested directories, double-check the content globs cover them — ./src/**/*.{js,ts,jsx,tsx} is the default and covers most layouts.

The build pulls in old Lovable preview artifacts. Lovable sometimes leaves files under .lovable/ or similar in the repo. These don't affect the build but bloat the repo. Add them to .gitignore and clean them out if you want a tidier deploy.

What you've shipped

You now have:

  • A Lovable frontend rebuilding on every push to main
  • Atomic deploys with no downtime during the transfer
  • HTTPS over Cloudflare's edge with automatic certificate management
  • One-click rollback to any previous deployment from the DeployHQ dashboard
  • Supabase Auth, database, storage, and Edge Functions unchanged, doing exactly what they did before
  • A clean separation between the static UI and the backend Lovable built for you

For the broader context of how Static Hosting fits among DeployHQ's other hosting types, see the hosting hub. The Static Hosting pillar guide covers framework auto-detection, SPA mode, and the head-to-head against the most common alternatives — directly relevant for Lovable users weighing the trade-offs between Lovable Cloud's built-in hosting and a third-party edge.

What's next

If your Lovable project grows beyond what Supabase Edge Functions can cover — you add a long-running background worker, a custom WebSocket server, or a Node service that doesn't fit the serverless model — there are two clean upgrade paths inside the same DeployHQ project:

  1. Move the custom server to DeployHQ Managed VPS and keep the Lovable frontend on Static Hosting. The frontend talks to both Supabase and your VPS server — DeployHQ ships to both targets from the same project.
  2. Consolidate everything on Managed VPS if you'd rather run the full app in one place — the build pipeline you set up here adapts to either target.

Either path, what you've built doesn't get thrown away — the static frontend on the edge is still the right home for the UI even after the backend grows.

For a roundup of how DeployHQ fits alongside the rest of the deployment-tool category, our best software deployment tools in 2026 post is a useful reference. And for context on the broader DeployHQ proposition across all five hosting types it supports, see your universal deployment and hosting platform.

If you're sizing what's included before signing up, the DeployHQ pricing page lays out which plan covers what — the beta-tier Static Hosting site is enough to ship this guide end to end. For the full product reference, see the Static Hosting support library.

Questions or feedback on deploying Lovable apps to DeployHQ Static Hosting? Email support@deployhq.com or follow @deployhq on X for product updates.