Deploy your exported Lovable app on ohmyho.st

You have exported your Lovable project to GitHub. Paste the prompt below into your coding agent: it reads the repository, plans a Dev deployment on ohmyho.st, and only after you have tried the preview promotes it to Prod. Keeping Supabase and moving to managed Postgres are separate choices, each requiring verification. Free gives 200 credits a month; Paid is $10 a month for 1,000 credits, and a small app uses about 567.10 credits.

What this page is for: deploying the exported app here. If you are still deciding whether to move, or want a checklist of what Lovable's own documentation says you must redo, read the guide Hosting a Lovable app after export: a migration checklist first. To get the repository, follow How to export Lovable code to GitHub.

Deploy it: paste this prompt

Open your coding agent (Claude Code, Cursor or Codex), tell it the repository URL, and paste this. If the repository is not on your machine yet, the agent clones it.

Read https://ohmyho.st/llms.txt and https://ohmyho.st/skills/ohmyhost-get-started/SKILL.md. Connect this agent to ohmyho.st and develop and deploy this application using only the capabilities it needs. Read the existing project source first and follow the get-started Skill to reuse GitHub or managed versions for this workspace. After signing in, use the user and organization that whoami reports; never guess an account, organization or project ID. Follow the deployment Skill, keep my existing project decisions and verify the app.

What happens next, in plain words. The agent reads two pages, installs the ohmyho.st CLI and MCP server, and prints a sign-in link with a short code. You open the link in your browser, check that the page shows the same code, and sign in or sign up. For a selected GitHub source it obtains repository access when needed; managed source saves the current files as a version. It reviews a deployment plan with you and only then builds. Every expensive step is a plan you confirm: deployment_plan before deployment_create, promotion_plan before promotion_execute. Private values use local stdin or the supported remote portal path below, only when the app needs them.

Export to GitHub

Need the exact menu clicks? Follow How to export Lovable code to GitHub, our screenshot guide to connecting GitHub, checking the sync and downloading your source code.

Lovable's external-hosting guide (read 2026-10-27) names two stacks: older React + Vite apps that build to static files in dist/, and TanStack Start apps created from May 13, 2026 that also run server code. Both are supported frameworks here (Vite, TanStack Start); the agent tells you which one your repository is before it plans anything. The agent checks the exported source, build command and dependencies with ohmyhost init --dry-run --json. A frontend build alone does not establish that its external database, authentication or files work from the new host; test those flows on Dev before moving production traffic.

Lovable's GitHub integration keeps the project "in continuous sync with your repository", and "external platforms deploy directly from GitHub" (https://docs.lovable.dev/tips-tricks/external-deployment-hosting, read 2026-09-20). The sync runs both ways: edits you make in Lovable land in the repository as commits, and commits from your agent show up in Lovable.

You can also keep working on the exported code with the agent you already use. The Lovable alternative guide explains how Claude Code, Codex, Cursor and Grok Build fit that workflow and how to coordinate their edits with Lovable's sync. To try the exported app on your own computer first, follow How to run a Lovable project locally.

Three things to do in Lovable:

1. Connect GitHub from your project's settings and let Lovable create the repository under your GitHub account.
2. Wait for the first push. Open the repository on github.com and check that package.json, vite.config.ts and a .env file are there.
3. Leave Lovable connected. You can keep prompting there; each change becomes a commit your agent can deploy.

For this selected GitHub export, your agent uses github_connect when needed, you approve repository access in the browser, and source_link ties it to the project. An existing ohmyho.st project keeps its current source; accessible local files can instead be saved as managed versions through the deploy Skill. No hosting dashboard upload is required. GitHub details: https://docs.ohmyho.st/github.

What breaks after export

Lovable's own guide lists the seams. Read them once so the checklist further down makes sense.

The three VITE_ values

VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY and VITE_SUPABASE_PROJECT_ID sit in the .env file "in Lovable's code editor or in your synced GitHub repository", and "environment variables prefixed with VITE_ are embedded at build time, not runtime" (docs.lovable.dev, read 2026-09-20). For a selected GitHub export, verify the public build values in that repository. Managed snapshots exclude .env files; preserve required non-secret build configuration in the supported source files instead. The publishable key is public by design; it belongs in the browser bundle. If you keep the same Supabase project, these three lines do not change.

OAuth redirect URLs and Site URL

Lovable says: "If your app uses Google sign-in or other OAuth providers, add your new production domain to your authentication provider's allowed redirect URLs." For a Supabase app the place is Supabase's dashboard, Authentication → URL Configuration. Site URL is where Supabase sends people after a magic link or a password reset; Redirect URLs is the allowlist for OAuth callbacks. Both still point at your old Lovable host. Add the Dev host, the Prod host and, later, your own domain.

