Staticbot vs Dreamlit
Both move your Lovable Cloud data to Supabase without password resets. They're built for different jobs after that — here's the honest breakdown.
Dreamlit moves your data. Their lovable-cloud-to-supabase-exporter is free, open-source, narrowly focused, and excellent at copying database tables, auth users (passwords preserved), and storage files to a fresh Supabase project.
Staticbot moves your data and Edge Functions, OAuth identity links, vault secrets, and cron jobs — then deploys your frontend to AWS (your own account or managed by Staticbot) with a custom domain. Optional Continuous Sync also keeps your Lovable repo in lockstep with the production backend afterward, for as long as you want it to. One tool, end to end.
If you're going to handle Edge Functions, hosting, DNS, and ongoing sync yourself after the data move, Dreamlit's tool is a great choice and free. If you want one pipeline to land you in production with all of that done — Staticbot is the pipeline.
What each tool is designed for
Dreamlit's exporter
Open-source data migration tool
- Copy database tables, auth users, storage files
- Preserve password hashes (no resets)
- Free, MIT-licensed, fork-friendly
- Hosted, local web UI, or CLI
- Doesn't migrate Edge Functions, OAuth config, secrets
- Doesn't deploy your frontend
- One-time data move; no ongoing sync
Staticbot
End-to-end productionisation pipeline
- Everything Dreamlit does plus:
- Edge Functions, OAuth identities, vault secrets, cron jobs
- Frontend deploy to AWS (S3 + CloudFront + SSL)
- Custom domain, EU hosting, Staticbot-managed AWS
- Continuous Sync (optional) — every Lovable push flows to your AWS + Supabase
- Works for Lovable, Bolt, Base44, v0, Manus
- AI troubleshooting + MCP server for AI clients
Feature-by-feature
| What | Dreamlit | Staticbot |
|---|---|---|
| Database schema + table data | ||
| Auth users (password hashes preserved) | ||
| Storage files + bucket configuration | ||
| Row-Level Security policies | ||
| Edge Functions | ||
| OAuth provider config + identity re-link (Google, GitHub, Apple, …) | ||
| Vault secrets + project env vars | ||
| pg_cron scheduled jobs | ||
| Frontend deploy to AWS (your own or managed) | ||
| Custom domain + SSL cert + Route 53 DNS | ||
| Continuous Sync — optional (Lovable push → your production app) | ||
| Source service-role key stays inside your project | ||
| Open source | yes (MIT) | partial (some components on GitHub) |
| Multi-builder (Bolt, Base44, v0, Manus) | ||
| Free option | yes (entire tool) | yes (1 migration + subdomain hosting) |
How each tool handles your auth users (password vs OAuth)
"Auth users migrated" is really two different problems wearing one label. Email + password sign-ins work after either tool because both copy the bcrypt hash in auth.users.encrypted_password verbatim. OAuth sign-ins (Google, GitHub, Apple…) are where the tools diverge.
Dreamlit
- Email + password sign-ins: work after migration.
auth.usersrows are pg_dumped with their bcrypt hashes intact. - OAuth sign-ins: the
auth.identitiesrow is migrated, but the target project has no OAuth providers configured — Google / GitHub / Apple client IDs and redirect URIs live in Supabase's auth control plane, not in the database. You'll need to manually reconfigure each provider in the new project's auth dashboard before OAuth users can sign in again.
Staticbot
- Email + password sign-ins: work after migration. Same mechanism as Dreamlit.
- OAuth sign-ins: Staticbot also migrates the provider configuration (Google / GitHub / Apple client IDs, redirect URIs, JWT settings) and re-links
auth.identitiesto your target's Auth service. Users who signed in with a provider continue signing in without re-authorising and without operator intervention.
How each tool handles your source Supabase service-role key
Both tools also need to write data into your target Supabase project, which requires the target's service-role key — that's unavoidable for any automated migration. The interesting difference is how each tool handles the source project's service-role key, which has read access to your existing production data.
Dreamlit
You manually deploy their migrate-helper edge function to your source Supabase, set a one-time random x-access-key in the function code, and call it from their tool.
When authorised by the matching key, the function returns SUPABASE_DB_URL and SUPABASE_SERVICE_ROLE_KEY over HTTPS to Dreamlit's tool. Their tool then uses those credentials directly to read your data.
Reasonable for many threat models. The source service-role key leaves your project, gated by a one-time access key.
Staticbot
Staticbot commits a temporary export function to your Lovable repo via the GitHub API. Lovable AI deploys it to your source Supabase, where the function reads SUPABASE_SERVICE_ROLE_KEY from native Supabase env vars and does the export work in-place.
Only the exported data — not the source service-role key — leaves your source project. Staticbot reads only the public Supabase URL and anon key from your GitHub repo for the discovery phase.
The temporary function is removed from the repo after the migration completes. The target project's service-role key is retrieved separately via Supabase's management API once you OAuth-authorise the Supabase integration.
When to pick which
Pick Dreamlit if…
- You need the data on a Supabase project and nothing else
- You'll redeploy Edge Functions yourself from your repo
- You're comfortable handling OAuth provider config, secrets, and cron jobs by hand
- Cost matters — free works
Pick Staticbot if…
- You want Edge Functions, OAuth identities, secrets, and cron jobs migrated automatically — not just rows + files
- You want the frontend deployed to your own AWS S3 + CloudFront with a custom domain and SSL, not just "here's your Supabase, go figure out hosting"
- You want the option to keep editing in Lovable (or Bolt, Base44, v0, Manus) and have those changes flow automatically to your own production infra — Continuous Sync is opt-in and free; you can also do a one-shot migration and never enable it
- You'd rather not see, paste, or handle the source Supabase service-role key anywhere in the workflow
- Going to AWS via Terraform you can take with you matters — no Staticbot lock-in on the infra side
The reason both tools exist
Lovable's official guide for moving off Lovable Cloud asks every one of your real users to reset their password. For an app with paying customers, that's a non-starter — you'd be emailing your entire user base with a forced password reset, and you'd lose a percentage of them in the silence after.
Both Staticbot and Dreamlit's tool exist primarily to fix that one thing: move your data, your users, and your storage to Supabase with password hashes intact, no reset emails, no churn. Whichever you pick — that part you get either way.
FAQ
Migrate your Lovable app to your own AWS + Supabase
Data, Edge Functions, OAuth identities, custom domain, continuous sync — one pipeline, ~15 minutes. Free first migration, no credit card.