Lovable GitHub integration gives you a path from an AI-built project to a normal code workflow. You can keep a copy of the code outside Lovable, review changes, work locally, collaborate with developers, and deploy the application on infrastructure you choose. That is valuable, but it is not the same as pressing an export button and forgetting about the platform boundaries.
The integration has two parts: a workspace connection that authorizes Lovable to work with a GitHub account or organization, and a project link that connects one Lovable project to one repository. Once connected, changes can move in both directions, but there is still an active branch model, repository identity to protect, and a backend whose data and secrets may not be contained in the repository.
This guide explains the workflow from first connection through local development and deployment. It also covers the difference between exporting code and migrating the backend, how to deploy a frontend to Cloudflare Pages, and the decisions to make before you call the project self-hosted. For context on Lovable’s current feature set, see the Lovable review and custom domain guide.
What Lovable GitHub integration does and does not do
When a project is connected, Lovable can create and update a GitHub repository for the project. Changes made in Lovable sync to GitHub, and changes pushed to the active GitHub branch can sync back to Lovable. The current documentation describes this as a one-branch-at-a-time model. That is enough for a useful backup and collaboration workflow, but it is important to know which branch is active before assuming every feature branch will appear in the Lovable editor.
The integration does not require GitHub for building or publishing inside Lovable. If you only need a copy of the code, Lovable also documents a direct codebase download on paid plans. GitHub becomes more valuable when you need pull requests, local edits, automated checks, a deployment pipeline, or a handoff to another developer.
The repository is not automatically a complete copy of your running application. Environment variables, secrets, hosted database data, storage objects, OAuth settings, payment provider configuration, domain records, and external service dashboards live elsewhere. Exporting code gives you the application source. Migration requires inventorying and recreating the services the source code expects.
| Question | What GitHub gives you | What you still need to manage |
|---|---|---|
| Code ownership | A versioned copy of the project source | Secrets, environment files, generated assets, and external services |
| Collaboration | Branches, commits, pull requests, and reviews | A clear source-of-truth policy when Lovable and local developers edit together |
| Deployment | A repository that can trigger CI/CD | Build settings, environment variables, domains, and runtime services |
| Data portability | Schema or migration files when present | Actual database rows, storage files, auth users, and provider-specific configuration |
| Rollback | Historical commits and deploy artifacts | A safe plan for rolling back code without accidentally rolling back or corrupting live data |
Treat GitHub as the source for code history, not as a magical export of every production dependency.
How to connect a Lovable project to GitHub
The connection is easiest when you decide the repository owner and naming convention first. Use an account or organization where the project should live long term. Do not connect a temporary personal repository if you already know the final organization, because repository identity and location are part of the sync relationship.
Workspace owners or admins manage the workspace connection, while project permissions determine who can link a specific project. Lovable’s current flow uses the GitHub app to authorize access, then creates a new repository for the project. Review the requested organization and repository scope during installation instead of granting broad access without checking it.
- Choose the GitHub account or organization: Decide who should own the repository, who needs access, and whether the repository should remain private. Make the choice before connecting the project.
- Add the workspace GitHub connection: Open the GitHub integration from workspace or project settings, authorize the Lovable GitHub app, and select the account or organization where the repository will be created.
- Link the project: Connect the individual Lovable project to its repository. Confirm the new repository name, owner, visibility, and active branch before the first sync.
- Clone and verify the first commit: Clone the repository locally, inspect the package scripts, check for environment variable references, and run the app in a safe development environment before changing code.
Use a source-of-truth workflow before two-way sync gets messy
Two-way sync is powerful because it lets a product owner prompt in Lovable and a developer work in the repository. It is also where ambiguity starts. If one person changes a file in Lovable while another changes the same file locally, the team needs a decision about which change is reviewed, merged, or reapplied. Do not use the integration as a reason to skip normal version-control discipline.
A practical workflow is to keep Lovable focused on scoped product changes, sync them to the active branch, and use GitHub for review, tests, and deployment. For larger work, create a branch in GitHub, implement and test there, merge through a pull request, then switch or sync intentionally in Lovable if the platform needs to continue editing that branch. The exact branch controls can change, so check the current Lovable UI before adopting a team convention.
Keep commits understandable. A commit that says ‘add seller dashboard and rewrite auth and change database policies’ is difficult to review and risky to roll back. Ask for or make one coherent change at a time, run the existing checks, and record any migration or environment-variable requirement in the pull request.
- Pick one active branch for Lovable sync and document it for the team.
- Avoid editing the same files in Lovable and a local IDE at the same time.
- Use pull requests for risky changes, authorization changes, migrations, and payment code.
- Run type checks, linting, tests, and a production build before merging.
- Tag or record known-good deploy commits so a rollback has a clear target.
- Keep generated code reviewable by asking Lovable for scoped changes and a summary of assumptions.
How to deploy exported Lovable code outside Lovable
Once the code is in GitHub, you can connect the repository to a deployment platform that supports the project’s build output. For a static Vite frontend, a platform such as Cloudflare Pages can build from the main branch and publish the generated assets. The exact deployment works only if the application does not require a server runtime that the static host does not provide.
Before switching the public domain, run the build locally with production-like environment variables and test direct navigation to nested routes. Configure redirects or rewrites for the client router, add the required environment variables in the deployment platform, and confirm that API requests point to the intended backend. Use our Vite to Cloudflare Pages guide for the hosting sequence.
A frontend deployment is only one layer. If the app uses Lovable Cloud, Supabase, storage, email, AI features, or payment webhooks, those services still need to remain available or be migrated. It is perfectly valid to host the frontend on Cloudflare Pages while keeping a managed backend elsewhere. ‘Self-hosted frontend’ and ‘fully self-hosted stack’ are not the same thing.
- Inspect the build contract: Read package scripts, identify the output directory, confirm the Node version, and list every environment variable and external endpoint the app expects.
- Deploy a preview first: Connect the repository to your host, deploy a preview or staging branch, and test authentication, API calls, assets, uploads, and direct links before changing DNS.
- Configure the router and domain: Add the host’s SPA fallback or route rules, set the canonical public URL in the app, and connect the domain after the preview behaves correctly.
- Switch production deliberately: Update DNS, verify HTTPS, run smoke tests, inspect logs, and keep the previous deployment available until the new environment has handled real traffic safely.
Lovable Cloud versus self-hosting: make the decision by responsibility
Keeping the app on Lovable Cloud can be the right choice when you want managed hosting, integrated previews, backend services, custom domains, and minimal operational work. It is not a failure to stay managed. The trade-off is that you continue to depend on the platform’s hosting, usage model, regions, and operational controls.
Moving the frontend to another host can give you control over deployment, cache behavior, headers, observability, and cost structure without requiring a backend migration. This is often the lowest-risk portability step. You can keep the Lovable or Supabase backend while deploying the web code from GitHub, then migrate individual services only when there is a concrete reason.
Fully self-hosting is a larger project. Lovable’s documentation describes code and data portability, but it also notes that moving a Cloud project to Supabase is not straightforward in the current product. Inventory the database schema, rows, storage, auth users, edge functions, scheduled jobs, secrets, AI providers, webhooks, email, and operational dashboards before promising a clean move. The code being standard does not mean the migration is automatic.
| Choose this | When it makes sense | Responsibility you accept |
|---|---|---|
| Stay on Lovable hosting | You value managed infrastructure and fast iteration | Platform usage, limits, billing, and provider availability |
| Move only the frontend | You need a different CDN, deploy workflow, or domain setup | Build configuration, environment variables, SPA routing, and frontend observability |
| Keep a managed external backend | You want relational data and auth without operating databases | Provider configuration, migrations, backups, policies, and service costs |
| Fully self-host | You have a strong compliance, control, or infrastructure reason | Updates, security patches, backups, scaling, monitoring, incident response, and migration correctness |
Code export does not export secrets or production data
The most dangerous migration mistake is to see a working local build and assume the production application came with it. The repository may reference environment variables that are absent locally. The database may contain users and orders that are not represented in the code. A storage bucket may hold images that the new domain cannot access. A webhook may still point to the old hostname.
Create an environment inventory before moving anything. Record the variable name, what it controls, where it is configured, whether it is public or private, and how to rotate it. Never commit secret values to GitHub. Public browser configuration and private server credentials should be treated differently, and a client-side variable should never be assumed to be secret.
For database changes, keep migrations versioned and test them against a copy or staging project. A code rollback does not necessarily undo a schema migration or restore deleted data. Pair every risky migration with a backup plan, an expand-and-contract strategy where possible, and a way to confirm the new application works with old and new records.
- List auth providers, redirect URLs, allowed origins, and callback domains.
- List database tables, migrations, functions, triggers, RLS policies, and scheduled jobs.
- List storage buckets, upload rules, image transforms, and public versus private access.
- List payment webhooks, email providers, analytics, error tracking, and AI keys.
- Rotate credentials if they were ever pasted into prompts, committed, or exposed in a build.
- Test the new deployment with a disposable account before pointing production traffic at it.
Common GitHub integration problems and fixes
Most failures come from a mismatch between the team’s mental model and the integration’s actual boundaries. A repository renamed for tidiness can break sync. A commit on a feature branch can appear to be missing when Lovable is following the default branch. A deployment can be green while the app fails because the new host lacks an environment variable or route fallback.
Diagnose one boundary at a time. First confirm the repository path and sync status. Then confirm the branch and latest commit. Then build the code with the new environment. Finally test the backend, domain, and external integrations. Changing all of these at once makes it difficult to tell whether the problem is GitHub, the build, the host, or the application itself.
| Symptom | Likely cause | First check |
|---|---|---|
| Lovable stopped syncing | Repository name, owner, or path changed | Restore the original repository identity and review the sync status |
| A local commit is not visible in Lovable | Commit is on a non-active branch | Confirm the active branch and merge or switch intentionally |
| Deploy succeeds but direct route returns 404 | SPA fallback is missing | Configure the host to serve the app entry for client routes |
| Login works locally but not in production | Redirect URL, cookie, CORS, or environment mismatch | Compare production auth settings and browser network logs |
| App loads without data after migration | Backend URL or public key is missing or wrong | Verify environment variables and the target project |
| Rollback breaks the database | Code and schema changed on different timelines | Restore the compatible application version or apply a forward migration |
A low-risk Lovable to GitHub workflow
For a solo builder, the simplest safe workflow is to connect GitHub once the first app flow is coherent, keep the repository private, and use it as both backup and deployment source. Make small prompts in Lovable, inspect the diff, run the checks locally, and deploy from a known branch. Add a separate staging deployment before real users or payments arrive.
For a team, write down who is allowed to prompt, who reviews code, which branch Lovable follows, and where migrations are approved. Use GitHub issues or pull requests to record assumptions that should not disappear into chat history. If a feature changes authorization, payments, data shape, or external callbacks, make the review requirement explicit.
The best reason to connect Lovable to GitHub is not fear of lock-in. It is a better product workflow: fast natural-language iteration paired with version control, local inspection, tests, deploy previews, and a clear path to change the parts that eventually need deeper engineering.
- Prototype the core flow in Lovable.
- Connect the project to a long-term GitHub owner before production data arrives.
- Create a staging deployment from the repository.
- Use scoped prompts and inspect every meaningful diff.
- Keep backend migrations, secrets, and deployment settings documented outside chat.
- Promote a tested commit to production and keep rollback information visible.
Key takeaways
- Lovable GitHub integration provides a versioned code workflow and two-way sync, not a complete export of every hosted dependency.
- Protect the linked repository name, owner, and path, and document the active branch used by the sync.
- Use GitHub for review, tests, previews, and deployment while keeping Lovable prompts scoped and inspectable.
- A frontend can move to Cloudflare Pages or another host while the managed backend stays where it is.
- Full self-hosting requires a separate inventory and migration plan for data, auth, storage, secrets, webhooks, and operations.
- Code rollback and data rollback are different events. Plan them separately.
Common questions
How do I export a Lovable project to GitHub?
Connect a GitHub account or organization through Lovable’s GitHub integration, then link the project to a repository. Lovable creates and syncs the repository for the project. The exact settings and permissions can change, so check the current GitHub integration flow in Lovable before connecting a production project.
Does Lovable GitHub sync work both ways?
Yes. When the project is linked, changes made in Lovable can sync to GitHub and changes pushed to the active GitHub branch can sync back to Lovable. Lovable currently works with one active branch at a time, so branch selection matters.
Can I import an existing GitHub repository into Lovable?
Lovable’s documented GitHub integration is an export and sync flow from Lovable to GitHub, not a general import flow for starting a Lovable project from an existing repository. Check the current documentation if this product behavior changes.
Can I deploy a Lovable app on Cloudflare Pages?
You can deploy a compatible frontend from the GitHub repository to Cloudflare Pages or another Git-based host. Confirm the build command, output directory, environment variables, client-router fallback, and any server-side requirements before switching production traffic.
Does exporting Lovable code include my database and users?
The code repository is not the same as a full database migration. Hosted rows, auth users, storage files, secrets, webhooks, and provider settings need their own export or recreation process. Inventory those dependencies before moving the app.
Can I self-host a Lovable app?
Yes, you can deploy the code outside Lovable, but the difficulty depends on the backend and services the project uses. Moving only the frontend is usually simpler. Fully self-hosting requires a plan for the database, authentication, storage, secrets, integrations, monitoring, backups, and ongoing operations.
What happens if I rename the GitHub repository linked to Lovable?
Renaming, moving, or deleting the linked repository can break the sync because Lovable relies on the repository identity and path. Restore the original location or follow the current Lovable recovery guidance before making repository changes.