Secrets

Anything private (a service role key, a Stripe secret, a third-party API key) must never carry the VITE_ prefix; Vite would ship it to every visitor. A local agent uses the stdin command from secret_set_command; a supported remote connection uses the private portal input from secret_input_request. Enter the value through that private path, never in chat or source. Details: https://docs.ohmyho.st/secrets.

SPA rewrites

A React app with client-side routes needs the host to "configure a fallback rewrite so all routes serve /index.html" (docs.lovable.dev, read 2026-09-20). Otherwise /dashboard works when you click there and returns 404 when you reload. Vite artifacts on ohmyho.st serve index.html for paths without a static file. After the first Dev deploy, ask the agent to open a deep link directly and reload it. An edge companion is needed for the app's own server routes, rather than for the fallback alone. Framework notes: https://docs.ohmyho.st/frameworks/vite.

Keep Supabase or import a dump

Two honest paths. The first is smaller.

Keep Supabase (recommended for a first move)

Keeping Supabase is an option to verify against your actual export. The agent inventories browser requests, backend functions, authentication and files, then declares the exact external browser origins the app uses in runtime.browser in ohmyhost.yaml. Browser connections and external scripts, images or other resources have separate declarations; undeclared origins keep the restrictive defaults. Server-side calls use runtime.egress.allow instead. Check Supabase's allowed redirect URLs and Site URL, and verify login, a protected read, a write and file access on Dev before moving production traffic. This route keeps the backend at Supabase rather than copying it into ohmyho.st. Supabase's existing bill remains separate; Supabase Pro is from $25 per month.

Import a dump into managed Postgres

If you want off Supabase, the agent follows the Supabase migration Skill. It inventories what the app really uses: queries, RPCs, RLS assumptions, Auth sessions, Storage calls, Edge Functions, Realtime. A package name alone is not a reason to replace anything. The schema conversion takes only your application-owned public (and optional private) schema; Supabase's auth and storage schemas never enter it. So users do not come across as-is: passwords cannot be exported, and the app needs its own auth. The managed Better Auth bridge requires its database; managed mail is optional. Its verification/reset sends use the configured platform sender and require Paid access and your verified sender domain. A customer-owned Better Auth implementation and sender remain ordinary dependencies; customer-owned WorkOS AuthKit is another documented path (https://docs.ohmyho.st/application-auth). Verify the chosen auth flow separately after the frontend works on Dev.

Either way your data stays portable. An Owner can request a password-encrypted ZIP with a SQL dump (project_export_create): one accepted request for each project in any 24-hour window, download link valid 24 hours. SQL exports are free, even at zero credits.

List prices checked on 2026-09-28 — Supabase pricing.

How to move your app from Lovable

