# 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 an existing Lovable or Base44 project once; while enabled, Continuous Sync keeps every push flowing to your infrastructure. Apps built with ChatGPT, Claude, Claude Code or Codex can skip the migration and deploy straight from their repository. Built, migrated, kept in sync only as long as you want — zero lock-in.

Staticbot lets you keep using AI builders (Lovable, Base44) while owning the infrastructure your production app actually runs on. It also deploys apps that never came from a builder — anything built with ChatGPT, Claude, Claude Code or Codex — by assessing the repository, recommending a deployment target, and shipping it. Frontend on Cloudflare Workers (for full-stack apps — TanStack Start, Nuxt, etc.) or AWS S3 + CloudFront (for static sites, your AWS or Staticbot-managed); backend on your own Supabase project or self-hosted Supabase on AWS. The product is a complement to the AI builders, not a replacement: builders keep their users for the build experience, users get to own and scale on their own infra. The workflow is: (1) Initial Migration — a one-time guided pipeline (about 15 minutes) that brings your existing app to your own infrastructure; (2) Optional Continuous Sync — if you want it, every push from your builder's GitHub repo flows automatically to your own Supabase and your hosting (Cloudflare or AWS, whichever fits your project), so your live app always matches what you just built. Continuous Sync is opt-in and not required to use Staticbot. Either way, your infrastructure is standard and keeps running independently — cut ties to your builder anytime.

Vercel-compatible (manual user setup, not automated by Staticbot): the frontend Lovable produces is a standard Vite + React project, so users can deploy it to Vercel themselves while Staticbot handles the backend migration to their own Supabase. A common "escape Lovable Cloud" path is Lovable (editor) + Vercel (frontend, set up by the user) + your own Supabase (backend, migrated by Staticbot). Staticbot does not deploy to Vercel — the user imports the repo into Vercel and adds the new Supabase env vars themselves (a 2-minute step). See https://www.staticbot.dev/deployment-guides/ai-tools/lovable-vercel

Cloudflare Workers (TanStack Start, automated by Staticbot since June 2026): Lovable's default stack for new projects (since May 13, 2026) is full-stack apps with server-side rendering. They need a real runtime, not just a static file CDN. Staticbot hosts them on Cloudflare's global edge network for the customer — no Cloudflare account required on the customer's side. The customer's domain stays at their existing registrar; they add an ALIAS/ANAME at the apex (or CNAME on a subdomain) plus a TXT record to verify domain ownership, and SSL is issued automatically. The per-customer infrastructure code is open source in the public Staticbot templates repo. Bring-your-own Cloudflare account is on the roadmap. Full write-up: https://www.staticbot.dev/blog/lovable-tanstack-cloudflare-workers

- Docs: https://www.staticbot.dev
- Dashboard: https://app.staticbot.dev
- llms.txt: https://www.staticbot.dev/llms.txt

## Homepage

### Build with Lovable. Own your stack.

