Can Lovable Import an Existing GitHub Repo? (2026 Answer)

You already have an app on GitHub. Maybe a Next.js dashboard, maybe a Rails monolith a contractor built two years ago, maybe something you started in another builder and outgrew. You've watched someone describe a change to Lovable in plain English and watched it appear, and you'd like to point that at the repo you actually ship.

It's a fair thing to want. It's also the one thing Lovable doesn't do.

This post covers what the documentation says, the workaround people pass around on Reddit, the point where that workaround stops being worth it, and what the options are when the repository has to stay where it is. Each option is listed with its limitations, not just its pitch.

The short answer is no

Lovable's Git sync documentation puts it in one sentence: "You can't import an existing repository into Lovable. Connecting a project always creates a new repository."

That's the whole answer, and it's the vendor saying it rather than a reviewer guessing. When you connect GitHub or GitLab from the editor, Lovable makes a repository and starts pushing to it. You can rename that repository. You can't redirect the connection at one you already have.

The documented ways to start a project run from a typed prompt to an attached screenshot, a remixed template, a link that carries a prompt, even a project kicked off from ChatGPT. Importing a codebase isn't among them, and its absence is not an oversight.

Be careful which guide you follow

There are well-ranked tutorials that walk you through "New Project, then Import from GitHub", complete with a list of prerequisites for your repository.

That button doesn't exist. Worth saying plainly, before anyone spends an afternoon looking for it. Before you follow any tutorial on this, open the vendor's own docs and check the feature is real, because this particular query has attracted a lot of content written by people who never tried it.

The copy trick, and where it runs out

The workaround that does work shows up on r/lovable regularly:

1. Create a blank Lovable project and let it generate its own repository.
2. Push or copy your existing code into that new repository.
3. Go back to Lovable and wait for it to rebuild the preview. If it stalls, edit the readme to nudge it.
4. Ask it to read the codebase before you ask it to change anything.

People have had this work, usually on small Vite projects. It's clever and it's free, so try it if your app is simple.

Two things to weigh before you do. The first is that you're adopting a new repository, not connecting your old one, so your commit history, issues, branch protection rules, CI configuration and anything wired to deploy from the original are all still pointing at a repo Lovable isn't watching. For a side project that's nothing. For a product with a release process it's a migration, and migrations have a habit of being discovered by the person on call.

The second is the stack. Lovable's own comparison guide is direct about the boundary: you build in React, TypeScript and Tailwind, with no Vue and no Svelte, and the output is web or PWA rather than native. Copying files in doesn't move that boundary. If your app is a Django service, a Laravel site, a Rails monolith, an Angular admin panel or a pnpm workspace with four packages in it, the copy trick puts code in front of an agent that isn't built to edit that code.

What to use instead

Four tools that can work on a repository you already have. Each entry lists what it costs you, because all four cost something.

Refinar

Best for: a non-developer changing an app that already exists, with a developer reviewing the result.

Connects to a repository you already own, then clones, installs and boots it in a sandbox, so the preview is the running app rather than a regenerated approximation of it. Work happens on a branch named after the session and arrives as a draft pull request for someone to review. Stack coverage is the point of difference from the copy trick: Next, Vite, Astro, Nuxt, Angular, Create React App, Node servers, Deno, Laravel, Symfony, Django, Flask, FastAPI, Rails, Rack, Go, Rust and static sites each get their own adapter, and monorepos are resolved rather than rejected.

The preview runs against real infrastructure rather than mocks. Environment variables and service credentials are held per project and delivered into the sandbox, and connectors cover Supabase, Neon, PlanetScale, Turso, Upstash, MongoDB Atlas, Convex, Firebase, Stripe, Resend, Twilio and around thirty more, so the app talks to the database and the services it actually uses.

Guardrails are what make that safe to hand to a non-technical person. Every file change is reversible through checkpoints, and the commands that aren't reversible, a migration against a live database being the obvious one, are blocked outright rather than left to the model's judgement. Connected services stay read-only until somebody approves a write. When the agent hits one of those walls it stops instead of improvising, and the escalation can be filed as an assigned GitHub issue, so the risky half of a request becomes a developer's ticket rather than an incident.

The caveats are narrow. Services are reached over HTTPS, which covers the serverless drivers those providers ship, but a client that opens a raw Postgres socket, the default in node-postgres, Drizzle and Prisma, won't connect from a preview. The pull request stays a draft until a person publishes it.

Cursor or Claude Code

Best for: an engineer making the change themselves.

The strongest option for an existing codebase, and the right answer whenever the person making the change writes code. They read the repo where it lives, respect what's already there and ask for no migration at all.

The cost is the audience. Both assume an engineer, a terminal and a working local environment. A product manager is not going to use them, which is the whole reason this question keeps getting asked.

Bolt

Best for: JavaScript experiments that boot in a browser.

It imports repositories, which already puts it ahead of Lovable for this job, and the in-browser environment makes it quick to try.

The cost is what fits. Projects run through WebContainers, so the app has to be the sort of app that boots there, and the backend side is Node and Express. No Python, no Go, no PHP. That rules out a lot of production stacks before you start.

Replit

Best for: a cloud workspace with real runtime flexibility.

It imports into a proper cloud environment with support for Python, Go and Node alike, which is more runtime range than anything else in this list.

The cost is that importing isn't a read-only act. Replit writes its own .replit and replit.nix into the project so the Run button works, the second of those being a Nix shell that pins the system packages your app runs against, and two-way Git sync carries them back. A repository that carried nothing platform-specific now carries Replit's runtime configuration.

The agent is active during import rather than passive, and that has cost older reports worth dating. In 2025 a founder reported that importing disabled the creative agent and left something closer to Copilot, which then began rewriting his Node backend in Python unprompted, and a community thread from the same period has users posting defensive instructions telling it not to touch authentication or database architecture. Replit has shipped several agent generations since, so read those as history. Import a throwaway copy first regardless.

Which should you pick

If you have a repository and the person making changes doesn't write code, that's the gap this whole post describes. Refinar is built for it, and ten minutes is enough to find out whether a given stack boots.

If the person making changes writes code, use Cursor or Claude Code.

If you want a browser workspace and can accept platform files landing in your repository, Bolt and Replit both import, with the trade-offs above.

If you're starting something new rather than changing something that already exists, use Lovable. It's good at that, and this question doesn't apply to you.

Before you migrate anything

Whichever way you go, do the boring part first. Know which commit matches what's in production, know which services sit outside the repository, and make sure previews can't email your customers or charge a live card. There's a fuller version in the production readiness checklist, and a companion piece on updating an existing app without breaking it.

If the copy trick works on a stack listed here as out of scope, that's worth reporting. This post gets corrected rather than left to rot.