In this guide
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.
Note
You own the code Lovable creates, but code ownership and infrastructure portability are different questions. Write down where the database, storage, auth, secrets, and domain currently live before changing providers.
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.
- 1
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.
- 2
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.
- 3
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.
- 4
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.
Watch out
Do not rename, move, or delete the linked repository or change its organization path without checking Lovable's current recovery guidance. The sync depends on the repository identity.
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.
- 1
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.
- 2
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.
- 3
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.
- 4
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.
Tip
Deploy a preview URL before touching DNS. It lets you catch missing environment variables, router fallbacks, CORS rules, and backend assumptions while the existing site remains untouched.
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.
Watch out
A secret inside a frontend bundle is already public. Move privileged calls behind a trusted server-side boundary and rotate any credential that may have been exposed.
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.
Frequently asked questions
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.