Staticbot productionises your AI-built app on infrastructure you own: full-stack apps on Cloudflare Workers (Lovable's new TanStack Start default, and any other Worker-target framework — Nuxt, SolidStart, Astro), static sites on AWS S3 + CloudFront, your data on your Supabase. Migrate a Lovable or Base44 project once and Continuous Sync keeps every change flowing to your infrastructure; or point Staticbot at a repository you built with ChatGPT, Claude, Claude Code or Codex and just deploy it. Opt in if you want a living pipeline, skip it if you want a one-shot migration.

### Continuous Sync: build there. Own it here.

Every change you make in Lovable or Base44 flows automatically to your own Supabase and hosting (Cloudflare for full-stack apps, AWS for static sites). No re-migration. No copy-paste. Just keep building.

- **Build where you love** -- Keep using Lovable or Base44 for what they're great at — prompting, prototyping, iterating fast. Nothing changes about how you build.
- **Sync happens automatically** -- Push to GitHub. Staticbot picks up your changes — schema, edge functions, frontend — and applies them to your own infra. No re-runs.
- **Own the infrastructure** -- Your users hit your AWS, your Supabase. Your data, your scale, your costs. No vendor lock-in — at any time you can walk away with everything.

### Step 1 — Initial Migration: bring your backend to your own Supabase

A one-time setup that moves your schema, data, edge functions, storage, and auth from Lovable or Base44 into a Supabase project you own. About 15 minutes. Before you switch production over, Staticbot 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 first — nothing on your live site changes until you choose to merge/switch. Preview is available for both Lovable and Base44 migrations on the managed-Supabase path. After that, continuous sync takes over.

### Deploy your front-end — Cloudflare Workers or AWS, depending on your project

Import your repo, set your domain, click deploy. Staticbot auto-detects what kind of project you have: full-stack apps (TanStack Start — Lovable's new default since May 13, 2026 — Nuxt 3, SolidStart, Astro with the CF adapter) deploy to Cloudflare Workers in a Staticbot-managed Cloudflare account. Classic static sites and SPAs (Vite + React, plain HTML/CSS/JS) deploy to AWS S3 + CloudFront in your AWS account or Staticbot-managed AWS. SSL certificates and CDN configuration are automatic on both paths. Bring-your-own Cloudflare account is on the roadmap.

### The most reliable data migration for AI builders

No CSV exports. No manual table ordering. Staticbot resolves foreign key dependencies, exports every table in the right order, and imports it all into your target -- automatically.

- **Dependency-aware export** -- Tables are exported and imported in topological order based on foreign key relationships. No broken references, no constraint violations.
- **Full fidelity transfer** -- UUIDs, timestamps, JSONB, arrays -- every data type is preserved exactly. Auth users, storage metadata, and RLS policies come along for the ride.
- **One-click, zero config** -- Connect source and target, hit migrate. Staticbot handles schema introspection, data serialization, and chunked inserts -- you just watch the progress bar.

### AI fixes what AI builders break

AI-generated code often ships with incorrect or conflicting SQL migrations. Staticbot detects these issues and suggests fixes -- one click to apply, one click to retry.

- **Conflicting migration files** -- Two migrations both create the same table or column, causing "relation already exists" errors. Fix: AI merges the conflicting statements into a single idempotent migration with IF NOT EXISTS guards.
- **Wrong column types** -- Migration references text but the app expects uuid, or uses varchar where jsonb is needed. Fix: AI reads your app code, detects the mismatch, and generates an ALTER TABLE with the correct type.
- **Missing RLS policies** -- Tables are created with RLS enabled but no policies defined -- locking out all access. Fix: AI analyzes your app's query patterns and generates matching SELECT/INSERT/UPDATE policies.
- **Broken foreign key order** -- Migrations create a child table before the parent, causing constraint violations. Fix: AI reorders the statements so referenced tables are always created first.

### Key features

- **AI Builder Integration** -- Seamlessly integrates with Lovable.dev and other AI builders via GitHub. Connect your repository once and deploy automatically whenever you push changes.
- **Private Repository Support** -- Supports private GitHub repos -- perfect for showcasing nights & weekends projects while maintaining privacy.
- **Effortless Custom Domains & SSL** -- Easily connect your custom domains. Staticbot handles SSL certificate provisioning and renewals via AWS Certificate Manager.
- **Infrastructure Templates** -- Go beyond simple hosting with ready-to-use AWS stacks. Deploy production-ready infrastructure with a single click.
- **Seamless Supabase Integration** -- Deploy front-ends for your Supabase projects with ease. Staticbot automatically detects Supabase environment variables, allowing you to manage your keys through our dashboard.
- **Complete Transparency & No Lock-in** -- Infrastructure code is always available inside your S3 bucket. You can take over development anytime. Download the Terraform code and manage your infrastructure independently.
- **Own Your Infrastructure & Cut Costs** -- Deploy directly to your own AWS account (optional). This eliminates third-party hosting markups and vendor lock-in. You retain full control and only pay for the AWS resources you consume.
- **Automated Supabase Migrations** -- Migrating from Lovable or another AI builder? Staticbot automates the full backend migration -- database schema, edge functions, storage buckets, and auth configuration.

### Currently free for early users

Under current pricing, self-service migrations are free for any project size and include two AI credits. Optional paid offerings include Supported Migration ($199 for human review and troubleshooting on one migration), managed hosting, and additional AI credits.

### FAQ

- **Can I keep using Lovable or Base44 after connecting Staticbot?** -- Yes — that's the whole point. Staticbot doesn't replace the AI builder. You keep building, prompting, and iterating exactly the way you do today. Every change you push from the builder flows automatically to your own Supabase and hosting (Cloudflare for full-stack apps, AWS for static sites) via continuous sync. Staticbot replaces the hosting layer, not the editor.
- **What's the difference between the initial migration and continuous sync?** -- Initial migration is the one-time setup — about 15 minutes — that brings your existing schema, data, edge functions, storage, and auth from Lovable or Base44 into a Supabase project you own. While enabled, Continuous Sync handles every new push: it applies database changes, deploys updated edge functions, and rebuilds your frontend on your own hosting (Cloudflare Workers for full-stack apps, AWS S3 + CloudFront for static sites). No re-migration, no copy-paste, no manual deploys.
- **How is this different from free Lovable → Supabase exporters?** -- Free exporters move your data into a Supabase project once and stop there. They don't host your frontend, they don't deploy to your AWS, and they don't keep things in sync — every new feature you ship in your builder requires re-running the export manually. Staticbot is end-to-end: initial migration, frontend hosting (your AWS or ours), and ongoing Continuous Sync while you keep it enabled. Same outcome on day 1; very different outcome on day 30.
- **Where will Staticbot deploy my website?** -- Depends on the project. Static sites (Vite SPAs, plain HTML/CSS/JS) deploy to AWS S3 + CloudFront -- your own AWS account or Staticbot-managed. SSR apps (Lovable's TanStack Start default since May 13, 2026, or any framework that produces a Worker bundle) deploy to Cloudflare Workers in a Staticbot-managed Cloudflare account, with custom domains via SSL for SaaS so the customer keeps DNS at their existing registrar.
- **Do I need to connect my AWS account?** -- Only if you want to deploy your static site to your own AWS infrastructure. The Staticbot-managed deployment options (AWS for static sites, Cloudflare for full-stack apps) don't require you to connect any cloud account; you only need to point your custom domain.
- **Does Staticbot support full-stack / SSR apps?** -- Yes. Apps that build for Cloudflare Workers (TanStack Start, Nuxt 3 with the CF adapter, SolidStart, Astro with the CF adapter, Hono) deploy to Cloudflare via Staticbot -- SSR, server functions, and edge logic all work. Static-only frameworks (Vite SPAs, plain HTML) deploy to AWS S3 + CloudFront. We auto-detect which kind of project you have.
- **Can I deploy a web app?** -- Yes. Static SPAs (React, Vue, Svelte, Angular) deploy to AWS as a static bundle and connect to your Supabase / Firebase / API backend. SSR / full-stack apps (TanStack Start, Nuxt, SolidStart) deploy to Cloudflare Workers with their server functions intact. Your Supabase backend is always your own.
- **Is it really free?** -- The self-service migration workflow and one hosted site on a Staticbot subdomain are currently free. Optional paid offerings include Supported Migration, managed hosting, and AI credit top-ups. If you deploy a static site to your own AWS account, there is currently no Staticbot fee; you pay for the AWS resources you consume.
- **How does Staticbot work with Supabase?** -- Staticbot automatically detects public environment variables (like NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY) in your repository. You can set these in the Staticbot dashboard, and they will be injected into your built site. This method is designed for public anonymous keys that work with Supabase's Row Level Security.
- **Can I migrate from Lovable Cloud to my own Supabase?** -- Yes — that's the one-time initial migration that sets up the rest. It handles database schema, table data, auth users (including Google/GitHub OAuth identities), edge functions, storage files, secrets, and cron jobs. Your Lovable project is not modified or disconnected. After the initial migration, continuous sync takes over so you don't have to repeat it. See the migration guide at /deployment-guides/ai-tools/lovable-supabase-migration.
- **What happens to my data and credentials during and after migration?** -- During migration, data briefly passes through the Staticbot backend on an ephemeral worker volume only — never written to durable storage (no S3, not in the application database) — and is purged by a background job. Supabase access is via OAuth; disconnecting the integration in Staticbot (Integrations → Manage → Danger Zone → Disconnect) or revoking from Supabase's Authorized Apps invalidates any cached token immediately. For maximum control, the downloadable migration package option keeps Staticbot out of the data path entirely.

### Lovable Migration FAQ

- **Can I start from my current Lovable Cloud project?** -- Yes, that's exactly how it works. You use the same GitHub repository connected to your Lovable Cloud remix. Staticbot accesses it via GitHub OAuth.
- **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. Your Lovable project remains completely unaffected.
- **What gets migrated?** -- Database schema (SQL migration files), table data, auth users, OAuth identities (Google, GitHub), edge functions, storage buckets and files, vault secrets, cron jobs, and auth configuration. Frontend deployment is optional.
- **Does it migrate Google auth / OAuth users?** -- User records and OAuth identities (Google, Apple, GitHub) are migrated automatically, so existing users keep their accounts. The OAuth provider configuration itself (client ID/secret) cannot be migrated — Supabase doesn't expose provider secrets through its Management API. After migration you need to: (1) re-enter the same Client ID and Client Secret in target Supabase → Authentication → Providers, and (2) add `https://<new-target-ref>.supabase.co/auth/v1/callback` to the authorized redirect URIs in Google Cloud Console / Apple Developer. After that, existing users sign in exactly as before.
- **Are secrets migrated?** -- Yes. Staticbot discovers which secrets your project needs, reads them from the source, and sets them on the target. This is best-effort — the migration continues even if some secrets can't be read.
- **Does migration disconnect my Lovable project?** -- No. Staticbot reads from the source but does not modify or disconnect it. Your Lovable project continues to work as before. Even if you update .env variables to point to the new backend, Lovable will automatically revert them.
- **Which GitHub repo should I use?** -- Use the repo connected to Lovable. The automated data migration pushes a temporary edge function that Lovable needs to sync and deploy on the source Supabase instance.
- **Do I need a deploy key or GitHub OAuth?** -- Both work — GitHub OAuth is recommended. Staticbot only accesses repos you explicitly import, never your other repositories. OAuth is the future-proof option: new features work automatically without reconfiguring access. Deploy keys are also supported but need write access (Staticbot pushes a temporary edge function for data export).
- **Where does my data live during the migration? Does Staticbot store it?** -- During the data import phase, table data, storage objects, and secrets pass through the Staticbot backend on an ephemeral worker volume — never in durable storage (no S3, not in the application database) — and are purged by a background job. Supabase access tokens are stored encrypted per organization; once you disconnect the integration or revoke from Supabase, any cached token is invalid. The downloadable migration package option keeps Staticbot out of the data path entirely.
- **How do I disconnect the Supabase integration after migration?** -- In the Staticbot dashboard go to Integrations → Manage next to Supabase → Danger Zone → Disconnect Supabase. (Hard-refresh the Manage page if the Danger Zone doesn't appear immediately.) For an audit trail also revoke "Staticbot" from Supabase → Account → Authorized Apps. Disconnecting does not affect data on your target Supabase project — only Staticbot's ability to reach it.
- **Can I revoke Staticbot access after migration?** -- Yes, if you only need the one-time migration. Your target Supabase project is fully independent afterward. If you want Continuous Sync, Staticbot needs to stay connected to your GitHub repo — but revoking access only stops future syncs, your migrated data and infrastructure remain intact.
- **Can I continue editing in Lovable after migration?** -- Yes, many users do. Staticbot injects the correct target credentials at build time, so it doesn't matter if Lovable reverts environment variables in the repo.
- **Will new changes in Lovable sync to the migrated Supabase?** -- Yes. Continuous Sync monitors your GitHub repo and automatically applies new migration files, edge functions, and backend changes to the target. Flow: Lovable → GitHub → Staticbot → your Supabase. Only syncs code/config, not runtime data.
- **Do I still need Lovable Cloud's Supabase after migration?** -- No. After migration, Lovable Cloud's Supabase is just a development sandbox. The recommended setup: Lovable (editor) → GitHub (source of truth) → Staticbot (sync + deploy) → your Supabase (production backend).
- **Can I keep using Lovable as staging?** -- Yes. Skip Phase 7 (Backend Switchover) and deploy with Staticbot in Phase 8. This overrides env variables at build time without modifying the repository — Lovable's setup remains untouched.
- **Is Continuous Sync free? Any hidden charges or lock-in?** -- Zero lock-in. Under current pricing, self-service migrations and Continuous Sync carry no separate Staticbot fee. Optional paid offerings include Supported Migration, managed hosting, and AI credit top-ups. Your migrated Supabase and AWS infrastructure are standard — if you stop using Staticbot, everything keeps running.
- **Can I disable Continuous Sync without breaking my project?** -- Yes. Pause or disable from the dashboard at any time. Everything already migrated remains untouched. Only automatic updates stop. Re-enabling picks up where it left off.
- **How long does it take?** -- Most migrations complete in 10-20 minutes. There is one manual step: syncing the export function to Lovable (1-2 minutes).
- **What if a step fails?** -- Critical steps pause the migration for investigation. AI troubleshooting analyzes the error and suggests fixes. Non-critical steps (storage, secrets, cron, OAuth identities) are best-effort and never block the pipeline.
- **Can I start over?** -- Yes. Delete the target Supabase project, create a new one, and run the migration again. Under current pricing, the self-service workflow and eligible retries are free.
- **Can I still migrate if my frontend is already hosted on Vercel/Cloudflare/Netlify?** -- Yes. Migration moves the Supabase backend (database, storage, edge functions, auth) regardless of where the frontend lives. Your existing Vercel/Cloudflare/Netlify deployment stays in place and untouched — no need to move hosting. One extra step after migration: update `VITE_SUPABASE_URL` and `VITE_SUPABASE_ANON_KEY` in your hosting provider's project settings to the values from the target Supabase project (Supabase → Project Overview), then trigger a redeploy. Vercel/Cloudflare/Netlify read env vars from their own dashboards, not from the `.env` in your repo, so this step is required for the deployed frontend to talk to the migrated backend.
- **Can I use the migrated Supabase backend with Vercel/Cloudflare instead of Staticbot hosting?** -- Yes, and you'd set them up yourself (Staticbot doesn't deploy to Vercel/Cloudflare automatically). The migrated Supabase backend is standard and works with any frontend hosting provider. Common setup: Lovable (editor) + Vercel (frontend, you wire it in ~2 minutes) + your own Supabase (backend, migrated by Staticbot). Full guide at https://www.staticbot.dev/deployment-guides/ai-tools/lovable-vercel
- **Can I host in an EU region and use different env variables than Lovable?** -- Yes to both. Staticbot deploys to any AWS region, including EU (Frankfurt, Ireland, Paris, Stockholm). The deployed app does not have to share env variables with the Lovable preview — Staticbot injects the target Supabase URL and anon key at build time so the deployed site talks to your own Supabase even if the repo's .env still points at Lovable. Any other env variable can also be overridden per deployment.
- **Are RLS policies migrated?** -- Yes, RLS policies are in your SQL migration files and are applied to the target.
- **Are email templates migrated?** -- Auth redirect URLs and provider settings are migrated. Custom email templates and SMTP configuration need to be set up manually on the target.

---

## Templates

### Infrastructure for Website in S3+CloudFront

AWS infrastructure template for hosting static websites using S3 and CloudFront on a top-level domain.

Tags: S3, Terraform, Infrastructure, AWS, CloudFront, StaticWebsite, Topdomain

**Features:**
- Automated S3 bucket creation and configuration
- CloudFront distribution setup with SSL
- Top-level domain routing and DNS configuration
- Terraform infrastructure as code
- Automatic deployments from GitHub
- Global CDN caching for improved performance

**Use Cases:**
- Corporate websites on main domain
- E-commerce storefronts
- Marketing landing pages
- Documentation portals
- Web applications with global audience

**Requirements:**
- AWS account (optional)
- Top-level domain name (optional)

### Website in S3+CloudFront on Subdomain

AWS infrastructure template for hosting static websites using S3 and CloudFront on a subdomain.

Tags: S3, Terraform, Infrastructure, AWS, CloudFront, StaticWebsite, Subdomain

**Features:**
- Automated S3 bucket creation and configuration
- CloudFront distribution setup with SSL
- Subdomain routing and DNS configuration
- Terraform infrastructure as code
- Automatic deployments from GitHub
- Cost-effective hosting solution

**Use Cases:**
- Personal portfolios and blogs
- Business marketing websites
- Documentation sites
- Static application frontends
- Microsites and campaign pages

**Requirements:**
- AWS account (optional)

### AWS CloudFront Reverse Proxy

Staticbot's managed reverse proxy routes traffic through our infrastructure with automatic SSL, routing, and maintenance.

Tags: CloudFront, AWS, ReverseProxy, CDN, Security, Analytics

GitHub: https://github.com/bitfiction/staticbot/tree/main/infrastructure/_templates/cloudfront_reverse_proxy_template

**Features:**
- CloudFront distribution with custom origin configuration
- Automatic SSL/TLS certificate management
- DDoS protection and security enhancements
- Global CDN caching for improved performance
- Custom cache behaviors and routing rules
- Automatic maintenance and updates

**Use Cases:**
- Route analytics traffic through your own domain to bypass ad blockers
- A reverse proxy sends events to analytics platforms through your own subdomain (like e.yourdomain.com) instead of directly to the platform's domain
- Typically increases event capture by 10-30% depending on your user base

**Requirements:**
- AWS account (optional)
- Ability to add DNS record to your domain

### Full-Stack App on Cloudflare Workers

SSR and server functions at Cloudflare's edge, your custom domain with automatic SSL, and per-app environment variables and secrets. Framework-agnostic: TanStack Start, Nuxt, SolidStart, Astro, or anything that builds to a Worker bundle.

Tags: Cloudflare, Workers, SSR, FullStack, Terraform, Infrastructure, EdgeCompute

**Features:**
- Server-side rendering and server functions on Cloudflare Workers, running at the edge
- Framework-agnostic -- any project that builds to a Worker bundle
- Custom domain with an automatically issued and renewed SSL certificate
- Per-app environment variables, with sensitive secrets stored outside Terraform state
- Infrastructure as code with OpenTofu (Terraform), isolated per app
- Pairs with your own Supabase project for database, auth and storage

**Use Cases:**
- Lovable apps on TanStack Start, which produce a Worker bundle rather than a static site
- Any full-stack app needing SSR or server routes rather than static file hosting
- Apps built with ChatGPT, Claude, Claude Code or Codex that you want deployed without picking a host yourself
- Teams wanting edge performance without operating their own Workers platform

**Requirements:**
- A GitHub repository that builds to a Cloudflare Worker bundle
- Custom domain (optional -- a Staticbot subdomain works too)
- Supabase project for backend features (optional)

### Self-Hosted Supabase on AWS

Deploy a fully self-hosted Supabase stack on your own AWS infrastructure -- PostgreSQL, GoTrue auth, Realtime, Storage, and Edge Functions -- all inside your VPC with full data sovereignty.

Tags: Supabase, AWS, Self-Hosted, PostgreSQL, Terraform, Infrastructure, VPC

GitHub: https://github.com/bitfiction/staticbot/tree/main/infrastructure/_templates/aws_supabase_self_hosting_template

**Features:**
- Full Supabase stack -- PostgreSQL, GoTrue, Realtime, Storage, Edge Functions
- Deployed inside your own AWS VPC with private subnets
- Automatic SSL/TLS certificate management
- Infrastructure as code with OpenTofu (Terraform)
- Data sovereignty -- choose any AWS region
- Automated migration from hosted Supabase via Staticbot

**Use Cases:**
- Enterprise apps requiring data sovereignty and VPC deployment
- Migrating Lovable / AI-generated apps from hosted Supabase to self-hosted
- Regulated industries (healthcare, finance, government) needing full infrastructure ownership
- Teams that want Supabase developer experience with enterprise-grade deployment

**Requirements:**
- AWS account
- Domain name for the Supabase API endpoint (optional)

---

## Blog

### Staticbot Skills for Codex: Deploy, Migrate, and Sync with MCP

Published August 25, 2026; updated August 29, 2026 — 7 min read — audience: developers who want their coding agent to deploy, migrate, or sync through Staticbot

Launch guide for the Staticbot skill collection and MCP server. Explains how `deploy-web-app-with-staticbot`, `migrate-vibe-coded-app`, and `sync-vibe-coded-app` provide goal-specific sequences and approval gates, with either a direct REST fallback or optional typed MCP tools. Covers repository-driven AWS or Cloudflare target selection and infrastructure ownership, manual ChatGPT personal-plugin setup while the public listing is pending, `STATICBOT_API_KEY` handling for coding agents, optional local MCP, and example prompts for each focused workflow. The Codex plugin package source, skills, and MCP implementation live together in the public `staticbot-mcp` repository.

Article URL: https://www.staticbot.dev/blog/staticbot-skill-claude-code-codex

---

### Managing Your AI App After Migration from Base44 / Lovable to Supabase + Staticbot

Published August 2, 2026 — 7 min read — audience: users who have just completed a migration and want to know how to run the app going forward

The post-migration playbook. Once your app is on a Supabase project and a repo you own, you get two ways to keep building — and you can mix them: (1) keep using the AI builder (Lovable, Bolt, Base44) with Continuous Sync flowing every change to the infrastructure you own, or (2) edit the repo directly with Claude Code / Cursor / Codex, because it's standard Supabase and a normal frontend now — no builder credit limits, no black-box backend. Explains why both coexist cleanly: Staticbot deploys production from a dedicated `staticbot/live` branch that changes are applied onto, so the builder branch stays untouched and a Lovable session plus a Claude Code refactor don't step on each other; merging back is an opt-in "cut the cord" move only. Frames Continuous Sync as an **audit trail** — each push is a recorded sync run with a granular diff (new migrations, changed functions, frontend/storage/auth), tracked commit-to-commit, with templates pinned to SHAs and destructive-change review gates. Describes **atomic deployments**: SQL migrations first (in order) → edge functions (in parallel) → frontend rebuild + CDN invalidation on Cloudflare Workers or AWS, so backend and frontend never drift. Notes that the focused Staticbot skills and MCP server are optional ways for an AI agent to trigger syncs, inspect runs, deploy, and run migrations; the dashboard does everything and the infrastructure runs without either. Closes on ownership: pause sync, disconnect the builder, or manage by hand anytime — you're never locked in, including to Staticbot.

Article URL: https://www.staticbot.dev/blog/manage-ai-app-after-migration

---

### Base44 vs Supabase: What Actually Moves When You Migrate (and What Doesn't)

Published June 26, 2026 (updated August 25, 2026) — 10 min read — audience: product owners, vibe coders, and developers considering moving off Base44

Technical, plain-English compatibility guide for moving a Base44 app to your own Supabase. Its public-architecture section explains why native Base44 apps need a compatibility layer and how the MIT-licensed `@staticbot/base44-supabase-shim` preserves common `@base44/sdk` calls while routing entity operations to Postgres/PostgREST, account operations to Supabase Auth, files to Supabase Storage, and supported server work to Edge Functions. The package is public at https://www.npmjs.com/package/@staticbot/base44-supabase-shim and its source is at https://github.com/staticbot/staticbot-base44-supabase-shim. Staticbot pins and vendors the shim into migrated repositories, so builds do not acquire a runtime npm dependency and the browser talks to the customer's Supabase rather than another hosted Staticbot backend. The article explicitly describes the boundary: the shim is not an emulator for every Base44-managed service; hosted agents, payments, image generation, SMS, and specialised document extraction still need a provider or replacement function. It then compares data model, server-side code, login/accounts, and uploads; sorts migration work into automatic, one-time setup, and needs-attention buckets; explains the compatibility review and `00_compatibility_review.md`; covers Base44's hosted-login gap and passwordless transition; and explains the live preview before production switchover. The content intentionally stays at the public contract and architecture level rather than documenting Staticbot's discovery, credential, or rollout internals.

Article URL: https://www.staticbot.dev/blog/base44-supabase-compatibility

---

### Deploying Lovable TanStack Start Apps to Cloudflare Workers

Published June 16, 2026 — 8 min read

Lovable made TanStack Start the default for new projects on May 13, 2026. These are full-stack apps with server-side rendering — they need a real runtime, not just a static file CDN. Staticbot hosts them on Cloudflare's global edge network for the customer: the customer doesn't need a Cloudflare account, doesn't manage any infrastructure, and keeps their domain at whichever registrar they're already using. Custom domain setup is two records the customer copies from the deployment screen into their DNS — an ALIAS/ANAME at the apex (or CNAME on a subdomain) and one TXT record for cert validation. SSL is issued and renewed automatically. The per-customer infrastructure code is open source in the public Staticbot templates repo so customers can read and audit what's provisioned for them. The app code we build is portable — same project deployed on Cloudflare today could move to AWS, Netlify, or a Node server without code rewrites. Current pricing for customers: migrations are free; hosting is $5/mo for two sites or apps, or $15/mo for up to ten, with the first month free for any app you migrate. **Bring-your-own Cloudflare account is on the roadmap.**

Article URL: https://www.staticbot.dev/blog/lovable-tanstack-cloudflare-workers

---

### Inside the Cloudflare Workers Deployment — Technical Deep Dive (companion post)

Published June 16, 2026 — 10 min read — audience: experienced/curious developers

Technical companion to the overview post above. Walks through the actual moving parts of Staticbot's Cloudflare Workers for Platforms deployment for Lovable TanStack Start apps. Topology: one dispatch namespace, one user Worker per customer app, one small dispatch Worker (~50 lines) in front doing KV-backed Host-header routing via a `STATICBOT_ROUTES` KV namespace. Custom hostnames terminate via Cloudflare's SSL for SaaS: TLS SNI lookup against the Custom Hostnames table on our SaaS zone, fallback origin routed back to the dispatch Worker via a Workers Route. Per-customer Terraform (open source) provisions exactly two resources: `cloudflare_workers_kv` for the route entry, and `cloudflare_custom_hostname` with `ssl.method = "txt"` for the DCV-validated DV cert enrollment. Notably absent from TF: the user-Worker bundle — Cloudflare provider v5 doesn't TF-manage WfP scripts, so wrangler owns that path entirely (`wrangler deploy --config <generated.toml> --dispatch-namespace`, then `wrangler secret put` per sensitive env var). Secrets never enter TF state. The `wrangler.generated.toml` is rendered at deploy time from template config + TF outputs (customer's repo-committed `wrangler.jsonc` is ignored). Build artifact is a stock TanStack Start `.output/server/index.mjs` + `.output/public/`. Framework-agnostic via six configurable fields (build_command, build_output_dir, worker_main_path, assets_directory, compatibility_date, compatibility_flags) — same template deploys Nuxt 3 (cloudflare-module preset), SolidStart, Astro (@astrojs/cloudflare, override worker_main_path to dist/_worker.js), bare Hono Workers. Portability: switch Nitro's preset to `aws-lambda` for Lambda + API Gateway + CloudFront, `node-server` for containerized Node, or `netlify` / `vercel` / `deno-deploy` for those targets — application code is unchanged. For Lovable apps specifically, the `@lovable.dev/vite-tanstack-config` wrapper hardcodes the Cloudflare preset; switching means either replacing it with a hand-rolled vite config or waiting for Lovable to expand support.

Article URL: https://www.staticbot.dev/blog/lovable-tanstack-cloudflare-workers-deep-dive

---

### Supabase Auth Migration Scope — Which Tables to Migrate (and Which to Skip)

Published June 4, 2026 — 5 min read

Doing a production Supabase-to-Supabase auth migration? Here's exactly which tables matter and which to leave behind. **Migrate**: `auth.users` (with `encrypted_password` preserved — password hashes stay intact so no user has to reset) and `auth.identities` (required for all sign-in, not just OAuth). **Add if applicable**: `auth.mfa_factors` when TOTP/WebAuthn is enrolled. **Re-enter manually**: OAuth provider client IDs and secrets (Google, GitHub, Apple) — Supabase stores these in its auth control plane, not the database. **Do not touch**: `auth.schema_migrations`, `auth.instances`, `auth.flow_state`, `auth.one_time_tokens`. **Sequence**: restore `auth.users` first, then `auth.identities` (FK dependency), clean any seeded public rows, then restore public data in FK order. The OAuth control-plane gap (provider secrets can't be read via SQL or Management API) catches everyone — plan for it.

Article URL: https://www.staticbot.dev/blog/supabase-auth-migration-scope

---

### Supabase Auth Across Multiple Nuxt Apps on Subdomains (Cloudflare Workers)

Published June 3, 2026 — 9 min read

Split one Nuxt monolith into `app.example.com`, `admin.example.com`, `portal.example.com` — one shared Supabase project, one user base, three Cloudflare Workers apps. The clean pattern: (1) Scope Supabase's session cookie to the parent domain (`Domain=.example.com`) so all subdomains see the same session. (2) Let one app (e.g. `auth.example.com`) own login, callback, OAuth, and password reset — other apps redirect to it. (3) Each Nitro backend verifies the JWT independently on every request — stateless, no coordination needed. (4) Share auth code via a Nuxt layer, not copy-paste. You don't need Supabase's Custom SSO feature — that solves a different problem (SAML/OIDC enterprise IdPs). This pattern works with `@nuxtjs/supabase` and Cloudflare Workers with zero additional infrastructure.

Article URL: https://www.staticbot.dev/blog/supabase-auth-multi-nuxt-subdomains

---

### Lovable vs Bolt vs Supabase: What Hosting Actually Costs After You Outgrow the Free Tier

Published May 7, 2026 -- 9 min read

AI builders bundle frontend hosting, database, and AI assistance into one monthly subscription -- convenient until your app grows. Once you have real traffic, the markup becomes substantial. This article walks through public pricing for Lovable, Bolt, and Supabase as of May 2026, runs the same workload through each stack at two scales (5K MAU and 50K MAU), and documents where the comparison stops being apples-to-apples.

Key numbers (May 2026):

- **Lovable Pro**: $25/mo base + Lovable Cloud usage on top. Includes 100 AI message credits and a custom domain. Cloud is a usage-billed wrapper over Supabase + a CDN.
- **Bolt Pro**: $25/mo for 10M tokens. Heavier users jump to $50/$100/$200 tiers. WebContainer DBs are dev-time only; production needs an external DB.
- **Supabase Pro**: $25/mo. Includes 8 GB Postgres, 100 GB storage, 250 GB egress, 100K MAU, 2M edge function invocations. No AI bundled.
- **AWS CloudFront**: 1 TB/mo egress free under permanent free tier, then $0.085/GB in NA/EU.
- **AWS S3 Standard**: $0.023/GB-month in us-east-1.

Cost comparison at 5K MAU / 10 GB DB / 50 GB storage / 200 GB bandwidth:

- Lovable Pro + Cloud: ~$50-60/mo
- Bolt Pro: $25+/mo (production DB extra)
- Supabase Pro + CloudFront/S3: ~$26/mo

Cost comparison at 50K MAU / 50 GB DB / 500 GB storage / 2 TB bandwidth:

- Lovable Business + Cloud: ~$250-350/mo
- Bolt Pro $200 tier: $300+/mo realistic
- Supabase Pro + CloudFront/S3: ~$152/mo (includes Small compute add-on)

Egress is the dominant variable. Supabase storage egress is $0.09/GB; CloudFront's first 1 TB/month is free and the next 9 TB is $0.085/GB. The AI builder's bundle marks up the same primitives -- same Postgres, similar CDN -- by an order of magnitude in some bands.

Watch-out caveats (where the comparison stops being apples-to-apples):

- Lovable and Bolt's $25 includes AI dev assistance. Migrating off the platform doesn't free you from paying for AI -- you typically substitute Cursor (~$20/mo) or Claude Code. Migration saves on infra, not on AI.
- Supabase Pro covers one project. Staging is a second project. PITR is a $100/mo add-on. Compute beyond Micro starts at $15/mo (Small).
- CloudFront's permanent 1 TB/mo free tier flatters small-scale workloads. Past 1 TB, CloudFront is $0.085/GB in NA/EU.
- Bolt's "unlimited databases" are WebContainer dev DBs, not production Postgres. Production apps still need a real backend.
- After migration you own DNS, certificates, build pipelines, environment variables, and secrets. Not hard, but no longer invisible.

Payments: if your Lovable app accepts payments through Lovable's bundled Stripe integration, the merchant relationship is shared and you're paying a markup over Stripe's standard rate. During migration discovery Staticbot detects Lovable-managed payment integrations and provides a guide for moving checkout, webhooks, and subscriptions to your own Stripe (or other provider) merchant account -- so funds land in your bank and the only fee is what Stripe charges.

Recommendation: stay on the bundle if your app is a prototype, if you genuinely use the AI message credits daily, or if the difference between $25 and $250/mo is irrelevant to your unit economics. Migrate when your bill stops being dominated by AI usage and starts being dominated by hosting -- typically around your first month above 1 TB of egress.

Article URL: https://www.staticbot.dev/blog/ai-builder-hosting-cost-comparison

---

### Migrate Your Lovable Supabase Project via Chat -- Using the Staticbot MCP Server

Published April 25, 2026 -- 4 min read

Run a full Supabase migration from ChatGPT or Claude with hosted OAuth, or from Codex CLI, Claude Code, Cursor, or another skill-capable AI agent using focused Staticbot skills and an API key -- Staticbot handles the rest.

#### What You Need

- A chat or coding agent (ChatGPT, Claude, Codex CLI, Claude Code, Cursor, or another skill-capable tool)
- A Staticbot account for hosted OAuth, or a Staticbot API key for Codex CLI, Claude Code, and optional local stdio (open **API** in the Staticbot menu, or visit https://app.staticbot.dev/developer)
- Your project details: local repo path, Lovable project URL, and target Supabase project URL

#### Step 1: Set Up Staticbot

For ChatGPT, enable Developer mode in **Settings** → **Security and login**, open https://chatgpt.com/plugins, select the plus button, and add the production MCP endpoint:

```
https://mcp.staticbot.dev/mcp
```

Choose User-Defined OAuth Client, set `client_id=staticbot-openai`, token endpoint authentication to `none`, and use PKCE. Authorize your Staticbot account when prompted. For a read-only connection, select only `staticbot:read`; select `staticbot:write` during setup only when you intend to perform changes. No Staticbot API key or local Node process is required.

A hosted connector for Claude chat is not available yet. Claude Code connects with the local MCP server plus an organization-scoped API key, described next.

For Codex CLI and Claude Code, the recommended setup is the focused Staticbot skill collection plus an organization-scoped API key. Create the key at https://app.staticbot.dev/developer, then load it into the terminal that will launch the agent without writing the raw key into shell history:

```sh
printf 'Staticbot API key: '
IFS= read -rs STATICBOT_API_KEY
printf '\n'
export STATICBOT_API_KEY
```

In Codex CLI, paste: `Use $skill-installer to install these four Staticbot skills as personal skills from https://github.com/bitfiction/staticbot-mcp/tree/main/skills: deploy-web-app-with-staticbot, migrate-vibe-coded-app, sync-vibe-coded-app, and staticbot. Do not install or configure the Staticbot MCP server. Confirm the installed paths and list all four installed skills.`

In Claude Code, paste: `Install deploy-web-app-with-staticbot, migrate-vibe-coded-app, sync-vibe-coded-app, and staticbot from https://github.com/bitfiction/staticbot-mcp/tree/main/skills as personal Claude Code skills under ~/.claude/skills. Copy each complete skill directory, including scripts and references. Do not install the Staticbot plugin or configure MCP. Validate with "claude plugin validate ~/.claude/skills" and report the installed paths and result.`

The direct REST fallback means MCP is not required.

For optional local MCP, load the API key with the hidden-input commands above, then run the command for the client.

```sh
codex mcp add staticbot --env STATICBOT_API_KEY="$STATICBOT_API_KEY" -- npx -y @staticbot/mcp
codex mcp get staticbot

claude mcp add --scope user staticbot -e STATICBOT_API_KEY="$STATICBOT_API_KEY" -- npx -y @staticbot/mcp
claude mcp get staticbot
```

The commands save the expanded key in each client's user-level MCP configuration. Never put them in a repository script or paste the key into chat. Package: https://www.npmjs.com/package/@staticbot/mcp. Full docs: https://www.staticbot.dev/platform/mcp-server.

#### Step 2: Paste the Prompt

Open your AI agent's chat and describe the migration, replacing these examples with your actual values:

```
Migrate my Lovable project to my own Supabase.

My repo is https://github.com/username/my-project
My Lovable project ID is abc123-def456

Target Supabase project ref: xyz789
```

That's it. Your AI agent will use the connected Staticbot tools or the skill collection's API fallback to orchestrate the entire migration.

#### What Happens Next

The AI agent calls Staticbot through the hosted tools or the skill collection's API fallback:

1. **Setup** -- Reads your .env to find the source Supabase URL and anon key. Detects the GitHub repo. Creates a template from your repo.
2. **Discovery** -- Inventories your source project -- tables, edge functions, storage buckets, auth providers, migration files. Presents the inventory for your approval.
3. **DB Migration** -- Applies all SQL migration files and enables required extensions on the target.
4. **Data Import** -- Deploys an export edge function, calls it to export your data, and imports it to the target. Also copies storage objects, secrets, cron jobs, and OAuth identities.
5. **Edge Functions** -- Deploys all your edge functions to the target Supabase project.
6. **Auth Config** -- Updates auth configuration -- providers, redirect URLs, site URL.
7. **Backend Switchover** -- Replaces source Supabase env vars in your repo with the target values.
8. **Next Steps** -- Offers continuous sync and frontend deployment options.

**One manual step:** During data import, the AI agent will ask you to open your Lovable project and paste `deploy staticbot edge function` into the Lovable AI chat. This deploys the temporary export function on the source Supabase so Staticbot can read your data.

#### Why use Staticbot from an AI agent?

- **Conversational** -- No need to learn a new UI. Your AI agent explains what's happening at each step and asks for approval when needed.
- **Faster setup** -- The agent reads your .env, finds your integrations, and creates the migration -- no manual form-filling.
- **Smart error handling** -- If a job fails, the agent can retry or skip it. It understands the context and suggests the right action.
- **Works across chat and coding agents** -- Use hosted tools in ChatGPT or Claude, focused skills in Codex CLI or Claude Code, or the optional local MCP package in compatible clients.

---

### Deploy a PostHog Reverse Proxy on AWS CloudFront -- The Easy Way

Published March 26, 2026 -- 7 min read

Ad blockers strip 10-30% of your analytics data. A reverse proxy fixes that by routing PostHog events through your own domain. Here's why it matters, what usually goes wrong, and how Staticbot deploys it for you in minutes.

> This article is for developers and engineering teams using PostHog for product analytics who want more accurate data without maintaining complex cloud infrastructure by hand.

#### The Ad Blocker Problem

Browser ad blockers maintain lists of known analytics domains. When your frontend sends events directly to `eu.i.posthog.com` or `us.i.posthog.com`, a significant chunk of those requests never reach PostHog. They're silently blocked before the browser even makes the connection.

The result: your product analytics are incomplete. Feature flag evaluations don't run. Session recordings have gaps. You're making decisions based on data that systematically excludes a segment of your users.

> PostHog estimates that a reverse proxy increases event capture by 10-30%, depending on your user base.

#### How a Reverse Proxy Fixes It

A reverse proxy sits between your users and PostHog. Instead of sending analytics events to `eu.i.posthog.com`, your frontend sends them to a subdomain you control -- like `e.yourdomain.com`. That subdomain forwards everything to PostHog behind the scenes.

Ad blockers haven't cataloged your domain, so the requests go through. From PostHog's perspective, nothing changes -- it receives the same events, the same way.

- **More Accurate Data** -- Capture events from users running ad blockers. No silent data loss, no blind spots in your analytics.
- **First-Party Traffic** -- Events appear as first-party requests to your own domain. No third-party cookies, no cross-origin complexity.
- **Feature Flags Work** -- Feature flag evaluations, session recordings, and experiments all depend on reliable event delivery.

#### Why AWS CloudFront?

PostHog offers a managed reverse proxy that handles everything for you. But there are reasons you might want your own:

- **Your AWS account, your infrastructure.** The proxy runs in your account. You control the billing, the access policies, the deployment lifecycle.
- **DNS uncloaking resistance.** Some privacy-focused DNS resolvers follow CNAME chains to detect analytics proxies. A CloudFront distribution with your own ACM certificate doesn't have a CNAME chain that resolves to PostHog.
- **Cloudflare Enterprise zone holds.** If you use Cloudflare with zone holds enabled, PostHog's managed proxy can't provision SSL certificates for your domain.
- **Custom cache and CORS policies.** You control the exact cache behavior, origin request headers, and CORS configuration.

#### What Makes CloudFront Setup Hard

PostHog's CloudFront proxy guide walks through a 7-step manual setup. It works, but there are sharp edges:

- **Host header forwarding** -- If your origin request policy forwards all viewer headers, CloudFront sends `Host: yourdomain.com` to PostHog instead of `Host: eu.i.posthog.com`. PostHog returns 404 for every request.
- **Cache policy constraints** -- When you disable caching (TTL=0), CloudFront requires cookie, header, and query string behaviors to be set to "none."
- **CORS with credentials** -- Using `Access-Control-Allow-Headers: *` with `Access-Control-Allow-Credentials: true` violates the CORS spec.
- **ACM certificates and Route53** -- CloudFront requires ACM certificates in `us-east-1` regardless of your distribution's region.
- **Root domain misuse** -- Deploying a reverse proxy on a root domain instead of a subdomain overwrites existing DNS records.

#### How Staticbot Deploys It for You

Staticbot's proxy deployment wizard handles the entire CloudFront setup through a simple form.

1. **Pre-deployment checks** -- Staticbot assumes a cross-account IAM role into your AWS account and checks for existing Route53 hosted zones and ACM certificates. If a wildcard certificate already exists, it reuses it.
2. **Domain validation** -- The wizard prevents you from deploying on a root domain. If you type `example.com`, it tells you to use a subdomain like `e.example.com` instead.
3. **Terraform on your account** -- The deployment runs OpenTofu against your AWS account, creating the CloudFront distribution with both origins, custom cache and origin request policies, CORS headers, and optionally an ACM certificate with DNS validation.
4. **Your infrastructure, fully managed state** -- The Terraform state is stored in an S3 bucket in your account with DynamoDB locking.

#### What Gets Created in Your AWS Account

| Resource | Purpose |
|---|---|
| CloudFront Distribution | Routes API requests and /static/* to PostHog's origins |
| Cache Policy | Disables caching (TTL=0) so events are forwarded in real time |
| Origin Request Policy | Whitelists CORS headers without forwarding Host |
| Response Headers Policy | CORS headers with credentials support |
| ACM Certificate | SSL certificate for your custom domain (us-east-1, DNS-validated) |
| Route53 A Record | Alias record pointing your subdomain to the CloudFront distribution |

#### Updating Your PostHog SDK

Once deployed, point the PostHog SDK to your proxy domain:

```javascript
posthog.init('phc_your_project_token', {
  api_host: 'https://e.yourdomain.com',
  ui_host: 'https://eu.posthog.com'  // or us.posthog.com
})
```

Don't forget to update your Content Security Policy (CSP) headers if your application uses them.

#### Open Source Templates

The Terraform template that powers this deployment is open source:
https://github.com/bitfiction/staticbot/tree/main/infrastructure/_templates/cloudfront_reverse_proxy_template

#### When You Don't Need This

PostHog's managed reverse proxy is free for all Cloud users. The managed proxy is the right choice when:

- You don't use Cloudflare Enterprise with zone holds
- You don't need the proxy infrastructure in your own AWS account
- DNS uncloaking resistance isn't a concern for your user base

### Lovable Apps for Enterprise: From Prototype to Production-Ready

Published March 23, 2026 -- 8 min read

AI-generated apps are great for moving fast. But when enterprise requirements like data sovereignty, network isolation, and full solution ownership enter the picture, you need a path from prototype to production.

> This article is for technical leaders, CTOs, and engineering teams evaluating how AI-built apps -- particularly from Lovable -- can meet enterprise compliance and infrastructure requirements.

#### The Lovable Workflow: Zero to App in Minutes

Lovable lets you describe what you want in plain language and get a working full-stack app back. It generates a React + Vite frontend, connects it to a Supabase backend (auth, database, storage, edge functions), and deploys it -- all from a chat interface.

For prototyping, internal tools, and MVPs, this workflow is transformative. Teams ship in days what used to take weeks.

#### What Enterprise Actually Needs

Enterprise means requirements that go beyond what a managed SaaS platform offers:

- **Data Sovereignty** -- Data must reside in a specific geographic region. EU companies under GDPR, financial institutions under local regulations, government agencies with strict data residency rules.
- **Network Isolation** -- The database and backend services must live inside a private network -- no public endpoints, VPC peering, private subnets.
- **Solution Ownership** -- The organization must own the entire stack -- code, infrastructure, data. No dependency on a third party's platform.
- **VPC Deployment** -- Run everything inside your own AWS account, your own VPC, with your own IAM policies.

#### The Gap: Prototype vs. Production

Lovable's hosted Supabase is excellent for development. But some organizations can't use any shared infrastructure.

| Requirement | Hosted Supabase | Self-Hosted |
|---|---|---|
| SOC 2 / HIPAA | Available | You control |
| Data residency (specific region) | Limited regions | Any region |
| Private network / VPC | Not available | Full control |
| Own encryption keys | Managed by Supabase | Your KMS |
| No vendor dependency | Platform dependency | Fully owned |

#### The Path: Automated Migration and Deployment

Staticbot handles the migration pipeline. It takes a Lovable app connected to hosted Supabase and moves the entire stack to a self-hosted Supabase instance running in your own AWS infrastructure.

The process is fully automated across eight phases:

1. **Discovery** -- Inventory the source Supabase project
2. **Database Migration** -- Apply schema to the target PostgreSQL instance
3. **Data Import** -- Move production data with validation
4. **Edge Functions** -- Deploy Deno edge functions to the self-hosted runtime
5. **Storage Buckets** -- Recreate storage configuration and migrate files
6. **Auth Config** -- Transfer authentication providers, email templates, and settings
7. **Backend Switchover** -- Update environment variables in your GitHub repository
8. **Frontend Deploy** -- Build and deploy the Vite app to your own infrastructure with CDN

#### What You End Up With

After migration, your Lovable app runs entirely on infrastructure you own:

- Self-hosted Supabase (PostgreSQL, GoTrue auth, Realtime, Storage) in your AWS VPC
- Vite frontend deployed to S3 + CloudFront with your custom domain and SSL
- All source code in your GitHub repository
- Infrastructure defined as code (Terraform/OpenTofu)
- No runtime dependency on Lovable, Supabase Cloud, or Staticbot

#### No Vendor Lock-In -- By Design

- **Open-source templates** -- All infrastructure templates are public on GitHub: https://github.com/bitfiction/staticbot/tree/main/infrastructure/_templates
- **IaC in your S3 bucket** -- Every deployment stores its Terraform state and configuration in your own AWS S3 bucket.
- **Standard PostgreSQL** -- Self-hosted Supabase is just PostgreSQL with open-source extensions.

#### Who This Is For

Teams that:
- Built something valuable with Lovable and need to bring it into their enterprise infrastructure
- Must demonstrate data sovereignty and infrastructure ownership for compliance audits
- Want to keep iterating with AI-assisted development while running production on their own terms
- Need their security team to sign off on the deployment before going live

### Browser-Based Vibe Coding Tools: Technical Analysis and Comparison

Published February 6, 2026 -- 12 min read

A comprehensive technical evaluation of modern browser-based coding tools, focusing on custom domain support, deployment capabilities, CDN integration, and migration flexibility.

> This article provides a detailed technical comparison of leading browser-based coding tools. All technical claims are backed by official documentation sources.

#### Introduction

Browser-based coding tools have transformed web development by offering AI-powered assistance, real-time collaboration, and streamlined workflows. This analysis evaluates six major platforms: Replit, Bolt.new, v0, Lovable, Manus, and Base44.

#### Evaluation Criteria

- **Custom Domain Support** -- Ability to use custom domains with proper SSL certificate management and DNS configuration.
- **Deployment Capabilities** -- Workflow complexity, infrastructure provisioning, and production-readiness.
- **CDN Integration** -- Global content delivery network support, caching behavior, and edge distribution.
- **Migration Flexibility** -- Import/export capabilities, vendor lock-in considerations, and code portability.

#### Tool Analysis

**1. Replit** -- Browser-based IDE with AI assistance and real-time collaboration. Custom domains supported natively. Native hosting is production-ready. CDN via external platforms. Code export is straightforward.

**2. Bolt.new** -- By StackBlitz. Generates full-stack apps from AI prompts. Custom domains on paid plans. One-click GitHub export. No native CDN. JavaScript/TypeScript focused.

**3. v0** -- By Vercel. Generates React components from text prompts. Custom domains via Vercel Pro plan. One-click "Push to GitHub" export. Vercel's native CDN with excellent global distribution. React-only.

**4. Lovable** -- Generates websites with Supabase backend integration. Custom domains supported natively. CDN included. Migration from Lovable Cloud to self-hosted Supabase is documented and supported. Provides a rare vendor lock-in escape hatch.

**5. Manus** -- AI Developer generating full-stack applications from prompts. Custom domains supported. Clean GitHub export. CDN included. Easy migration.

**6. Base44** -- AI-powered app development with 2-way GitHub synchronization. Custom domains supported. CDN included. The most tightly-coupled of these builders: a proprietary @base44/sdk, a managed "entities" layer instead of plain database tables, assets on Base44's own CDN, and a login page Base44 serves from its own platform (so a migrated app has no sign-in screen until one is rebuilt). Leaving means translating the app onto a real backend, not just exporting files — automated migration (Staticbot) does that translation; by hand it's substantial.

#### Comparison Summary

| Tool | Custom Domains | Deployment | CDN | Migration |
|---|---|---|---|---|
| Replit | Native & external | Native & external | Native & external | Easy |
| Bolt.new | Native (Paid) | Clean export | No native | Moderate |
| v0 | Native & external | One-click export | Native & external | Easy |
| Lovable | Native & external | Supabase complexity | Native & external | Complex |
| Manus | Native & external | AI Code Gen | Native & external | Easy |
| Base44 | Native & external | 2-way sync | Native & external | Complex — deepest lock-in (proprietary SDK) |

#### Recommendations

- **Rapid Prototyping** -- v0 for UI components, Manus for rapid full-stack development.
- **Team Collaboration** -- Base44 for real-time sync, Replit for simpler collaboration.
- **Full-Stack Applications** -- Lovable for Supabase integration, Bolt.new for AI-generated full-stack apps.
- **Migration Flexibility** -- v0 for clean component exports, Lovable for the Supabase migration path.

---

## Deployment Guides

### Deploy from Lovable with Staticbot

Host your project built with Lovable on AWS S3 + CloudFront (static / SPA Lovable projects) or Cloudflare Workers (full-stack TanStack Start projects — Lovable's default since May 13, 2026) using Staticbot.

**Using a database, edge functions, or auth?** Staticbot deploys your frontend. If your project relies on backend features powered by Lovable Cloud's Supabase, migrate your backend to your own Supabase project first, then come back here to deploy the frontend.

**Steps:**

1. **Push to Git Repository** -- Export to GitHub by linking your GitHub account (OAuth) at https://lovable.dev/settings/git/github, installing the Lovable GitHub App, and connecting your project to a repository. Screenshot of the connection UI: /images/lovable/lovable-github-add-connection.png
2. **Import Your Project's Code** -- Paste your GitHub repo link into Staticbot to create a Template.
3. **Migrate your backend to Supabase** -- If your Lovable app uses Lovable Cloud for a database, edge functions, or auth, move those into your own Supabase project first. Guide: https://www.staticbot.dev/deployment-guides/ai-tools/lovable-supabase-migration
4. **Launch — AWS or Cloudflare, depending on your project** -- Static / SPA projects deploy to AWS S3 + CloudFront (your AWS account or Staticbot-managed). Full-stack / SSR projects (TanStack Start) deploy to Cloudflare Workers in a Staticbot-managed Cloudflare account. Staticbot auto-detects which one applies; the customer can override.
5. **Enter the Domain** -- Staticbot will provide instructions to point the domain to your website.
6. **Deploy** -- Staticbot provisions infrastructure and rolls out your website.

No vendor lock-in. Complete Terraform code is placed in an S3 bucket in your account (AWS path) or in the public templates repo (Cloudflare path).

### Deploy from Bolt with Staticbot

Host your project built with Bolt.new on AWS S3 + CloudFront (static) or Cloudflare Workers (full-stack / SSR) using Staticbot.

**Steps:**

1. **Connect to GitHub** -- Log in to Bolt, click the GitHub icon, authorize StackBlitz.
2. **Import Your Project's Code** -- Paste your GitHub repo link into Staticbot.
3. **Migrate your backend to Supabase** -- If your Bolt app uses a database, auth, or server logic from Bolt's hosted backend, move those into your own Supabase project first. Guide: https://www.staticbot.dev/deployment-guides/ai-tools/bolt-supabase-migration
4. **Launch — AWS or Cloudflare, depending on your project** -- Staticbot auto-detects the project type and chooses the target.
5. **Enter the Domain** -- Configure DNS.
6. **Deploy** -- Staticbot provisions and deploys.

### Deploy from v0 with Staticbot

Host your project built with v0 (Vercel's generative UI tool) on AWS S3 and CloudFront.

**Steps:**

1. **Sync to GitHub** -- Click "Push to GitHub" in the v0 interface.
2. **Import, Launch, Deploy** -- Same Staticbot workflow.

### Deploy from Manus with Staticbot

Host your project built with Manus on AWS S3 and CloudFront.

**Steps:**

1. **Connect GitHub** -- Authorize and export to a new repository.
2. **Import, Launch, Deploy** -- Same Staticbot workflow.

### Deploy from Base44 with Staticbot

Host your project built with Base44 on AWS S3 + CloudFront (static) or Cloudflare Workers (full-stack / SSR) using Staticbot.

**Steps:**

1. **Connect Your App to GitHub** -- Open your app in the Base44 project dashboard, click the GitHub icon in the top panel, authorize Base44 Builder, choose or create a repository. Screenshot of the connection UI: /images/base44/base44-github-add-connection.png
2. **Start Syncing** -- Export your app to GitHub and enable 2-Way Sync so changes in Base44 and GitHub stay aligned.
3. **Import Your Project's Code** -- Paste your GitHub repo link into Staticbot.
4. **Migrate your backend to Supabase** -- If your Base44 app uses a database, authentication, or server logic, move those off Base44's managed backend into your own Supabase project first. Guide: https://www.staticbot.dev/deployment-guides/ai-tools/base44-supabase-migration
5. **Launch — AWS or Cloudflare, depending on your project** -- Staticbot auto-detects the project type and chooses the target.
6. **Enter the Domain** -- Configure DNS.
7. **Deploy** -- Staticbot provisions and deploys.

### Deploy a Supabase Front-end with Staticbot

Staticbot hosts the front-end of your Supabase-powered app on the right target for your project — Cloudflare Workers for full-stack apps, AWS S3 + CloudFront for static SPAs — with automatic env-var detection and custom domain setup.

**How Supabase Integration Works:** Staticbot automatically detects Supabase keys in your project so you can manage them through the dashboard, and figures out the ideal deploy target while it's at it.

**What gets detected automatically when you import your repo:**
- *Supabase env vars* — `SUPABASE_URL`, `SUPABASE_ANON_KEY` and their `VITE_` / `NEXT_PUBLIC_` variants are picked up from the repo so you manage them in the dashboard.
- *Project type → deploy target* — Staticbot inspects your build:
  - **Full-stack / SSR** (TanStack Start, Nuxt 3, SolidStart, Astro with the CF adapter, Hono) → lands on **Cloudflare Workers**, talks to your Supabase from the server runtime (server-only secrets stay server-side).
  - **Static / SPA** (classic Vite + React, JAMstack, plain HTML/CSS/JS) → lands on **AWS S3 + CloudFront**, talks to your Supabase from the browser via the anon key.

Both setups support the exact same Supabase backend — only the hosting layer differs. The customer can override the suggested target if they'd rather pick themselves.

**Steps:**
1. Ensure your app has a `.env` or `.env.example` with Supabase variables (`VITE_SUPABASE_URL`, `VITE_SUPABASE_ANON_KEY`).
2. Import your GitHub repo into Staticbot — env vars and deploy target are detected automatically.
3. Launch (button label is "Launch in AWS" for static / SPA projects, "Launch in Cloudflare" for full-stack) and deploy.

The static path supports anonymous Supabase keys (works with Row Level Security); on the SSR path, server-only env vars including the Service Role key are pushed to Cloudflare's secret store at deploy time — never in source control, never in deployment logs.

### Deploy to Your Own AWS Account

Full control over your infrastructure, compliance, and billing with no markup on AWS costs.

1. **Connect Your AWS Account** -- Grants Staticbot permission to provision resources on your behalf.
2. **Import, Launch, Deploy** -- Same workflow.

**Benefits:**
- Direct AWS billing -- no markup
- Full control -- access S3 and CloudFront directly in your AWS console
- No vendor lock-in -- Terraform code exported to your S3 bucket
- Enterprise grade infrastructure

### Deploy to Staticbot Managed AWS Account

Hands-off experience with no cloud infrastructure management.

1. **Select Your Git Repository** -- Staticbot auto-detects build settings.
2. **Choose "Staticbot Managed Account"** -- Zero-config hosting with a free frever.net subdomain.
3. **Automatic Infrastructure & Rollout** -- S3 + CloudFront provisioned on Staticbot's account.

Includes: Free frever.net subdomain, automatic SSL, global CDN, 99.99% uptime SLA.

---

## Migration Guides

### Migrate Lovable to Supabase + AWS — and Keep Them in Sync

**Migrate Lovable Cloud to your own Supabase without making a single user reset their password.** Lovable's official export path requires triggering a password reset flow for every user (their docs: "you cannot export user passwords, so you need to trigger a password reset flow"). Staticbot migrates auth users with password hashes intact, re-links OAuth identities (Google, GitHub, Apple, …) so no one has to re-authorise, and migrates Edge Functions, vault secrets, and cron jobs alongside the database, storage, and RLS policies. The source Supabase service-role key never leaves your Lovable project — the export runs in-place via a temporary edge function that reads it from Supabase's built-in env vars.

Point Staticbot at your GitHub repo and a target Supabase project — about 15 minutes end to end. Host the frontend on your own AWS account or on Staticbot-managed AWS, and keep editing in Lovable afterward — Staticbot syncs both backends so the migration stays alive. Free exporters (e.g. Dreamlit) move your data to Supabase and stop there; Staticbot finishes the job (Edge Functions, OAuth identities, secrets, frontend hosting) and keeps it alive (continuous sync). For a side-by-side comparison see https://www.staticbot.dev/staticbot-vs-dreamlit. Or follow the 8-step CLI guide below to do it yourself.

#### How do I migrate a Lovable app to Supabase?

**Automated with Staticbot** (Recommended) -- 15 minutes. Schema, data, auth, storage, edge functions, and frontend deploy — all in one dashboard. Frontend lands on your own AWS account or Staticbot-managed AWS (your choice). Ongoing sync keeps both backends current as you continue editing in Lovable.

**Manual Migration** -- Follow 8 CLI steps. ~2-3 hours. No ongoing sync.

#### What Staticbot Automates

- **Project Discovery** -- Automatically inventories your source Supabase project
- **Database Migration** -- Applies your SQL migrations to the target instance
- **Edge Functions** -- Deploys all server-side functions automatically
- **Storage Buckets** -- Recreates your storage bucket configuration
- **Auth Configuration** -- Migrates authentication settings and policies
- **Automated Data Migration** -- Exports and imports your data between projects automatically
- **AI Troubleshooting** -- AI diagnoses failed jobs and suggests fixes you can apply in one click
- **Phase Tracking** -- Real-time status for every step of the migration

#### AI Troubleshooting

When a migration job fails, click the AI button to get an instant diagnosis. The AI analyzes the error, reads your migration files, and suggests a concrete fix -- often a corrected SQL statement you can apply with one click.

#### Manual Migration: 8-Step CLI Guide

**Prerequisites:** New Supabase project created, Supabase CLI installed, Git repo set up.

1. **Update Local Configuration** -- Replace credentials in `.env`, update `supabase/config.toml`, link CLI with `supabase link --project-ref <project-id>`.
2. **Deploy Database Schema** -- `supabase db push`
3. **Deploy Edge Functions** -- `supabase functions deploy`
4. **Configure Supabase Secrets** -- Set ENCRYPTION_SECRET (must be 64-char hex: `openssl rand -hex 32`)
5. **Migrate Data** -- Export each table as CSV from Lovable, import to new Supabase in dependency order
6. **Set Up User Account** -- Create new user via app signup, transfer workspace ownership via SQL
7. **Remove Lovable AI Dependencies** -- Replace Lovable AI Gateway calls with direct provider APIs
8. **Finalize & Deploy** -- Clear cache, commit, push, verify

#### Automated vs Manual Comparison

| Item | Manual equivalent | Automated |
|---|---|---|
| DB schema | supabase db push | Auto |
| Edge functions | supabase functions deploy | Auto |
| Storage buckets | Manual dashboard setup | Auto |
| Auth config | Secrets + policies | Auto |
| Data migration | Manual CSV export/import | Auto |
| Troubleshooting | Manual debugging | AI-powered |

### Migrate from Bolt.new to Supabase

Move your Bolt-generated app's Supabase backend to your own Supabase project.

**How to confirm your Bolt app uses Supabase:**
- Check `package.json` for `@supabase/supabase-js`
- Check `.env` for `SUPABASE_URL` / `SUPABASE_ANON_KEY`
- Check if API URL looks like `https://xxxxx.supabase.co`

**Steps:**

1. **Create Your Own Supabase Project** -- Save URL, anon key, and service role key.
2. **Export the Database** -- Use `supabase db dump` or SQL Editor.
3. **Import the Schema** -- `supabase link` + `supabase db push` or psql import.
4. **Migrate Auth Configuration** -- Recreate OAuth providers, redirect URLs, JWT settings, email templates.
5. **Update Environment Variables** -- Replace Bolt-managed credentials with new project's credentials.
6. **Migrate Storage Buckets** -- Recreate buckets and transfer files.
7. **Verify Row-Level Security** -- Confirm RLS policies are correct.
8. **Redeploy Your App** -- Update env vars in hosting platform and trigger redeploy.

### Migrate from Base44 to Supabase

Extract your Base44 project's auto-generated Supabase schema, RLS policies, auth configuration, and storage buckets.

Note: the manual steps below apply only to Base44 apps **already wired to their own Supabase** (they have a database to dump). **Native Base44 apps** — the common case, using `@base44/sdk` with a managed "entities" layer — have no source Supabase to export and can't be migrated by hand; Base44 also keeps password hashes and hosts the login page on its own platform. For those, use Staticbot's automated pipeline, which synthesizes Postgres tables from your Base44 entity schemas, migrates users by email with passwordless magic-link/email-code sign-in, regenerates a real login page in your app, and stands up a working preview against your own Supabase before anything switches over. Automated guide: https://www.staticbot.dev/deployment-guides/ai-tools/base44-supabase-migration

**Manual steps (Base44-already-on-Supabase only):**

1. **Create Your Own Supabase Project**
2. **Export the Full Database** -- `supabase db dump` for schema + data.
3. **Import into New Project** -- psql or SQL Editor.
4. **Reconfigure Auth Settings** -- Recreate providers, redirect URLs, SMTP, email templates.
5. **Migrate Storage Buckets** -- Recreate and transfer files.
6. **Verify Row-Level Security** -- Check policies and RLS status.
7. **Check Extensions, Triggers, and Edge Functions** -- Verify `uuid-ossp`, `pgcrypto`, `pg_trgm` etc.
8. **Update Your App and Redeploy**

### Migrate to Supabase.com (Managed)

Migrate your Supabase backend from an AI builder to a Supabase.com project you own. Staticbot automates the entire pipeline.

**Workflow:**

1. Create a target Supabase project on supabase.com
2. Connect source and target in Staticbot via OAuth
3. Staticbot runs the 8-phase automated pipeline
4. Track progress in real time

**What gets migrated:** Database schema & data, Edge Functions, Storage buckets & policies, Auth configuration, Backend env var switchover, RLS policies & triggers.

**Why Supabase.com?**
- Managed infrastructure -- PostgreSQL upgrades, backups, and scaling handled for you
- Generous free tier -- two free projects with 500 MB database, 1 GB storage
- Full web dashboard, SQL editor, auth management
- Fastest path to production

### Migrate from Firebase to Supabase

Migrate your application from Firebase (Firestore, Firebase Auth, Firebase Storage, Cloud Functions) to your own Supabase instance -- giving you a relational SQL database, full control over your data, and open-source infrastructure.

#### Choose Your Approach

**Manual Migration** -- Follow 7 steps. ~4-8 hours.

**Automated with Staticbot** (Recommended) -- Staticbot handles the complex technical steps automatically. ~20 minutes. Free.

#### What Staticbot Automates

- **Project Discovery** -- Automatically inventories your Firebase project collections and config
- **Schema Generation** -- Maps Firestore collections to PostgreSQL tables with typed columns
- **Edge Functions** -- Converts Cloud Functions to Supabase Edge Functions automatically
- **Storage Buckets** -- Recreates your Firebase Storage bucket structure in Supabase
- **Auth Migration** -- Migrates Firebase Auth users and custom claims to Supabase Auth
- **Automated Data Migration** -- Exports Firestore documents and imports them into PostgreSQL tables
- **AI Troubleshooting** -- AI diagnoses failed jobs and suggests fixes you can apply in one click
- **Phase Tracking** -- Real-time status for every step of the migration

#### Manual Migration: 7-Step Guide

**Prerequisites:** New Supabase project created (note project ref and service role key), Supabase CLI installed, Firebase CLI installed, Firebase service account JSON key, Node.js 18+ and Python 3.9+.

1. **Auth Migration** -- Export Firebase users (`firebase auth:export users.json`). Batch-insert into `auth.users` via SQL (100 users per INSERT, `ON CONFLICT DO NOTHING` for idempotency). Migrates ALL provider types (email, Google, GitHub, phone, anonymous). Firebase uses SCRYPT hashing -- either require password resets or use a Supabase Auth Hook for a transition period. Preserve provider data in `raw_app_meta_data`. Create `firebase_uid_mapping` table (firebase_uid TEXT → supabase_uuid UUID) for FK updates. Update OAuth redirect URIs to new Supabase callback URL.
2. **Schema Design (NoSQL to SQL)** -- Sample documents to build per-field type profiles. Type mapping: string→TEXT, number→NUMERIC, boolean→BOOLEAN, timestamp→TIMESTAMPTZ, geopoint/map/array→JSONB. Add `firebase_doc_id TEXT` column to every table. Favor JSONB for nested objects (migrate fast, normalize later). Subcollections → separate tables with FK to parent. Create migrations with `supabase migration new` and apply with `supabase db push`.
3. **Data Export / Import** -- Use Firebase Admin SDK to stream collections one at a time (limits memory). Transform Firestore types: top-level Timestamps → ISO strings, nested Timestamps → `{_seconds, _nanoseconds}` in JSONB, GeoPoints → `{latitude, longitude}`, DocumentReferences → path strings. Insert in batches (500 rows) via PostgREST or psql COPY. Import in dependency order (parent tables first). For large collections (100k+ docs), use streaming libraries like `stream-json`.
4. **Storage Migration** -- Create matching Supabase buckets (preserve Firebase bucket names). List blobs in pages (100 at a time), skip folder entries (paths ending with `/`). Upload with `x-upsert: true` header for idempotent re-runs. Set `cache-control: max-age=3600`. URL-encode file paths with special characters. Replace Firebase Storage security rules with Supabase RLS policies on `storage.objects`.
5. **Cloud Functions to Edge Functions** -- Rewrite Cloud Functions as Supabase Edge Functions (Deno). Replace `admin.firestore()` → `supabase.from('table')`, `admin.auth()` → `supabase.auth.admin`, Firestore triggers → database webhooks/pg_net. Deploy with `supabase functions deploy`.
6. **Client SDK Replacement** -- Replace Firebase JS SDK with `@supabase/supabase-js`. Key mappings: `getAuth` → `supabase.auth`, `getDoc/getDocs` → `.select()`, `addDoc/setDoc` → `.insert()/.upsert()`, `onSnapshot` → `.channel().on()`, `getStorage/ref` → `supabase.storage.from()`. Update env vars to `VITE_SUPABASE_URL` and `VITE_SUPABASE_ANON_KEY`.
7. **Frontend Deploy** -- Verify locally with `npm run dev`, build and push, deploy to AWS using Staticbot.

#### Post-Migration Checklist

- Auth flows working (sign up, sign in, OAuth)
- Password reset flow tested for migrated users
- Firebase UID → Supabase UUID mapping verified
- All edge functions deployed
- Database schema migrated
- RLS policies in place
- Critical data imported with firebase_doc_id preserved
- Storage buckets recreated and files migrated
- Foreign keys updated from Firebase UIDs to Supabase UUIDs
- All critical features tested end-to-end

### Migrate to Self-hosted Supabase

Run your own Supabase instance -- full data sovereignty, no recurring platform fees, full customization. Delivered as a downloadable migration package that Claude Code applies to your self-hosted instance (self-hosted Supabase has no Management API, so the import side cannot be fully automated by us).

**Workflow:**

1. Set up your self-hosted Supabase (Docker Compose, Kubernetes, or use Staticbot's AWS template)
2. Run discovery in Staticbot -- connect your source project via OAuth and choose "Self-hosted Supabase" as the target
3. Download the migration package -- AES-256 password-protected zip with ordered SQL, edge function source, storage objects, secrets, auth identities, cron jobs, and a generic CLAUDE.md with apply instructions (password shown on dashboard)
4. Apply with Claude Code -- unzip locally, open the folder in Claude Code, and let Claude follow the manifest (psql for SQL, Supabase CLI for edge functions, REST for storage uploads)

**What's in the package:**
- Database schema and data (ordered SQL dumps)
- Edge functions (source code)
- Storage buckets and objects
- Vault secrets and env vars
- Auth config and OAuth identities
- pg_cron scheduled jobs
- Verification SQL checks

**Currently free**, same as a managed Supabase Cloud migration. Cloud migrations also receive a downloadable package as a portable backup.

**Why self-host?**
- Data sovereignty -- your data stays on your servers in your region
- No platform fees -- pay only for cloud compute
- Full customization -- install any PostgreSQL extension, tune configs
- No vendor lock-in -- Supabase is open source

---

## Solutions

### Host AI-Powered Apps with Staticbot

The rise of AI-powered development tools has made it easier than ever to go from idea to application. Staticbot is the perfect partner for hosting the front-end of your AI-generated applications.

**Why Host Your AI App on Staticbot?**
- **Effortless Deployment** -- Connect your GitHub repository. Staticbot handles the rest.
- **No Vendor Lock-in** -- Full ownership of your infrastructure with Terraform code provided.
- **Cost-Effective** -- Use your own AWS account to bypass hosting markups. Many projects run free under the AWS Free Tier.
- **High Performance** -- Served via AWS S3 and CloudFront for fast load times globally.

**Workflow:**
1. Build with your favorite AI tool (Lovable, Bolt, v0, Manus, Base44)
2. Push to GitHub
3. Deploy with Staticbot

### From AI Builder to Production-Grade Infrastructure

Lovable, Bolt.new, and Base44 are great for shipping fast. But they run your backend on infrastructure you don't own. Staticbot gives you a path to move everything to Supabase and AWS accounts you own.

**The problem with managed AI builders:**
- You don't own the data -- it lives inside the AI builder's Supabase organization
- Pricing scales against you -- managed platforms charge per project, per seat, or per usage tier
- No infrastructure transparency -- you can't audit database configuration or comply with data residency requirements

**The production stack:**
- **Supabase (your backend)** -- Postgres database, Auth, Storage, Edge Functions under your account
- **Frontend (auto-targeted)** -- Cloudflare Workers for full-stack apps (TanStack Start, Nuxt, SolidStart, Astro CF, Hono) or AWS S3 + CloudFront for static / SPA projects. Custom domain + SSL on both paths.
- **Staticbot (orchestration)** -- Connects GitHub to your chosen hosting, orchestrates the Supabase migration, Terraform-managed infra

**What moves, and where:**
- Database schema + data → Your Supabase project
- Auth configuration → Your Supabase Auth
- Storage buckets + files → Your Supabase Storage
- Edge functions → Your Supabase Edge Functions
- Frontend → Cloudflare Workers (full-stack apps) OR AWS S3 + CloudFront (static / SPA) — Staticbot auto-detects

**Supported AI builders:**
- **Lovable to Supabase** -- Fully automated migration
- **Bolt.new to Supabase** -- Fully automated migration
- **Base44 to Supabase** -- Fully automated migration (covers native @base44/sdk apps and apps already wired to their own Supabase; native apps additionally get entity-schema→Postgres-table synthesis, passwordless email sign-in, and a regenerated login page). A live preview runs before switchover.

### Lovable Hosting Without the Lock-in

Lovable is a great AI editor. Lovable Cloud is the bundled hosting that comes with it — and it's the part that auto-pauses idle projects, throttles you onto pricier plans, and keeps your data behind their dashboard. Staticbot hosts what Lovable built, on infrastructure you own, while you keep using Lovable as your editor.

**"Projects in this workspace will be paused after the grace period."** That's a real line from a Lovable Cloud billing email. Lovable Cloud runs on prepaid credits; when they run out, the live app your users depend on gets paused — production, not staging. A common question Lovable users are asking in 2026: "Lovable Cloud is out of credits — is it time to move to Supabase and own my stack?" On infrastructure you own there is no credit meter to run dry: your Supabase project and your AWS / Cloudflare hosting bill on standard, transparent usage, and a lapsed invoice doesn't flip your product to "paused."

Staticbot does not replace Lovable as your editor — it replaces the hosting layer underneath. A Lovable app has three layers: Frontend (Vite + React bundle, portable), Backend (Postgres + auth + storage + edge functions, Supabase), Editor (Lovable itself, unchanged).

**Three Lovable hosting setups:**
1. **Lovable + AWS (CloudFront/S3) + Supabase** — End-to-end via Staticbot. Frontend on your AWS, backend on your Supabase. Cheapest at scale with 1 TB/month free CloudFront tier.
2. **Lovable + Vercel (your setup) + Supabase** — DIY frontend on Vercel (~2 min setup), automated backend migration via Staticbot.
3. **Lovable + fully self-hosted Supabase on AWS** — End-to-end via Staticbot. Maximum ownership, no SaaS dependency for the runtime.

**Why move off Lovable Cloud:** No auto-pause, no credit meter holding your app hostage (run out of credits and Lovable pauses your projects after a grace period), own your data, continuous sync keeps everything in lockstep, drop Lovable any time without losing the app, take payments under your own name via Stripe directly.

### Frontend Hosting for Supabase Apps

You have a Supabase backend (Cloud or self-hosted) and need somewhere to deploy the frontend. Staticbot picks the right target based on your project type, injects your Supabase URL and anon key at build time, and sets up your custom domain.

**Staticbot detects what your project is and recommends the right path.** It reads your repo and suggests the deploy target that fits; you can override the suggestion if you'd prefer:

- **Full-stack / SSR → Cloudflare Workers.** TanStack Start (Lovable's new default since May 13, 2026), Nuxt 3, SolidStart, Astro with the CF adapter, bare Hono Workers. Server-side rendering, server functions, server-only env vars (kept off the client bundle), custom domain via SSL for SaaS — no nameserver migration, customer keeps DNS at their existing registrar — and global edge in 300+ cities.
- **Static / SPA → AWS S3 + CloudFront.** Classic Vite + React SPAs, plain HTML/CSS/JS, JAMstack builds. S3 origin + CloudFront global CDN, build-time injection of public env vars (`VITE_SUPABASE_URL`, anon key), ACM cert, www → apex redirects, permanent 1 TB/mo CloudFront free tier.

**Managed by Staticbot, or in your own cloud account.** Once Staticbot picks the target, you choose who owns the underlying cloud account:

- **Staticbot-managed account** -- Zero setup. Point your domain, click deploy. Available today for AWS *and* Cloudflare.
- **Bring your own cloud account** -- Connect your account; Staticbot orchestrates the deploy with no platform fee. You own the data, the keys, the billing. AWS BYO available today; Cloudflare BYO coming soon.

**How Supabase env vars get into your app:**
- Staticbot auto-detects Supabase env vars from your repo (`SUPABASE_URL` / `SUPABASE_ANON_KEY` and their `VITE_` / `NEXT_PUBLIC_` variants); you manage them in the dashboard.
- *Static / SPA path:* public env vars are baked into the bundle at build time. The Supabase anon key is safe to ship to the browser — Row Level Security is what protects your tables.
- *Full-stack / SSR path:* `VITE_*`-prefixed vars ship to the client; server-only env vars stay server-side and are pushed to Cloudflare's secret store at deploy time — never in source control, never in deployment logs.
- The Supabase service role key is not supported on the static path (no server runtime to keep it secret) — use the full-stack path or move that logic into a Supabase edge function instead.

**Continuous deployment on autopilot.** Connect your GitHub repo once. Every push to your main branch triggers a rebuild and redeploy on whichever target Staticbot picked. If you came from Lovable, Bolt, or Base44, changes you push from the builder flow through automatically — no re-migration, no copy-paste.

### Cheap and Durable Hosting

A durable website hosting solution based on AWS. Preserve your content online indefinitely with the robustness of S3.

**frever.net** -- Free subdomain with Staticbot's managed infrastructure option.

- **Unmatched Durability** -- Built on AWS S3, designed for 99.999999999% durability
- **Ultra-Low Cost** -- Pay only for storage and bandwidth you actually use
- **Zero Maintenance** -- No database to crash, no CMS to patch
- **Version Control** -- Every change is tracked

**Why S3 + Staticbot?**
Link rot and abandoned platforms are erasing our digital history. GeoCities, Google+, MySpace -- when the platform shuts down, your content disappears. Static sites just work.

**Steps:**
1. Create your static site (HTML, CSS, or any static site generator)
2. Optionally use AI tools to generate your site
3. Deploy with Staticbot -- select "Staticbot Managed Account" for a free frever.net subdomain

### Continuous Sync

Keep your target infrastructure up-to-date with Lovable after migrating. Whether you migrated to a managed supabase.com project or a self-hosted instance, Continuous Sync automatically applies incremental changes every time you push. Sync is optional — pause or disconnect anytime; your infrastructure keeps running independently.

**The problem:** After migrating your Lovable app to your own Supabase and hosting (Cloudflare for full-stack apps, AWS for static sites), development continues in Lovable. New database migrations, updated edge functions, frontend changes -- without Continuous Sync you'd need to re-run the migration pipeline or manually apply each change.

**How it works:**
1. **Connect your repository** -- Link your GitHub repo after completing a migration. Staticbot auto-detects the repo, branch, and Supabase credentials from your 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.
3. **Changes are applied automatically** -- SQL migrations (sequentially), edge function deploys (in parallel), then frontend rebuild and CDN invalidation. This ordering makes each sync an atomic, dependency-safe deploy.

**Non-destructive to your builder:** Staticbot deploys production from a dedicated `staticbot/live` branch that the AI builder's changes are applied onto. Lovable / Bolt / Base44 keep writing to their own branch, untouched — so you can also edit the repo directly with Claude Code (or Cursor/Codex) without the two sides conflicting. Merging `staticbot/live` back into the builder branch is an explicit, opt-in "cut the cord" action only, never automatic.

**Audit trail:** Every push produces a recorded sync run describing database, function, frontend, storage, and auth changes. Staticbot records the exact source and target revisions so every deploy can be traced, while destructive migrations pause for review.

**What gets synced:**
- **Database migrations** -- New SQL files in `supabase/migrations/` applied to your target Supabase project in order
- **Edge functions** -- New or modified functions in `supabase/functions/` deployed to your target Supabase
- **Frontend** -- Source code, config, or dependency changes trigger a full rebuild and deploy to AWS S3 + CloudFront

**Sync modes:**
- **Automatic** -- Every push to your configured branch triggers a sync via GitHub webhook. Rapid pushes are debounced.
- **Manual** -- Sync only when you click "Trigger Sync". Full control over when changes hit production.
- **Paused** -- No syncs run until you resume. Cut ties to your builder when ready — your infrastructure keeps running independently.

**Prerequisites:**
- A completed Supabase migration in Staticbot
- A deployed project (active AWS deployment)
- A GitHub repository with your Lovable app's code

### Switch AI Builders (Lovable ↔ Base44)

Move an app between AI builders without rebuilding it. The enabling fact: **Supabase is the common denominator** — both Lovable (Lovable Cloud is a usage-billed wrapper over Supabase) and Base44 run on a Supabase-shaped backend. Staticbot lands your app and its data on a Supabase project you *own*, which turns the builder in front of it into a choice you can change.

**Framing / honesty:** Switching is a guided, one-time move — mostly clicking, ~15 minutes for the backend — **not** a reversible daily toggle. Don't imply users can flip back and forth on a whim; the durable, repeatable benefit is *portability / no lock-in*, not constant switching. The move is non-destructive: the source builder keeps working, untouched, until the user chooses to cut ties. Auth users migrate with password hashes intact and OAuth identities re-linked — no forced password resets.

**Our honest take:** We think Supabase + Claude Code (or Codex) is a better tooling choice if you want more control and don't want to be locked in an AI builder's walled garden. Once your app is on your own Supabase, you can edit it directly with any AI coding tool — no builder middleman, no proprietary SDK, no platform risk. All four switch-ai-builders pages carry this callout, linked to the post-migration management article at `/blog/manage-ai-app-after-migration`.

**Base44 → Lovable (the tractable direction):** Base44-native apps are the hardest to leave (proprietary `@base44/sdk`, a managed "entities" layer instead of plain tables, assets on Base44's CDN, a Base44-hosted login page). Staticbot synthesizes Postgres tables from the Base44 entity schemas, imports data, and installs the `@staticbot/base44-supabase-shim` so the app code runs unchanged against Supabase — yielding a standard React + Supabase project Lovable can adopt. A real login page is regenerated in the user's own app (Base44 hosts sign-in on its side). A compatibility review lists what moves automatically vs. the few bundled features with no Supabase-native equivalent (GenerateImage, SendSMS, OCR) that get wired up.

**Lovable → Base44:** Migrate the Lovable/Lovable-Cloud backend out to a Supabase the user owns (schema, data, RLS, edge functions, storage, secrets, users), then build in Base44 against that owned backend — the same backend shape Base44 apps run on. The frontend is cheap to regenerate; the schema, data, and users are what carry over.

**Pages:** hub at `/guides/switch-ai-builders`, direction spokes at `/guides/switch-ai-builders/base44-to-lovable` and `/guides/switch-ai-builders/lovable-to-base44`, and an honest side-by-side comparison at `/guides/switch-ai-builders/lovable-vs-base44` (backend, data model, SDK lock-in, auth/hosted-login, portability — the differentiator is how portable your code + data are, not the demo).

---

## Platform

### Staticbot REST API

Automate every part of your deployment pipeline. The Staticbot v1 API gives scripts, CI systems, and AI agents programmatic control over migrations, stacks, and deployments.

**Authentication:** Bearer token. Open **API** in the Staticbot menu, or visit https://app.staticbot.dev/developer, then create a key in the **API Keys** section.

```
Authorization: Bearer sk-your-api-key
```

Keys are prefixed with `sk-`, org-scoped, never expire, and can be revoked at any time.

**Base URL:** `https://app.staticbot.dev/api/v1`

**Endpoints:**

Templates:
- `GET /templates` -- List all available templates
- `GET /templates/{id}` -- Get template details

Stacks:
- `GET /stacks` -- List all stacks
- `GET /stacks/{id}` -- Get stack details
- `POST /stacks` -- Create a new stack

Deployments:
- `GET /deployments` -- List all deployments (optional ?stackId= filter)
- `GET /deployments/{id}` -- Get deployment status (includes DNS records when WAITING)
- `POST /deployments` -- Create a deployment (APPLY, PLAN, or DRY_RUN)
- `POST /deployments/{id}/start` -- Start a created deployment

Migrations:
- `GET /migrations` -- List all migrations (optional ?status= filter)
- `GET /migrations/{id}` -- Get migration status and phase breakdown
- `POST /migrations/{id}/confirm` -- Approve after discovery
- `POST /migrations/{id}/resume` -- Resume a paused migration
- `POST /migrations/{id}/pause` -- Pause a running migration
- `GET /migrations/{id}/jobs` -- List all jobs within a migration
- `GET /migrations/{id}/deployments` -- List deployments for a migration's infrastructure
- `POST /migrations/jobs/{jobId}/retry` -- Retry a failed job
- `POST /migrations/jobs/{jobId}/skip` -- Skip a non-critical job

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

**Quick Example -- Deploy a Vite app end-to-end:**

```bash
# 1. Find a template
curl https://app.staticbot.dev/api/v1/templates \
    -H "Authorization: Bearer sk-..."

# 2. Create a stack with your domain
curl -X POST https://app.staticbot.dev/api/v1/stacks \
    -H "Authorization: Bearer sk-..." \
    -d '{"name":"My App","templateId":"...","domainOption":{"type":"CUSTOM_DOMAIN","domainName":"example.com"}}'

# 3. Create and start a deployment
curl -X POST https://app.staticbot.dev/api/v1/deployments \
    -H "Authorization: Bearer sk-..." \
    -d '{"stackId":"..."}'

curl -X POST https://app.staticbot.dev/api/v1/deployments/<id>/start \
    -H "Authorization: Bearer sk-..."

# 4. Poll for status
curl https://app.staticbot.dev/api/v1/deployments/<id> \
    -H "Authorization: Bearer sk-..."
```

### Staticbot Focused Skills and MCP

The public Staticbot repository is packaged as a Codex plugin that combines typed MCP tools with three focused workflows:

- `deploy-web-app-with-staticbot` -- deploys static, SPA, SSR, and full-stack repositories. Staticbot analyzes the repo and returns the workload classification, supported AWS or Cloudflare target, and customer-owned or Staticbot-managed ownership model. The agent reports that selection instead of choosing a provider itself.
- `migrate-vibe-coded-app` -- moves Base44, Lovable, Bolt, or Firebase apps to customer-owned Supabase while preserving discovery, preview, retry/skip, and production-switchover gates.
- `sync-vibe-coded-app` -- operates Continuous Sync with version tracking, failure inspection, and destructive-change review.

The general `staticbot` skill remains as the direct REST API fallback when MCP tools are unavailable. It fetches the live OpenAPI contract, uses a credential-safe curl helper, follows returned `pendingAction` and `failureBanner` fields, and preserves the same production safety rules.

Repository: https://github.com/bitfiction/staticbot-mcp
Skills: https://github.com/bitfiction/staticbot-mcp/tree/main/skills

ChatGPT users can add Staticbot as a personal plugin using `https://mcp.staticbot.dev/mcp`. Codex Desktop can use browser control to guide that setup in the user's signed-in ChatGPT account. Choose User-Defined OAuth Client, set `client_id=staticbot-openai`, token endpoint authentication to `none`, and use PKCE. For a read-only connection, select only `staticbot:read`; select `staticbot:write` during setup only when the user intends to perform changes.

The hosted Staticbot MCP connection is available now in ChatGPT developer mode. The public ChatGPT Plugins Directory listing is pending review, so ChatGPT users add the hosted endpoint manually for now. A hosted connector for Claude chat is not available yet. For Codex CLI and Claude Code, focused skills plus `STATICBOT_API_KEY` are the preferred setup; the local `@staticbot/mcp` package remains optional.

Full setup: https://www.staticbot.dev/platform/mcp-server
Launch guide: https://www.staticbot.dev/blog/staticbot-skill-claude-code-codex

### Staticbot MCP Server

Give ChatGPT, Claude, Codex, Claude Code, and other MCP-compatible AI assistants typed, authenticated Staticbot tools. MCP provides the live action layer; focused skills provide workflow sequences and decision points where the client supports them.

Hosted MCP endpoint: https://mcp.staticbot.dev/mcp

**What is MCP?** The Model Context Protocol is an open standard by Anthropic that lets AI assistants like Claude securely call external tools.

**Choose a setup:**

- Hosted chat users can add Staticbot to ChatGPT or Claude, sign in with OAuth, and work entirely inside the conversation.
- Coding-agent users install the focused Staticbot skills and use an organization-scoped `STATICBOT_API_KEY`. MCP is optional; users who want typed MCP discovery can run the local stdio package with the same key.

**Capabilities:**

The installed server is authoritative for current tool names, descriptions, and schemas. Its typed tools let clients:

- inspect templates, stacks, deployments, and connected integrations
- analyze repositories, report the selected workload, target, and ownership model, and create and monitor website deployments
- migrate Lovable, Bolt, Firebase, and Base44 projects to Supabase targets
- present migration discovery, choice, retry/skip, and destructive-change gates to the user
- build previews and retrieve portable migration packages
- operate Continuous Sync and version-confirmed website rollback

**ChatGPT setup:**

1. Enable Developer mode in ChatGPT under **Settings** → **Security and login**
2. Open https://chatgpt.com/plugins, select the plus button, and enter `https://mcp.staticbot.dev/mcp`
3. Choose User-Defined OAuth Client, set `client_id=staticbot-openai`, token endpoint authentication to `none`, and use PKCE
4. Sign in to Staticbot and approve the selected scopes. For a read-only connection, select only `staticbot:read`; select `staticbot:write` during setup only for intended changes, then select Staticbot from the tools menu in a new chat

This hosted path uses OAuth authorization code + PKCE and does not require an API key or local MCP process.

**Claude setup:**

Claude Code uses the local MCP server plus an organization-scoped API key — see the Codex CLI and
Claude Code setup below. A hosted connector for Claude chat clients that cannot run a local server is
not available yet.

**Codex CLI and Claude Code setup (recommended):**

1. Create an organization-scoped API key at https://app.staticbot.dev/developer
2. Load it into the terminal that will launch the coding agent:

```sh
printf 'Staticbot API key: '
IFS= read -rs STATICBOT_API_KEY
printf '\n'
export STATICBOT_API_KEY
```

3. In Codex CLI, paste: `Use $skill-installer to install these four Staticbot skills as personal skills from https://github.com/bitfiction/staticbot-mcp/tree/main/skills: deploy-web-app-with-staticbot, migrate-vibe-coded-app, sync-vibe-coded-app, and staticbot. Do not install or configure the Staticbot MCP server. Confirm the installed paths and list all four installed skills.`
4. In Claude Code, paste: `Install deploy-web-app-with-staticbot, migrate-vibe-coded-app, sync-vibe-coded-app, and staticbot from https://github.com/bitfiction/staticbot-mcp/tree/main/skills as personal Claude Code skills under ~/.claude/skills. Copy each complete skill directory, including scripts and references. Do not install the Staticbot plugin or configure MCP. Validate with "claude plugin validate ~/.claude/skills" and report the installed paths and result.`

This route uses the direct REST fallback and does not require MCP.

**Local stdio and API-key setup:**

1. Create a key and load it with the hidden-input shell commands above.
2. For Codex CLI:

```sh
codex mcp add staticbot --env STATICBOT_API_KEY="$STATICBOT_API_KEY" -- npx -y @staticbot/mcp
codex mcp get staticbot
```

3. For Claude Code:

```sh
claude mcp add --scope user staticbot -e STATICBOT_API_KEY="$STATICBOT_API_KEY" -- npx -y @staticbot/mcp
claude mcp get staticbot
```

These commands save the expanded key in the client's user-level MCP configuration. Never put them in a repository script or paste the key into chat.

Published package: https://www.npmjs.com/package/@staticbot/mcp

**Why combine MCP with focused skills?**
- Typed tool discovery -- the client receives names, descriptions, and schemas directly
- Broad client support -- one server works in Claude Code, Cursor, Windsurf, and other MCP clients
- Less shell context -- request construction stays behind named tools
- Goal-specific workflow -- skills add deployment, migration, and sync sequences plus explicit decision gates

---

## Why Staticbot

### Build with the AI tools you love. Own the infrastructure underneath.

Combine the speed of Lovable, Bolt, or Base44 with infrastructure you control — and keep them in lockstep, automatically.

- **Build where you love** -- Keep using Lovable, Bolt, or Base44 — and any tool you add later. Prompt, iterate, ship. Nothing changes about how you build.
- **Continuous sync** -- Every change you push flows automatically to your own Supabase and hosting (Cloudflare for full-stack apps, AWS for static sites) — schema, edge functions, frontend. No re-migrating. No manual deploys.
- **Own the stack** -- Your users hit your Supabase, your AWS. Your data, your scale, your costs, your region. Zero vendor lock-in — walk away with everything any time.

### Host in Your Own AWS Account

Unlike other platforms that lock you into their infrastructure, Staticbot allows you to deploy directly to your own AWS S3 buckets and CloudFront distributions. You own the data, the keys, and the billing.

- Complete data sovereignty
- Use your existing AWS credits
- Direct integration with other AWS services

---

## EU Hosting

### Pure EU Hosting for Your Frontend Applications

Deploy your apps to Bunny.net's European infrastructure. Ensure GDPR compliance, low latency for European users, and complete data sovereignty.

- **GDPR Compliance** -- Data stays within the EU. Bunny.net integration ensures static assets are served from European data centers.
- **Ultra-Low Latency** -- Bunny.net's extensive European edge network delivers content with lightning speed to users in London, Frankfurt, Paris, and beyond.
- **Flexible Ownership** -- Deploy to your own Bunny.net account for full control, or use Staticbot's managed account for zero-configuration convenience.

---

## Pricing

### Migrations are currently free. Affordable hosting.

Migrating any AI-builder app (Lovable, Bolt, Base44, v0, Manus) or self-hosted Supabase to a Supabase project you own is free -- any project size, no credit card. If you then choose to run it on our infrastructure, hosting is a few dollars a month (first month free) on a stack you own -- no lock-in, no surprise bills.

### Supabase Migrations

**Self-service migration -- currently $0**
- No current migration-count or project-size limit
- Schema, edge functions, storage buckets, RLS policies
- Auth users with password hashes preserved + OAuth identities re-linked
- Secrets and cron jobs migrated
- 2 AI credits included (AI-assisted troubleshooting and one-click fixes); top-ups $19 for 19 credits, $39 for 99
- Working preview URL before switchover
- No credit card, no size caps

**Supported Migration -- $199 one-time for one migration**
- Everything in the self-service workflow
- Human inspection of failures, reasonable fixes within Staticbot's standard migration scope, and help getting unblocked
- Human assessment of the migration preview before switchover and review of the final handoff
- Email and chat support plus one optional 15-minute consultation
- Account-level and not tied to a migration at checkout; normally consumed when an eligible migration first reaches Completed or Completed with errors after purchase
- A migration completed before purchase does not consume the entitlement merely because it is reopened later
- If Staticbot recommends starting a replacement migration, an operator can keep that replacement supported without another purchase
- An unused purchase expires 12 months after purchase
- First-response target within 12 hours and target resolution of in-scope issues within 48 hours; these are targets rather than guaranteed SLAs, and exclude time waiting on the customer or third parties
- Excludes custom application development, unrelated application bugs, third-party outages, and unsupported sources or destinations

AI-credit packs are separate from Supported Migration. The $19 and $39 packs buy more automated help; Supported Migration buys direct help from the Staticbot team.

### Escape Pass

Migrations are currently free, and buying a pass is not required to migrate today. The Escape Pass is a one-time $199 option for qualifying existing Staticbot users who are not ready to move but want one future Supported Migration prepaid for later.

- Expires 10 years after purchase if it has not been redeemed
- Covers one standard migration using a source and destination Staticbot supports at redemption
- Not tied to a migration or project already in the purchaser's account; the project is chosen later
- Includes the Supported Migration service; it becomes active at redemption and stays active until the migration completes
- Transferable to another Staticbot account when the owner requests it by email
- Does not include custom engineering outside Staticbot's standard supported migration process

The Escape Pass is not generally available for purchase. It prepays one future Supported Migration, which becomes active when the pass is redeemed and stays active until the migration completes. Eligibility is based on real account history and current product use: an account must have previously created or explored a migration, remain on an eligible free setup, and not already use paid hosting or an active Staticbot deployment or Continuous Sync setup. Purchasing requires an active invitation. The public page explains the offer but visiting it or creating an account does not itself establish eligibility. Full explanation: https://www.staticbot.dev/escape-pass

### Special offer: your first month of full-stack app hosting is free

The migration itself is currently free. On top of that, when you deploy a migrated Lovable TanStack app (or any SSR app) to Cloudflare Workers, your first 30 days of full-stack hosting are on us -- custom domain, custom SSL, global edge included. After 30 days, hosting is $5/mo on Hosting Pro -- cancel anytime.

### Hosting plans

### What Staticbot hosts

Four project types, all counting the same against a plan:

- **Static website** -- the build produces a folder of HTML, CSS and JavaScript. Plain HTML, Astro, Hugo, 11ty. Deployed to AWS S3 + CloudFront.
- **Single-page app (SPA)** -- a real application in React, Vue, Svelte or Angular, built with something like Vite. The build still produces plain files, so hosting is identical to a static website, but it runs as an app in the browser. Most Lovable and Base44 projects are SPAs. Deployed to AWS S3 + CloudFront.
- **Server-rendered app (SSR)** -- pages are built on the server for each request, which requires a live runtime rather than a folder of files. TanStack Start, Nuxt 3, SolidStart, Astro with the Cloudflare adapter. Deployed to Cloudflare Workers for Platforms.
- **Full-stack app** -- a server-rendered app that additionally runs the customer's own server-side code (API routes, server functions). Deployed to Cloudflare Workers for Platforms.

Staticbot detects the type from the repository; the customer does not choose a target.

**Staticbot does not host databases.** Database, authentication, file storage and edge functions live in a Supabase project the customer owns and pays Supabase for directly. "Full-stack" means the app can run server-side code on the Cloudflare Worker Staticbot deploys -- it does not mean Staticbot runs a database. This separation is deliberate and is what prevents lock-in: customer data is never in Staticbot's account.

A static website or SPA can still have a full backend without server-side rendering: the app calls Supabase directly from the browser under row-level security, and uses Supabase edge functions for server-side logic. Supabase edge functions are deployed on every plan, including Free.

Plans do not split by project type -- a static website, a single-page app and a server-rendered app all count the same. Tiers differ only by how many are included.

**Free -- $0/month**
- 1 static site or SSR app
- Staticbot subdomain
- 1 GB bandwidth/month
- Continuous Sync, free SSL, global CDN

**Hosting Pro -- $5/month** (checkout: /products/hosting-pro)
- 2 static websites or SSR apps, in any combination
- Custom domains — subdomain (CNAME) and root/apex (ALIAS/ANAME), via SSL for SaaS for apps
- 50 GB bandwidth/month; 20M requests/month for SSR apps, $0.30 per additional million
- Server-side rendering + server functions (TanStack `createServerFn`, Nuxt server routes, etc.)
- Supabase edge functions (Deno) for backend logic
- Free SSL, global CDN, Continuous Sync
- First month free for any app you migrate

**Hosting Scale -- $15/month** (checkout: /products/hosting-scale)
- Up to 10 static websites or SSR apps, in any combination
- Everything in Hosting Pro
- Higher bandwidth and request limits
- Edge key-value and object storage support (coming)

**Own AWS -- $0 Staticbot fee** (static only, today)
- Deploy static sites to your own AWS account
- Unlimited sites & bandwidth (you pay AWS direct)
- Complete data sovereignty
- Bring-your-own Cloudflare account for full-stack apps is on the roadmap

All hosting plans include SSL, global CDN, and automatic deployments from GitHub via Continuous Sync. Custom domains (both CNAME subdomains and ALIAS/ANAME apex domains) are available from Hosting Pro up — the Free tier stays on a Staticbot subdomain. Backend logic can run as Supabase edge functions (Deno) on every tier; framework-native server functions (TanStack `createServerFn`, Nuxt server routes) run on the Cloudflare Worker and are available on every tier, including Free.

### Pricing FAQ

- **Are migrations really free?** -- Yes. The self-service migration workflow is currently free for every supported AI builder and self-hosted Supabase, at any project size, with two AI credits included. Supported Migration is an optional $199 one-time service for human review and troubleshooting on one migration. Managed hosting and additional AI credits are separate purchases.
- **What's the difference between static site hosting and full-stack app hosting?** -- Static (S3 + CloudFront) is for sites where the build produces a folder of HTML/CSS/JS — Vite SPAs, plain HTML, classic JAMstack. Full-stack app hosting (Cloudflare Workers) is for apps that ship a Worker bundle and need SSR, server functions, or edge logic — TanStack Start (Lovable's new default), Nuxt, SolidStart, Astro with the CF adapter. Either way your backend logic can run as Supabase edge functions (Deno), which we deploy on every tier; full-stack app hosting just adds framework-native server functions (TanStack / Nuxt) that run on the Cloudflare Worker itself. One site or app of either type is free; two are $5/mo on Hosting Pro, up to ten are $15/mo on Hosting Scale.
- **Is full-stack app hosting included in the free plan?** -- No. Hosting beyond the free single site or app is paid ($5/mo Hosting Pro, $15/mo Hosting Scale) because each app consumes Cloudflare Workers for Platforms capacity and a Custom Hostname slot. Static site hosting remains free for one site on a Staticbot subdomain, and any app you migrate gets its first month of full-stack hosting free.
- **If migrations are currently free, how does Staticbot make money?** -- Through optional services: $199 Supported Migration for direct help on one migration, managed hosting, and AI credit top-ups. The self-service migration path remains currently free.
- **What's the first-month-of-hosting-free offer?** -- The migration is currently free. On top of that, deploying a migrated SSR app to Cloudflare Workers gets your first 30 days of full-stack hosting free. After that, hosting is $5/mo on Hosting Pro -- cancel anytime.
- **What counts as a migration?** -- One migration = one Supabase project migration including all phases. The full pipeline is currently free, with no current limit on how many migrations you run.
- **What if my migration fails?** -- Inspect the failure, retry or skip eligible jobs, or use an AI credit for automated diagnosis. Two AI credits are included and top-ups are $19/$39. Add Supported Migration if you want the Staticbot team to inspect the failure and help unblock the migration.
- **Can I deploy to my own AWS account for free?** -- Yes -- for static sites. Full-stack app hosting on your own Cloudflare account is on the roadmap.
- **Can I upgrade or cancel hosting later?** -- Yes, at any time. Hosting is month-to-month with no long-term contracts. Migration pricing is separate from your hosting plan, and migrations are currently free.

---

## Custom Domain Guides

### CNAME vs. ANAME/ALIAS Records

**CNAME Record** -- Use for subdomains (e.g., `www.`, `blog.`, `app.`). Points a subdomain to another domain name. Cannot be used for root domains.

**ANAME / ALIAS Record** -- Use for root/apex domains (e.g., `example.com`). Behaves like a CNAME but can be used on the root domain.

**Summary:**
- `www.yourdomain.com` → use CNAME
- `yourdomain.com` (root) → use ANAME/ALIAS
- If your DNS provider doesn't support ANAME/ALIAS, use Cloudflare's "CNAME flattening"

### How to Add a CNAME Record

Guides for common registrars:
- **AWS Route 53** -- Create record in hosted zone, choose CNAME type
- **Bluehost** -- cPanel > Domains > DNS Zone Editor
- **Cloudflare** -- DNS settings > Add Record > CNAME (supports CNAME flattening for root domains)
- **DreamHost** -- Manage Websites > DNS Settings > Add Record
- **GoDaddy** -- Domain Portfolio > DNS Management > Add New Record
- **Google Domains** -- DNS > Custom Resource Records (transitioning to Squarespace)
- **HostGator** -- cPanel > Advanced DNS Zone Editor
- **Hostinger** -- Domains > DNS Zone Editor
- **IONOS** -- Domains & SSL > Manage Subdomains > DNS settings
- **Name.com** -- DNS Records > Add CNAME
- **Namecheap** -- Advanced DNS > Add New Record > CNAME

**General Notes:**
- DNS propagation can take up to 48 hours
- Most registrars don't allow CNAME for root domains
- Remove existing conflicting records before adding a CNAME

### How to Add an ANAME/ALIAS Record

Guides for supported registrars:
- **AWS Route 53** -- Create Alias record pointing to AWS resource
- **Azure DNS** -- Alias record set pointing to Azure resource
- **Constellix** -- Native ANAME records
- **DreamHost** -- ALIAS Record in DNS Settings
- **easyDNS** -- ANAME in CNAME/ALIAS Records
- **Hostinger** -- CNAME ALIAS in DNS zone editor
- **Namecheap** -- ALIAS record in Advanced DNS

**Registrars without native support:** GoDaddy, Bluehost -- use A record with static IP or Cloudflare CNAME flattening.

**ANAME/ALIAS Key Considerations:**
- Can coexist with MX, TXT, and other records
- Automatically update if target hostname's IP changes
- Ideal for root domains pointing to CDNs and cloud platforms
- Not all DNS providers support them

### How to Redirect Your Root Domain to www

When a site is served on the `www` hostname (e.g. the platform issues the TLS cert for `www.example.com` via a CNAME), the bare apex (`example.com`) is pointed at it with a permanent (301) URL redirect set at the registrar. Pattern: remove any conflicting record on the `@` host, then add a 301 URL redirect from the apex to `https://www.yourdomain.com`.

Guides for common registrars (guide: /guides/custom-domain/redirect-apex-to-www):
- **Namecheap** -- Advanced DNS > Add New Record > URL Redirect Record, Host `@`, Permanent (301). HTTP-only on the apex.
- **GoDaddy** -- Domain Settings > Forwarding > Add (Permanent 301, Forward only). HTTPS supported.
- **Cloudflare** -- Rules > Redirect Rules (hostname equals apex -> 301 to www). HTTPS supported; most reliable for an https:// apex.
- **Porkbun** -- Details > URL Forwarding (301). HTTPS supported.
- **Name.com** -- URL Forwarding (301). HTTPS supported.
- **IONOS** -- Adjust Destination > Redirect (Permanent 301). HTTPS supported.
- **Squarespace (Google Domains)** -- Domain Forwarding (301). HTTPS supported.
- **Bluehost / HostGator (cPanel)** -- Domains > Redirects (Permanent 301, "Do Not Redirect www"). HTTPS via AutoSSL.
- **AWS Route 53** -- No native redirect; use an S3 redirect bucket + CloudFront + ACM cert + ALIAS.

**Important — HTTPS on the apex:** many registrar URL forwards answer on HTTP only and can't present a cert for the apex, so `https://example.com` typed directly may fail even though `http://` and `www` work. For an https:// apex redirect, use a provider whose forwarding includes SSL (GoDaddy, Porkbun, IONOS, cPanel) or move DNS to Cloudflare and use a Redirect Rule. Always use 301 (permanent), never masked/frame forwarding.

**On Staticbot (Cloudflare Worker apps):** the app is served on **www** (SaaS custom hostname). For the bare apex to work over HTTPS, use **nameserver delegation** on the deployment page — Staticbot hosts the DNS, auto-creates the apex → www 301 redirect with a valid certificate, and imports existing records (email/MX included). Registrar URL-redirects are not used for Staticbot apex domains (HTTP-only, no apex cert).

### How to Change Your Nameservers (delegate DNS to Staticbot)

Nameserver delegation hands authority over the whole domain's DNS to a new provider — different from adding a single record. For Staticbot-hosted apps it's the cleanest way to connect an apex/root domain when your DNS isn't already on a flattening-capable provider. Staticbot points the domain at a Cloudflare zone it manages, serves the apex with a valid cert + automatic apex→www redirect, and imports existing records (email/MX/TXT) first. The change is made at the registrar (where the domain was bought), not in the old DNS control panel. Guide: /guides/custom-domain/change-nameservers.

**Alternative — bring your own Cloudflare zone (no nameserver change):** if the domain's nameservers already point at your own Cloudflare zone, connect your Cloudflare account to Staticbot (Integrations → Cloudflare, scoped API token) and link it to the domain. Staticbot writes the cert-validation and website records straight into your existing zone, and Cloudflare's CNAME flattening serves the bare apex over HTTPS — you keep control of your zone and existing records. This is powered by the Cloudflare integration (enabled in production).

Pattern per registrar: find the domain's **Nameservers** setting, switch to **custom / "use my own nameservers"**, replace the defaults with the Staticbot values (found on the deployment page's DNS card when the action is "delegate nameservers"), and save.

Guides for common registrars:
- **Namecheap** -- Domain List > Manage > Nameservers > Custom DNS.
- **GoDaddy** -- Domain Settings > DNS > Nameservers > "I'll use my own nameservers".
- **Cloudflare (Registrar)** -- Can't delegate elsewhere (CF Registrar domains must use Cloudflare nameservers); use Staticbot's "Connect/Push to Cloudflare" instead.
- **Porkbun** -- Domain Management > Details > edit Nameservers.
- **Name.com** -- My Domains > domain > Manage Nameservers.
- **IONOS** -- domain > Actions (gear) > Name Server > Use Custom Name Servers.
- **Squarespace (Google Domains)** -- DNS > Domain Nameservers > Use Custom Nameservers.
- **Bluehost** -- Portal > Domains > Nameservers tab > Change Nameservers (set on the domain, not in cPanel).
- **HostGator** -- Customer Portal > Domains > domain > Advanced Tools > Manage "Name servers (DNS)".
- **Hostinger** -- hPanel > Domains > DNS/Nameservers > Change Nameservers.
- **AWS Route 53 (Registrar)** -- Registered domains > Actions > Edit name servers.

**Critical — disable DNSSEC first:** if DNSSEC is enabled at the registrar and you change nameservers, resolvers reject the mismatched signatures and the domain fails with SERVFAIL even though records are correct. Turn DNSSEC off, let it propagate, then switch nameservers.

**Before switching:** let Staticbot import existing records (especially MX/TXT/SPF/DKIM for email) into the managed zone; delegation moves the whole zone at once, so anything missing stops resolving. Propagation can take up to 48 hours. Reversible — point nameservers back anytime.

**Prefer not to move nameservers?** If DNS is already on Cloudflare, use Staticbot's "Connect/Push to Cloudflare" to write records into the existing zone. For a subdomain, a single CNAME record is enough — no delegation needed.

---

## How to Use Staticbot

### Connecting Your AWS Account

To deploy to your own infrastructure, connect your AWS account. This allows Staticbot to provision S3, CloudFront, and SSL resources in your cloud environment.

**Security & Permissions:**
- **Least Privilege** -- Only permissions necessary for S3 and CloudFront
- **Your Cloud, Your Rules** -- Resources in your account with full control
- **Transparent Infrastructure** -- All standard AWS services, no proprietary lock-in

## Migrated with Staticbot (customer gallery)

URL: https://www.staticbot.dev/migrated-with-staticbot

Curated gallery of live production apps that migrated off Lovable Cloud, Base44, and Bolt to their owners' own Supabase, and their frontends to their own AWS or Cloudflare. Manually curated — no user uploads.

Data source: `src/data/migratedProjects.ts` (a typed array). Each entry has: `name`, `url` (live site), `sourceTool` (lovable | base44 | bolt | other), `description` (one-line), `migratedAt` (ISO date), optional `screenshots` (array of `{ url, alt? }` — cards auto-cycle with crossfade while hovered when 2+ are present), optional `hostedOn` (aws | cloudflare | bunny | self-hosted), optional `tags`.

Structured data on page: `CollectionPage` with `ItemList` of `WebSite` items, each carrying `PropertyValue` entries for `migratedFrom` and `hostedOn`. Cards also expose microdata via `itemScope`/`itemProp` (`name`, `url`, `description`, `dateCreated`) as a fallback for scrapers that skip JSON-LD.

Projects listed (name -- source tool -- hosted on -- migrated -- url):
- Sample Lovable SaaS -- Lovable -- Cloudflare -- 2026-06 -- https://example.com
- Sample Base44 Marketplace -- Base44 -- AWS -- 2026-06 -- https://example.com
- Sample Bolt Landing -- Bolt -- AWS -- 2026-05 -- https://example.com

(Sample entries — replace with real customers in `migratedProjects.ts` and re-run the build to update this list.)