How to Export a Lovable Project: ZIP, GitHub, and Publish Options

Lovable offers three distinct exit paths and each is useful for a different job. The GitHub integration pushes your source to a repo you control and is the right answer for engineering work, version control, and migrations. The ZIP download packages the same source into a single file and is convenient for offline archival or one-off handoffs. The Publish button hosts the compiled site on the internet under a `lovable.app` subdomain or your custom domain — that path gives you a live site but not source code. Understanding which button does what saves confusion later.

Open your Lovable project, click the GitHub icon in the top-right toolbar, and connect your GitHub account. Choose a target repository (Lovable can create a new one for you) and let the initial push complete. From that moment on, every AI edit inside Lovable creates a commit in the connected repo, and any push you make to that repo shows up inside Lovable's editor. This bi-directional sync is what makes Lovable comfortable for teams that want to keep serious engineering work in their own IDEs while using Lovable for prompt-driven iteration.

The ZIP is a one-shot snapshot of the current project state. Click the download icon and save the archive locally. Unzip and you get a standard Vite + React project you can run with `npm install && npm run dev`. Use this path when you need a static artifact for archival, when you're handing the project to someone who doesn't use GitHub, or when the project is small enough that a single download beats setting up a repo. For migrations to WordPress, GitHub is generally cleaner, but ZIP works fine for smaller projects.

The export is faithful. You get every file Lovable's AI generated: React components in `src/components/`, pages in `src/pages/`, hooks in `src/hooks/`, styles in `src/index.css`, `tailwind.config.ts`, `vite.config.ts`, `package.json` with a complete dependency list, `index.html`, and everything in `public/`. Assets you uploaded through Lovable's UI live in `src/assets/`. Supabase integration code (`src/integrations/supabase/`) is included if you enabled it. Environment variables in `.env` are stripped for security; you re-create them locally as needed.

Requirements are ordinary: Node 18+, npm or pnpm. From the unzipped or cloned directory, run `npm install` then `npm run dev` for the Vite dev server, or `npm run build` to produce the static `dist/` output. Everything Lovable does inside its preview happens on your machine using the same Vite pipeline. If a build works in Lovable, it works locally; if it fails locally, it fails in Lovable for the same reason.

For migrations, either paste the GitHub repo URL into the AI to Wordpress uploader or drop the ZIP. The pipeline installs dependencies, runs `npm run build`, pre-renders every route, and emits a WordPress theme with real HTML per page. Nothing about the export needs modification before the migration — the converter handles Vite, Tailwind, shadcn/ui, and Supabase integration automatically.

If you want a live site fast and don't need source code control, click Publish. If you want to move to another host, own the code, or migrate to WordPress, click Export. There's nothing preventing you from doing both — publish for the demo URL, export for the source. The two paths don't conflict.

Once you've exported, you have three coexisting workflows. Continue prompting inside Lovable and let AI edits flow into the GitHub repo. Edit directly in your own IDE and push changes back — Lovable will see them. Re-run the WordPress conversion whenever the design has meaningfully changed. WordPress content stored in the database survives every theme regeneration, so re-conversions are cheap.

Two things trip people up. First, ZIP downloads timeout on very slow connections for larger projects — use GitHub for anything over a few dozen files. Second, `.env` values are not included in the export; if your Lovable project relied on runtime env vars, you need to re-create them locally in `.env.local` before running the build. Beyond those, exporting is genuinely uneventful — the artifact is a normal Vite project and behaves like one.