# Staticbot > Staticbot moves your AI-built app onto infrastructure you own: full-stack apps on Cloudflare Workers, static sites on AWS S3 + CloudFront, your data on your Supabase. Migrates your existing project once; Continuous Sync keeps every push from Lovable, Bolt, Base44, v0, or Manus flowing to your infrastructure forever. Built, migrated, kept in sync only as long as you want — zero lock-in. - Full content for LLMs: https://www.staticbot.dev/llms-full.txt Staticbot lets you keep using AI builders (Lovable, Bolt, Base44, v0, Manus) while owning the infrastructure your production app actually runs on. You don't leave the builder — and if you opt in to Continuous Sync, every change you ship in it flows automatically to your own Supabase and your chosen frontend host (Cloudflare Workers for full-stack apps, AWS S3 + CloudFront for static sites). Continuous Sync is opt-in and optional — many users do a one-shot migration and never enable it. Either way, your infra keeps running independently. The workflow has two parts: 1. **Continuous Sync** (the value prop) — every push from your Lovable / Bolt / Base44 GitHub repo flows automatically to your own Supabase and your hosting (Cloudflare for full-stack apps, AWS for static sites): schema migrations apply in order, edge functions deploy, frontend rebuilds and ships. No re-migration, no copy-paste, no manual deploys. Keep editing where you love; the live infra you own stays in lockstep. 2. **Initial Migration** (one-time setup, step 1) — a guided pipeline that brings your existing app to your own infrastructure: discovers the source Supabase project (edge functions, storage buckets, auth config, database), migrates each component in phases (schema, data, auth users, OAuth identities, edge functions, storage files, secrets, cron jobs, auth config), and deploys the frontend to Cloudflare Workers (full-stack apps) or AWS S3 + CloudFront (static sites). About 15 minutes. Before anything goes live, it deploys the migrated app to a **working preview URL** (running against your own newly-migrated Supabase) and health-checks it, so you click through your real app before switching production over — nothing changes on your live site until you choose. Preview is available for both Lovable/Bolt and Base44 migrations on the managed-Supabase path. After this, Continuous Sync takes over forever. Vercel-compatible (manual setup, not automated by Staticbot): the frontend Lovable produces is a standard Vite + React project, so you can wire it to Vercel yourself while Staticbot handles the backend migration to your own Supabase. Staticbot does not deploy to Vercel automatically; the user imports the repo into Vercel and adds the new Supabase env vars. Full guide: https://www.staticbot.dev/deployment-guides/ai-tools/lovable-vercel Cloudflare Workers (TanStack Start, automated by Staticbot): Lovable made TanStack Start the default for new projects on May 13, 2026 — full-stack apps with server-side rendering. Staticbot hosts these on Cloudflare's global edge for the customer; no Cloudflare account needed on the customer's side. Custom domain stays at the customer's existing registrar; they add an ALIAS/ANAME (apex) or CNAME (subdomain) plus a TXT record we generate, and SSL is automatic. The per-customer infrastructure code is open source in the public Staticbot templates repo so customers can audit what's provisioned for them. Bring-your-own Cloudflare account is on the roadmap. Full write-up: https://www.staticbot.dev/blog/lovable-tanstack-cloudflare-workers ## Product - Free tier available — no credit card required - Sign up at https://app.staticbot.dev - Supports custom domains (CNAME / ANAME), EU hosting, and Staticbot-managed AWS accounts - Frontend deploy targets: AWS S3 + CloudFront (own account or Staticbot-managed) for SPA-style Lovable projects, OR Cloudflare Workers (Staticbot-managed CF account) for SSR Lovable projects built on TanStack Start - Backend hosting: managed Supabase, self-hosted Supabase on AWS (Terraform), or your existing Supabase project - Compatible with (manual user setup, not automated): Vercel, Cloudflare Pages, Netlify — the frontend Lovable/Bolt/etc. produces is portable and works on any frontend host once Staticbot has migrated the backend - Integrates with Supabase, Namecheap, GitHub, and Cloudflare DNS (broader Cloudflare integration with deploy scopes arriving alongside BYO Cloudflare account support) ## REST API Base URL: `https://app.staticbot.dev/api/v1` Authentication: `Authorization: Bearer sk-` Keys are generated in the dashboard under Settings → API Keys. They are org-scoped, prefixed with `sk-`, and never expire but can be revoked. ### Templates - `GET /templates` — list all available infrastructure templates - `GET /templates/{id}` — get template details including configuration variables - `POST /templates` — create a new template by scanning a GitHub repository (auto-detects platforms, env vars, builders) ### Stacks - `GET /stacks` — list all infrastructure stacks - `GET /stacks/{id}` — get stack details - `POST /stacks` — create a new infrastructure stack from a template with auto-generated, custom, or existing domain ### Deployments - `GET /deployments` — list deployments (optional `?stackId=` filter) - `GET /deployments/{id}` — get deployment status; when WAITING, includes required DNS records - `POST /deployments` — create a deployment for a stack (APPLY, PLAN, or DRY_RUN) - `POST /deployments/{id}/start` — start a created deployment ### Migrations - `POST /migrations` — create a new migration (8-phase pipeline: Discovery → DB Migration → Data Import → Edge Functions → Storage → Auth Config → Backend Switchover → Frontend Deploy) - `GET /migrations` — list all migrations (optional `?status=` filter) - `GET /migrations/{id}` — get migration with status and per-phase breakdown - `POST /migrations/{id}/confirm` — approve a migration paused after discovery - `POST /migrations/{id}/resume` — resume a migration paused by user or pending user action - `POST /migrations/{id}/pause` — pause a running migration - `GET /migrations/{id}/jobs` — list all jobs within a migration - `POST /migrations/jobs/{jobId}/retry` — retry a failed migration job - `POST /migrations/jobs/{jobId}/skip` — skip a non-critical migration job - `POST /migrations/jobs/{jobId}/complete` — complete a manual job (e.g. MANUAL_SYNC_LOVABLE) - `GET /migrations/{id}/deployments` — list deployments linked to a migration's stack - `POST /migrations/{migrationId}/jobs/{jobId}/choose-method` — choose data import method (automated or manual) - `POST /migrations/{migrationId}/jobs/{jobId}/choose-backend-switchover` — choose backend switchover strategy - `POST /migrations/{migrationId}/jobs/{jobId}/choose-frontend-deploy` — choose frontend deployment method - `POST /migrations/jobs/{jobId}/validate-function` — validate a Supabase edge function URL is reachable - `GET /migrations/integrations/instances` — list connected integration instances (Supabase, GitHub) - `GET /migrations/parse-source-keys?githubRepoUrl=` — auto-read source Supabase URL and anon key from a repo's .env file - `GET /migrations/integrations/instances/{id}/supabase-projects` — list Supabase projects on a connected integration ### Connected Projects (Continuous Sync) - `GET /connected-projects` — list all connected projects (optional `?syncMode=` filter) - `GET /connected-projects/{id}` — get connected project details, sync mode, webhook status - `POST /connected-projects/{id}/sync` — trigger a manual sync - `GET /connected-projects/{id}/sync-runs` — list sync run history - `GET /connected-projects/{id}/sync-runs/{runId}` — get sync run status and summary - `GET /connected-projects/{id}/sync-runs/{runId}/jobs` — get individual sync jobs - `POST /connected-projects/{id}/sync-runs/{runId}/confirm` — confirm a sync paused for review ### Status values Migration: `PENDING` → `PAUSED_FOR_APPROVAL` (after discovery) → `IN_PROGRESS` → `COMPLETED` / `COMPLETED_WITH_ERRORS` / `PAUSED_FOR_USER_ACTION` Sync run: `PENDING` → `IN_PROGRESS` → `COMPLETED` / `FAILED` / `PAUSED_FOR_REVIEW` (destructive migrations) ## Continuous Sync After a completed migration, Continuous Sync keeps your target Supabase project (managed or self-hosted) and frontend deployment (Cloudflare Workers for full-stack apps, AWS S3 + CloudFront for static sites) up-to-date with changes in Lovable, Bolt, or Base44. - **What gets synced:** New database migrations (applied sequentially), edge function changes (deployed in parallel), and frontend changes (rebuild + CDN invalidation) — an ordered, atomic deploy - **Non-destructive by design:** Staticbot deploys from a dedicated `staticbot/live` branch that the AI builder's changes are applied onto; the builder keeps writing to its own branch untouched. Merging `staticbot/live` back into the builder branch is an explicit, opt-in "cut the cord" action only — never automatic. - **Audit trail:** Each push produces a recorded sync run with a granular `diffInventory` (new_migrations, changed_functions, frontend_changed, storage_changed, auth_changed) tracked `fromRepoVersion → toCommitSha`; templates are pinned to commit SHAs for reproducibility. - **Trigger:** GitHub webhook on push (automatic mode) or manual trigger from the dashboard - **Sync modes:** Automatic (webhook-driven, with debouncing), Manual (on-demand), Paused. Sync is optional — cut ties to your builder anytime; your infra keeps running independently. - **Prerequisites:** Completed migration + active deployment (Cloudflare Workers or AWS) + GitHub repository ## MCP Server The Staticbot MCP server lets Claude Code (and any MCP-compatible AI client) control Staticbot infrastructure through natural language. Repository: https://github.com/bitfiction/staticbot-mcp ### Available MCP tools (36 tools) **Templates:** - `list_templates` — list available infrastructure templates - `get_template` — get template details with configuration variables - `create_template` — create a new template by scanning a GitHub repo (auto-detects platforms, env vars, builders) **Stacks:** - `list_stacks` — list all infrastructure stacks - `get_stack` — get stack details - `create_stack` — create an infrastructure stack from a template **Deployments:** - `list_deployments` — list deployments, optionally filtered by stack - `create_deployment` — create a deployment for a stack - `start_deployment` — start a created deployment - `get_deployment` — get deployment status, including DNS records when WAITING **Migrations:** - `create_migration` — create a new migration (starts 8-phase pipeline from Discovery to Frontend Deploy) - `list_migrations` — list all migrations, optionally filtered by status - `get_migration` — get current status and per-phase breakdown of a migration - `confirm_migration` — approve a migration paused after discovery - `resume_migration` — resume a paused migration - `pause_migration` — pause a running migration - `get_migration_jobs` — list individual jobs within a migration - `retry_migration_job` — retry a failed migration job - `skip_migration_job` — skip a non-critical migration job - `complete_migration_job` — complete a manual job (e.g. MANUAL_SYNC_LOVABLE with functionUrl) - `get_migration_deployments` — list deployments linked to a migration's stack - `choose_data_import_method` — choose automated or manual data import in Phase 3 - `choose_backend_switchover` — choose backend switchover strategy in Phase 7 - `choose_frontend_deploy` — choose frontend deployment method in Phase 8 - `validate_function_url` — check if a Supabase edge function URL is reachable - `list_integration_instances` — list connected integrations (Supabase, GitHub) with their type - `parse_source_keys` — auto-read source Supabase URL and anon key from a repo's .env file - `list_supabase_projects` — list Supabase projects on a connected integration instance - `lovable_sync` — trigger Lovable sync via Chrome extension bridge (auto-deploys edge function) **Connected Projects (Continuous Sync):** - `list_connected_projects` — list all connected projects - `get_connected_project` — get connected project details and sync status - `trigger_sync` — trigger a manual sync - `list_sync_runs` — list sync run history for a project - `get_sync_run` — get sync run status and summary - `get_sync_run_jobs` — get individual jobs for a sync run - `confirm_sync_run` — confirm a sync paused for review (destructive migrations) ### MCP setup (Claude Code) 1. Generate an API key at https://app.staticbot.dev under Settings → API Keys 2. Add to your `.mcp.json` or `~/.claude/settings.json`: ```json { "mcpServers": { "staticbot": { "command": "npx", "args": ["-y", "@bitfiction/staticbot-mcp"], "env": { "STATICBOT_API_KEY": "sk-..." } } } } ``` 3. Restart Claude Code and run `/mcp` to verify the server is connected. ## FAQ - **Can I migrate from Lovable Cloud to my own Supabase?** -- Yes. Automated migration handles schema, data, auth users (including Google/GitHub OAuth), edge functions, storage files, secrets, and cron jobs — typically under 20 minutes. Your Lovable project is not modified or disconnected. - **Does it migrate Google auth / OAuth users?** -- User records and OAuth identities are migrated automatically. Provider config (client ID/secret) and the OAuth callback URL must be set manually post-migration — Supabase doesn't expose provider secrets via its Management API. - **Does migration disconnect my Lovable project?** -- No. Staticbot reads from the source but does not modify it. You can keep using Lovable as staging alongside the migrated Supabase backend. - **Can I migrate to a Supabase project I've already created?** -- Yes. You create the target project yourself and Staticbot fetches the project automatically. - **Do I need to deactivate Lovable Cloud first?** -- No. The migration runs while Lovable Cloud is active. - **Can I keep editing in Lovable after migration?** -- Yes, many users do. Staticbot injects the correct target credentials at build time regardless of what Lovable does to the repo. - **Do I need to connect Lovable to GitHub first?** -- Yes. Staticbot reads your project via GitHub, so your Lovable project must be synced to a GitHub repository before starting a migration or deployment. Connect GitHub at https://lovable.dev/settings/git/github, then link your project to a repository. - **Do I need to connect Base44 to GitHub first?** -- Yes. Open your Base44 project dashboard, click the GitHub icon in the top panel, and authorize the connection before starting a migration or deployment. - **Is it really free?** -- Yes. The free tier is permanent and includes 1 full migration for projects with up to 10 SQL files, 5 edge functions, 5 tables / 50MB of data, plus 2 AI troubleshooting credits. Paid migration credits ($19 single, $39 for 5) unlock unlimited complexity and full data migration. Static site hosting is free on a Staticbot subdomain; full-stack app hosting on Cloudflare Workers (for SSR projects like Lovable TanStack apps) is $15/mo per app — and is included free for the first month with every migration credit (free or paid). - **What does hosting cost?** -- Static sites: Free on a Staticbot subdomain (1 site, 1 GB/mo); Pro Static at $5/mo (5 sites, custom domains, 50 GB/mo); Own AWS at $0 Staticbot fee (you pay AWS direct, unlimited). Full-stack apps (SSR on Cloudflare Workers): $15/mo per app — includes custom domain via SSL for SaaS, 20M requests/mo, global edge, server functions. Every migration credit includes 1 month of full-stack app hosting free. For the full Lovable migration FAQ (20 questions): https://www.staticbot.dev/deployment-guides/ai-tools/lovable-supabase-migration#faq For more general and pricing FAQ: see llms-full.txt ## Key pages - Homepage: https://www.staticbot.dev - Dashboard: https://app.staticbot.dev - API docs: https://www.staticbot.dev/platform/api-access - MCP server docs: https://www.staticbot.dev/platform/mcp-server - Guides: https://www.staticbot.dev/guides - Templates: https://www.staticbot.dev/templates - EU Hosting: https://www.staticbot.dev/eu-hosting - Pricing: https://www.staticbot.dev/pricing - Why Staticbot: https://www.staticbot.dev/why-staticbot - Blog: https://www.staticbot.dev/blog - Customer gallery - Migrated with Staticbot (live production apps that migrated off Lovable Cloud, Base44, and Bolt to their owners' own Supabase + AWS or Cloudflare): https://www.staticbot.dev/migrated-with-staticbot - Blog - Downloadable Migration Package (Self-Hosted Supabase via Claude Code): https://www.staticbot.dev/blog/downloadable-migration-package - Blog - Base44 vs Supabase: What Actually Moves When You Migrate (compatibility deep-dive for product owners and vibe coders): https://www.staticbot.dev/blog/base44-supabase-compatibility - Blog - AI Builder Hosting Cost Comparison (Lovable vs Bolt vs Supabase vs Vercel, 2026): https://www.staticbot.dev/blog/ai-builder-hosting-cost-comparison - Blog - PostHog Proxy Deployment: https://www.staticbot.dev/blog/posthog-proxy-deployment - Blog - Lovable Apps for Enterprise: https://www.staticbot.dev/blog/lovable-apps-for-enterprise - Blog - Migrate via MCP Chat: https://www.staticbot.dev/blog/migrate-via-mcp - Blog - Managing Your AI App After Migration (post-migration playbook: keep building in the AI builder OR edit the repo directly with Claude Code since it's standard Supabase now; Continuous Sync as a recorded audit trail across Supabase + Cloudflare/AWS with atomic ordered deployments and destructive-change review gates; the non-destructive `staticbot/live` branch model; the optional staticbot-mcp server): https://www.staticbot.dev/blog/manage-ai-app-after-migration - Blog - Vibe Coding Tools Comparison: https://www.staticbot.dev/blog/browser-based-vibe-coding-tools-comparison - Blog - Supabase Auth Migration Scope (exactly which tables to migrate and skip): https://www.staticbot.dev/blog/supabase-auth-migration-scope - Blog - Supabase Auth Across Multiple Nuxt Apps (shared Supabase project on subdomains): https://www.staticbot.dev/blog/supabase-auth-multi-nuxt-subdomains - Blog - Lovable TanStack Cloudflare Workers Deployment (how Staticbot deploys Lovable's new SSR default — Workers for Platforms pool, open-source Terraform template, BYO CF account roadmap): https://www.staticbot.dev/blog/lovable-tanstack-cloudflare-workers - Blog (technical companion) - Inside the Cloudflare Workers Deployment — Technical Deep Dive (audience: experienced developers; covers dispatch namespace topology, KV-backed Host routing, the dispatch Worker code, SSL for SaaS / Custom Hostname mechanics, the `cloudflare_workers_kv` + `cloudflare_custom_hostname` Terraform resources, the generated `wrangler.toml` and `wrangler deploy --dispatch-namespace` flow, why CF provider v5 doesn't TF-manage WfP scripts, and how the Nitro `.output/` artifact stays portable to AWS Lambda / Node / Netlify by switching presets): https://www.staticbot.dev/blog/lovable-tanstack-cloudflare-workers-deep-dive - Template - Self-Hosted Supabase: https://www.staticbot.dev/templates/aws-supabase-self-hosting - Template - CloudFront Reverse Proxy: https://www.staticbot.dev/templates/aws-cloudfront-reverse-proxy - Template - S3+CloudFront Top Domain: https://www.staticbot.dev/templates/infrastructure-for-static-website-in-s3cloudfront - Template - S3+CloudFront Subdomain: https://www.staticbot.dev/templates/infrastructure-for-static-website-in-s3cloudfron-subdomain - Template - OpenClaw: https://www.staticbot.dev/templates/openclaw-serverless-hosting - Template - MCP Server: https://www.staticbot.dev/templates/serverless-mcp-implementation - Guide - Back Up Your Lovable Project (Download Schema, Data, Storage, Edge Functions, Auth): https://www.staticbot.dev/guides/backup-lovable-project - Guide - Switch AI Builders (hub: move an app between Lovable and Base44 without a rewrite. The mechanism is that Supabase is the common backend both builders speak — Staticbot lands your app + data on a Supabase you own, so changing builders is a guided one-time move rather than a rebuild. Base44-native apps are made portable via the @staticbot/base44-supabase-shim; auth users migrate with password hashes intact. Switching is a deliberate one-time move, not a reversible daily toggle — the durable benefit is portability / no lock-in. Includes our honest take: we think Supabase + Claude Code or Codex is a better tooling choice if you want more control and not to be locked in an AI builder's walled garden — linked to the post-migration management article): https://www.staticbot.dev/guides/switch-ai-builders - Guide - Switch from Base44 to Lovable (the tractable direction: Base44-native → your own Supabase via the shim → app is standard React + Supabase → continue in Lovable; regenerates a real login page since Base44 hosts sign-in on its side; honest matrix of what moves automatically vs what you re-wire; includes our honest take that Supabase + Claude Code/Codex is the better long-term tooling): https://www.staticbot.dev/guides/switch-ai-builders/base44-to-lovable - Guide - Switch from Lovable to Base44 (migrate your Lovable/Lovable-Cloud backend to a Supabase you own — the backend both builders speak — carrying schema, data, and users with hashes intact, then build in Base44 against your owned backend; includes our honest take that Supabase + Claude Code/Codex gives more control without the walled garden): https://www.staticbot.dev/guides/switch-ai-builders/lovable-to-base44 - Comparison - Lovable vs Base44 (honest side-by-side of the two main supported AI builders: backend, data model, SDK lock-in, auth/hosted-login, custom domains, portability. Both run on a Supabase-shaped backend; the differentiator is how much of your app is yours the day you want out — Lovable = standard React + Supabase repo, Base44 = proprietary @base44/sdk + managed entity layer + Base44-hosted login. Our honest take: Supabase + Claude Code/Codex is a better choice for more control without the walled garden. Ends on: own the Supabase foundation and switching either way is a rewrite-free move): https://www.staticbot.dev/guides/switch-ai-builders/lovable-vs-base44 - Migration Guide - Supabase Managed: https://www.staticbot.dev/migration-guides/supabase-managed - Migration Guide - Self-Hosted Supabase: https://www.staticbot.dev/migration-guides/self-hosted-supabase - Migration Guide - Firebase to Supabase: https://www.staticbot.dev/migration-guides/firebase-supabase - Solutions - Lovable Hosting (keep Lovable as editor, own the backend): https://www.staticbot.dev/solutions/lovable-hosting - Solutions - Supabase Hosting on AWS (self-hosted alternative to Supabase Cloud, no auto-pause): https://www.staticbot.dev/solutions/supabase-hosting - Solutions - Host AI-Built Apps (Lovable, Bolt, v0) on Your Own AWS: https://www.staticbot.dev/solutions/ai-apps - Solutions - AI Builder Migration: https://www.staticbot.dev/solutions/ai-builder-migration - Solutions - Frontend Hosting for Supabase Apps (Staticbot auto-detects whether your project is full-stack/SSR or static/SPA and deploys to the right target: Cloudflare Workers for TanStack Start / Nuxt / SolidStart / Astro, or AWS S3 + CloudFront for Vite SPAs and JAMstack. Managed or bring-your-own cloud account — AWS BYO available today, Cloudflare BYO coming soon. Automatic Supabase env-var injection at build, custom domain via SSL for SaaS, server-only secrets pushed to the runtime secret store on the SSR path): https://www.staticbot.dev/solutions/supabase-frontend - Solutions - Continuous Sync: https://www.staticbot.dev/solutions/continuous-sync - Solutions - Cheap Durable Hosting: https://www.staticbot.dev/solutions/cheap-durable-hosting - Deployment Guide - Deploy Lovable to Vercel (How-To, with Staticbot for the backend migration): https://www.staticbot.dev/deployment-guides/ai-tools/lovable-vercel - Deployment Guide - Migrate Lovable to Supabase + AWS, with ongoing sync (no password resets, password hashes preserved; OAuth identities re-linked; Edge Functions + vault secrets + cron jobs migrated; frontend hosting on your own AWS or Staticbot-managed AWS — free exporters stop at Supabase, Staticbot finishes the job and keeps both backends in sync): https://www.staticbot.dev/deployment-guides/ai-tools/lovable-supabase-migration - Deployment Guide - Migrate Base44 to Supabase + AWS (Base44 is the most tightly-coupled AI builder: a proprietary @base44/sdk, a managed "entities" layer instead of plain Postgres tables, assets on Base44's CDN, and a login page Base44 hosts on its own platform. Staticbot synthesizes Postgres tables from your Base44 entity schemas, swaps @base44/sdk for a Supabase-backed shim so your app code is unchanged, and handles the two things people don't expect: because Base44 keeps password hashes and hosts the sign-in screen, native apps get their users migrated by email with passwordless magic-link/email-code sign-in, plus a real login page regenerated in your own app — so a migrated app authenticates users from day one. Covers both native Base44 apps and apps already wired to their own Supabase. Free while in promo): https://www.staticbot.dev/deployment-guides/ai-tools/base44-supabase-migration - Deployment Guide - Deploy a Supabase Front-end with Staticbot (auto-detect path: imports your repo, finds Supabase env vars and project type, picks Cloudflare Workers for full-stack apps or AWS S3 + CloudFront for static SPAs — both setups support the same Supabase backend; managed or BYO cloud account, customer can override the suggested target): https://www.staticbot.dev/deployment-guides/backend/supabase - Comparison - Staticbot vs Dreamlit (honest side-by-side: both preserve password hashes; Staticbot also migrates Edge Functions, OAuth identities, vault secrets, cron jobs, deploys the frontend to Cloudflare Workers (full-stack apps) or your own AWS (static sites), and keeps it in sync — for users picking between the two tools): https://www.staticbot.dev/staticbot-vs-dreamlit