[DeployHQ Static Hosting](https://www.deployhq.com/hosting/static) 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](https://www.reddit.com/r/lovable/comments/1qupsrk/sorry_lovable_but_i_moved_on/) 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](https://www.deployhq.com/blog/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](https://www.deployhq.com) 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](https://www.deployhq.com) 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](https://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](https://www.deployhq.com) 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](https://www.deployhq.com) 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](https://www.deployhq.com) 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](https://www.deployhq.com) 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](https://www.deployhq.com) 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](https://www.deployhq.com) runs your build before transferring artifacts to the edge. For a Lovable project, the [build pipeline](https://www.deployhq.com/features/build-pipelines) 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](https://www.deployhq.com/signup) 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](https://www.deployhq.com) 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](https://www.deployhq.com) 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](https://www.deployhq.com).

## 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](https://www.deployhq.com) 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](https://www.deployhq.com). 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](https://www.deployhq.com) 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](https://www.deployhq.com/hosting). The [Static Hosting pillar guide](https://www.deployhq.com/blog/static-hosting-on-deployhq) 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](https://www.deployhq.com) project:

1. **Move the custom server to [DeployHQ Managed VPS](https://www.deployhq.com/hosting/managed-vps)** and keep the Lovable frontend on Static Hosting. The frontend talks to both Supabase and your VPS server — [DeployHQ](https://www.deployhq.com) 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](https://www.deployhq.com) fits alongside the rest of the deployment-tool category, our [best software deployment tools in 2026](https://www.deployhq.com/blog/best-software-deployment-tools) post is a useful reference. And for context on the broader [DeployHQ](https://www.deployhq.com) proposition across all five hosting types it supports, see [your universal deployment and hosting platform](https://www.deployhq.com/blog/deployhq-your-universal-deployment-platform-for-all-hosting-types).

If you're sizing what's included before signing up, the [DeployHQ pricing page](https://www.deployhq.com/pricing) 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](https://www.deployhq.com/support/servers/static-hosting).

* * *

Questions or feedback on deploying Lovable apps to [DeployHQ](https://www.deployhq.com) Static Hosting? Email [support@deployhq.com](mailto:support@deployhq.com) or follow [@deployhq](https://x.com/deployhq) on X for product updates.