1. Export: connect GitHub in Lovable and let it create the repository. Confirm the first push on github.com.
2. Paste the prompt above into your agent. Sign in through the link it prints; check that the code matches.
3. Inventory: the agent runs ohmyhost init --dry-run on the repository and reports the framework, the Supabase usage, required configuration names and anything unsupported without disclosing private values. Read its summary; ask questions.
4. Decide: keep Supabase (default) or ask for the migration Skill. Say it in one sentence, because the agent keeps your existing decisions unless you change them.
5. Secrets and callback URLs: the agent tells you which secrets it needs and gives you the local stdin command or supported remote private input link. You add the new hosts to Supabase's Redirect URLs and Site URL.
6. Deploy to Dev: the agent reuses your project or creates one when requested (US by default, EU if you say so at creation; the choice is permanent and prices are identical), continues or saves the managed version or links the selected GitHub repository, then plans and builds. Dev is protected by default; project_dev_share_link_get gives you a reusable share link, or you choose public Dev when the project is created.
7. Verify login on Dev: sign in with Google or email, open a protected page, reload it, sign out. Reload a deep link.
8. Promote to Prod: promotion_plan then promotion_execute reuse the same build without a rebuild. Isolated projects keep Dev and Prod data apart; Prod records are never overwritten by Dev rows.
9. Link the domain: after Prod works, domain_paid_plan returns the CNAME to set at your registrar and domain_paid_apply activates it on Paid, or on Free while the project shows the “Powered by ohmyho.st” flag; the flag waives domain credits on either plan (https://docs.ohmyho.st/domains). Add the domain to Supabase's Redirect URLs, then run the login check once more on the real address.

Every step maps to a Skill the agent reads on its own: get started, deploy the selected source, domains and mail.

My login still works: the checklist

Run this three times: on the Dev link, on the Prod host, and on your own domain after it is linked.

• The three VITE_SUPABASE_* values in the repository match the Supabase project you kept. A mismatch shows up as an app that loads and then cannot sign anyone in.
• Supabase Authentication → URL Configuration: Site URL is your Prod address; Redirect URLs contain the Dev host, the Prod host and your domain, each with the path your app redirects to.
• Google login: the OAuth client in Google Cloud still lists your Supabase callback as its authorized redirect URI. If you kept Supabase, this did not change; if you moved auth, it now points at your new provider.
• Sign in, open a protected page, reload it, sign out. A session that survives a reload proves the token is stored for the new host.
• A magic link or password-reset mail lands on the new host, not on the old Lovable address.
• A deep link such as /settings loads directly and after a reload.
• Dev 404 for anonymous visitors is expected: Dev is protected by default. Use the share link, not the raw URL.

If any line fails, tell the agent which one. deployment_logs and operation_get give it the diagnostics; it does not need you to read them.

What it costs

On Lovable, one balance pays for three different things. Its pricing page (read on List prices checked on 2026-09-21 — Lovable pricing.) says credits are spent "for building by sending messages to Lovable, hosting with Cloud, and offering AI features to users as part of your app". Pro is €25 a month including VAT and grants 100 credits. Lovable's own examples put one prompt at 1.20 credits for adding authentication and 1.70 credits for a landing page, so the month's credits are roughly sixty to a hundred edits — and every request your live app serves competes with them.

Here, the balance pays for infrastructure only. The model that writes your code is your own agent's subscription; ohmyho.st never charges for prompts. Paid is $10 a month for 1,000 credits, Free grants 200 credits each UTC month, and there is no per-project fee. Monthly credits expire at period end. Paid-only top-ups carry over until downgrade to Free.

Two setups, two bills. Pick the row that matches yours.

If you keep Supabase

Supabase keeps the database and the login; ohmyho.st meters the frontend only — the build, the requests, the CPU time, one deployed script and the hostname.

About $0.68 of credit value at the standard rate.

Drop the custom hostname and the rest fits inside the Free plan's 200 credits a month, on the <three-words>.check.omh.st address every project gets.

If you move the backend too

Leaving Lovable Cloud means the database and the mail run here as well. Then the month looks like this:

About $5.67 of credit value at the standard rate.

A linked domain adds 32.857143 credits per 1 paid custom hostname for a 744-hour month, about 32.86 credits a month, and needs Paid; while the project shows the “Powered by ohmyho.st” flag it also works on Free and uses no domain credits. The tables price a hostname without the flag.

Retained scripts still use about 6.57 credits a month and customer files keep their own rates. Sleeping databases have no active-RAM charge, with disk and seven-day backups included. Worker bandwidth is not charged. A zero balance starts the seven-day grace period. A project budget can continue or stop work: https://docs.ohmyho.st/budgets.

FAQ

Will my Google login keep working?

It can, but check the deployed flow before moving traffic. If Supabase stays, confirm that Google's OAuth client still points to the existing Supabase callback, declare the browser origins the export needs, and add the Dev host, Prod host and your own domain to Supabase's Redirect URLs and Site URL. Sign in, reload a protected page and sign out on each. If you migrate auth away from Supabase, the agent registers the new callback URLs with your chosen provider and tests again.

Can I keep building in Lovable?

Yes. Lovable's GitHub integration keeps the project in continuous sync with the repository, so prompts in Lovable become commits. With that GitHub source selected, your agent plans the pushed commit and promotes it after you check Dev. A project using managed versions saves the intended current files instead; switching source is an explicit choice on the existing project. Keep one rule: do not edit the same file in Lovable and in your agent at the same moment, or you will be resolving merge conflicts you did not need.

What about Lovable Cloud data?

Lovable's guide says the backend "can remain on the built-in backend (Cloud) or run elsewhere" (docs.lovable.dev, read 2026-09-20). Its current database export is under More → Database → Manage → Settings → Export project data. It contains the database structure, records and user accounts with their password hashes, so users restored into a Supabase project keep their passwords. Storage files, function code, secrets and sign-in provider settings are not included and move separately (read 2026-10-27). How to move out of Lovable Cloud walks through that move. Before choosing to keep Cloud behind a hosted frontend, verify its actual functions, login and file access on Dev. Keep the data move separate from the hosting change.

Do I have to use the terminal?

Almost never. The agent installs the CLI, prints the sign-in link and runs every command. A private secret uses the local stdin command or the private portal link for a supported remote connection, keeping its value out of chat and source. If your Lovable app only uses the public Supabase publishable key, you will not even do that.

Sources

• List prices checked on 2026-09-28 — Supabase pricing.
• List prices checked on 2026-09-21 — Lovable pricing.

From Bolt · Compare Supabase · Cost breakdown · Host a Lovable app after export