Staticbot logoStaticbot.dev
    Solutions

    Keep building there. Control what goes live here.

    Keep using Lovable or Base44 to try ideas, change the UI, and preview your work. Staticbot builds a separate preview of the updated frontend and checks that it works with your Supabase. Once you’re happy with it, approve the update—or let it go live automatically when the health check passes.

    After migration · every change gets a preview Continuous Sync
    1. 01 · In your builder

      LovableBase44

      Make a change and try it

      Try a new idea or UI change. Review it in Lovable or Base44’s own preview.

      Changes reach Staticbot through your connected repository.
    2. 02 · In Staticbot

      Continuous Sync

      A preview on your new stack

      • Detect what changed. Destructive SQL pauses for your review.
      • Build a working preview of the new frontend.
      • Health-check the preview: it loads, shows no error screens, and talks to your Supabase.
    3. 03 · Before going live

      You choose how it goes live

      Manual approval

      Try the preview, then approve it when you’re happy. Migrated apps start with this setting.

      OR

      Automatic promotion

      Go live automatically once the preview passes its health check. You can turn this on for each project.

    4. 04 · In production

      Your main domain

      Your users get the update at the same address they already use.

      Your Supabase backend.
      Cloudflare or AWS hosting.
      Your familiar domain.
    Checks fail? Promotion waits. Your main domain keeps serving the last promoted version until a healthy preview replaces it.
    Keep building. Each update follows the same steps.

    You don't have to leave Lovable to own your stack

    AI builders are great for shipping fast — but their managed backend is a one-way street. You can't scale past their limits, control your costs, host in your region, or walk away cleanly. Most tools force you to pick: keep the builder, or own the stack.

    Staticbot lets you have both. After the initial migration, your builder remains your creative workspace while your production app runs on your Supabase and Cloudflare or AWS hosting. The builder preview helps you develop the idea; the Staticbot preview lets you review and verify the change on the migrated stack before it reaches your users.

    This holds even for Base44, the most tightly-coupled of the builders — proprietary SDK, a managed entity layer instead of plain tables, a login page hosted on its side. If sync keeps a Base44 app mirrored to a backend you own, the standard Lovable and Bolt setups are the easy case. Migration and continuous sync are the parts of Staticbot we've hardened the most; they're what "keep the builder, own the stack" actually rests on.

    How It Works

    1. Connect your repository

    Link the GitHub repository behind your Lovable / Bolt / Base44 project after the one-time initial migration. Staticbot auto-detects the repository, branch, and Supabase credentials from the migration.

    2. Pushes trigger incremental sync

    A GitHub webhook fires on every push. Staticbot compares the new commit against the last synced version to detect exactly what changed — no full re-scan needed.

    3. Validate changes and build a preview

    Staticbot applies new SQL migrations, edge functions, and storage and auth settings to your Supabase project; destructive SQL pauses for your review first. It then builds a preview of the new frontend against that backend and health-checks it: the page loads, shows no error screens, and its bundle talks to your Supabase rather than the builder's. Try the preview before deciding what reaches your users.

    4. Decide when the update goes live

    Both release options use the preview and its health check. Choose whether a healthy preview waits for your decision or proceeds automatically. Migrated apps start on manual approval; you can switch per project at any time.

    Manual approval

    Open the Staticbot preview, review the checks, and approve promotion when you are happy with the change. A passing check alone does not publish it in this mode.

    Automatic promotion

    Enable automatic promotion to release the preview as soon as it is healthy. An unhealthy preview is not promoted; your main domain keeps serving the last promoted version. Review of destructive SQL still applies.

    The promoted version is served on your main domain. Then return to your builder for the next idea—the same preview, health-check, and promotion cycle repeats for each change.

    What you’re approving: promotion controls the frontend release. Backend changes apply to your Supabase project when the sync runs, so the preview shows the new frontend against your real, already-updated backend. Prefer additive schema changes (add a column before the code that uses it; remove it in a later change) so the version still on your main domain keeps working.

    It doesn't touch your builder

    Sync is non-destructive by design. Staticbot deploys from a dedicated staticbot/live branch, and your AI builder's changes are applied onto it. Lovable, Bolt, and Base44 keep writing to their own branch exactly as before — nothing on the builder side is renamed, rewritten, or disconnected. You can keep shipping in the tool you love while your owned infrastructure tracks along.

    Merging staticbot/live back into the builder's branch is an explicit, opt-in "cut the cord" action — never automatic. Until you choose to do that, the two sides stay cleanly separated: the builder drives development, staticbot/live drives your production deploy.

    What Gets Synced

    Database Migrations

    New SQL files in supabase/migrations/ are applied to your target Supabase project in order when the sync runs — whether it's on supabase.com or self-hosted. Destructive statements pause for your review.

    Edge Functions

    New or modified functions in supabase/functions/ are deployed to your target Supabase project.

    Frontend

    Changes to source code, config files, or dependencies trigger a rebuild into a fresh preview. After approval or automatic promotion it is deployed to your frontend host — Cloudflare Workers for full-stack / SSR apps (TanStack, Nuxt), or AWS S3 + CloudFront for static sites.

    Starting a sync is separate from approving a release

    Choose what starts a sync run. This is separate from the promotion setting: a run can start automatically and still wait for your approval before going live.

    Automatic start

    Every push to your configured branch triggers a sync automatically via GitHub webhook. Rapid pushes are debounced — only the latest commit is synced.

    Manual start

    Start a run with "Trigger Sync" from the project page. It still goes through preview and checks, followed by your chosen promotion mode.

    Sync is optional. Pause it or disconnect anytime — your Supabase and cloud infrastructure (Cloudflare Workers or AWS) is standard and keeps running independently. Cut ties to Lovable or Bolt when you're ready.

    Prerequisites

    • ✓A completed initial migration and verified production setup
    • ✓An active deployment — Cloudflare Workers (full-stack apps) or AWS S3 + CloudFront (static sites), managed or your own account
    • ✓A GitHub repository with your Lovable / Bolt / Base44 project

    Build there. Own it here.

    Keep building in Lovable or Base44. Preview each change, verify it automatically, and choose how it reaches your main domain.