Skip to main content

Buyer guide

Handing a Lovable App to Engineering

How Git sync works, where it stops, and the repository, environment, and review setup that lets engineers or coding agents take over a Lovable app.

Reading time
2 min read
Sources
14 cited
In this piece
3 products

Connect Git sync before a Lovable app gains users, protect the default branch, and split development and production into separate projects. With those in place, engineers or a coding agent can take over the code without breaking the Lovable project.

When you need this

  • A Lovable prototype has been approved for real development.
  • An internal tool now has enough users that engineering must own it.
  • Builders keep hitting problems the agent cannot fix.

Evaluation criteria

  1. Connect Git first

    Where does the code live?

    Look forLink a project to create a private repository on GitHub, GitLab, or Bitbucket. Lovable commits each change and reads commits pushed to the synced branch. It cannot import existing repositories. GitHub Enterprise Server and GitHub data residency require Enterprise.

  2. Agree the branch rules

    How do engineers work alongside builders?

    Look forProtect the default branch so Lovable writes to lovable-sync for pull request review. Lovable edits one branch at a time and starts on the default unless you switch. Branch switching has defaulted on since April 24, 2026. Do not force-push synced commits. Do not rebase or squash them.

  3. Separate environments

    Where do changes get tested?

    Look forUse separate projects when development must not touch production data. Lovable ties backends and secrets to a project, so every branch shares them. Anoop Vijayan, a cloud architect, runs separate dev and prod projects, each with its own repository, database, and secrets, and promotes features by pull request. The developer tomokat cloned the repository and ran Supabase locally so changes stopped touching user data.

  4. Check the framework

    Can the app run somewhere else?

    Look forCheck the app's template before choosing hosting. Apps created since May 13, 2026 use TanStack Start and run server code. Older React and Vite apps use static builds. Vercel, Netlify, and Cloudflare Pages pick the right preset automatically, while object storage alone cannot serve a TanStack Start app. Malik Sohaib Iqbal lost three hours to Vercel 404s before identifying the change. Lovable's firewall shields apps it hosts from CVE-2026-102989, a reflected XSS in TanStack Start disclosed September 30, 2026. Apps hosted elsewhere need @tanstack/react-start 1.168.60 or later and a redeploy.

  5. Decide when the builder stops

    Which problems go to engineering?

    Look forAssign engineering ownership for complex authorization or multi-tenant permissions, regulated data, and tools colleagues depend on. At a 50-person startup, maintaining three coworker-built tools became the cost to manage. Another team moved hosting to its own server and deploys from GitHub, with Codex or Claude making changes.

  6. Review it like any other code

    What does engineering check first?

    Look forReview row-level security and keep secrets server-side. Validate inputs in backend code and add tests. Lovable's own docs say frontend code should never make security decisions. Coding agents such as Claude Code and Cursor work in the synced repository like any other.

Questions to ask vendors

  1. Which branch does Lovable sync to, and is the default branch protected?
  2. Do we need separate dev and prod projects with their own databases and secrets?
  3. Is the app on TanStack Start or the older React and Vite template, and where will it run?
  4. Who approves pull requests that come from the lovable-sync branch?
  5. Once engineering owns the app, do builders keep editing it in Lovable?

Red flags

  • Engineers force-pushing or rebasing the synced branch.
  • One project, database, and set of secrets serving both experiments and live users.
  • Disconnecting the repository, which makes Lovable create a new one on reconnect.
  • Builders and engineers editing the same branch with no agreed owner.

Products in this piece

Sources

Official documentation
9
Public source
5
  1. Lovable blog: TanStack Start vulnerability (CVE-2026-102989)Official documentationlovable.dev
  2. Lovable docs: Sync with GitHub, GitLab, or BitbucketOfficial documentationdocs.lovable.dev
  3. Lovable docs: Sync your Lovable project with GitHubOfficial documentationdocs.lovable.dev
  4. Lovable docs: View and edit your project's codeOfficial documentationdocs.lovable.dev
  5. Lovable docs: Deployment, hosting, and ownership optionsOfficial documentationdocs.lovable.dev
  6. Lovable docs: Deploying and hosting outside LovableOfficial documentationdocs.lovable.dev
  7. Lovable docs: Connect to SupabaseOfficial documentationdocs.lovable.dev
  8. Lovable docs: Security best practices for Lovable appsOfficial documentationdocs.lovable.dev
  9. Lovable docs: ChangelogOfficial documentationdocs.lovable.dev
  10. Anoop Vijayan: From Prototype to Production With Lovable.app (Aug 18, 2026)Public sourcedev.to
  11. tomokat: Setting up a local environment off of a Lovable app (Jul 18, 2025)Public sourcedev.to
  12. Malik Sohaib Iqbal: Debugging a Vercel 404 on a Lovable app (May 13, 2026)Public sourcedev.to
  13. SubstantialTap81 in r/lovable: the upkeep of three internal tools at a 50-person startup (Aug 20, 2026)Public sourcereddit.com
  14. tradematesHQ in r/lovable: moving a Lovable app to the team's own server (Sep 13, 2026)Public sourcereddit.com