There is no single button that beams a Lovable project into a stranger's account. The official path is workspace-based: use Move workspace (Project settings) to move a project into a workspace the recipient belongs to, or invite them to your workspace and use Transfer ownership. Code and history move with the project, but Cloud data, custom domains, and credits usually need to be reconnected manually afterward.
| Fact | Value |
|---|---|
| Tool | Lovable |
| Difficulty | Intermediate |
| Time required | ~15-30 min |
| Compatibility | Move workspace and Transfer ownership: available to workspace owners/admins on all plans. GitHub/GitLab export fallback: sync is free on all plans. |
| Last updated | September 2026 |
Why Lovable transfers projects are workspace-based, not account-to-account
Lovable organizes everything around workspaces, not individual projects with independent ownership. Billing, credits, secrets, and team access are all scoped to a workspace, so a project cannot simply be beamed from one person's account to another's without crossing a workspace boundary. That is why the official mechanism is Move workspace, which relocates a project between workspaces you have access to, plus Transfer ownership for handing off control within a workspace you already share. This workspace-first design is also why some things do not travel automatically with the project. Lovable Cloud connections, custom domains, and credit balances are tied to the workspace's billing account, not the project itself, so they need to be reconfigured on the receiving side even after the code has successfully moved. For a true stranger-to-stranger handoff, where the recipient will never be part of any shared workspace, GitHub or GitLab export becomes the practical workaround, trading a slightly rougher handoff for a completely clean separation.
- Projects live inside workspaces, and workspaces hold billing, credits, and secrets — there is no project-level account independent of a workspace
- Move workspace requires the sender to already have access to the destination workspace, which is why inviting the recipient first is often the real first step
- Lovable Cloud data, custom domains, and credit balances are billing-account artifacts, not project files, so they rarely follow a transfer automatically
- GitHub/GitLab export exists as a workspace-independent fallback for recipients who will never join a shared workspace
Before you start
- Access to the project's current workspace settings (owner or admin role)
- The recipient's Lovable account, or their willingness to create one, if using Move workspace or Transfer ownership
- A GitHub or GitLab account for both parties if using the export fallback
- A note of any custom domain and Lovable Cloud usage the project depends on, so it can be reconnected afterward
How to fix it
Pick the right transfer method for your situation
The correct method depends on whether the recipient is already in a shared workspace, has a separate workspace, or has no Lovable account at all
If you and the recipient already share a workspace, use Transfer ownership inside that workspace. If they have their own separate workspace, use Move workspace to send the project there directly. If they have no Lovable account, or you specifically want a clean break with no shared workspace history, export via GitHub sync and hand off the repository instead. Choosing wrong means redoing the transfer, so confirm which case you are in before starting.
Expected result: You know which of the three transfer paths applies before touching any settings.
Move the project to another workspace
Move workspace is the official mechanism for relocating a project, and it works whether the destination workspace is yours or someone else's
Open the project and go to Project settings, then choose Move workspace. You will see a list of workspaces you have access to — this includes your own additional workspaces and any workspace you have been invited into. Select the destination workspace and confirm. From the dashboard, you can also do this in bulk: select multiple project cards, open the actions bar, and choose Transfer to workspace for several projects at once.
Expected result: The project now appears in the destination workspace's project list and is no longer listed under the original workspace.
Invite the recipient and transfer ownership within a shared workspace
When the recipient is not yet in a workspace you both can access, inviting them first is the cleanest route to a true cross-account handoff
From Workspace settings, invite the recipient's email to join your workspace as a member. Once they accept, open the specific project's settings and use Transfer ownership to make them the project owner. After ownership transfers, you can optionally remove yourself from the workspace or leave the project shared, depending on whether you want to retain access.
Expected result: The recipient is now the project owner, and billing/credit responsibility for that project's usage follows the workspace they control.
Reconnect what does not automatically transfer
Cloud data, custom domains, and credits are tied to the workspace and billing account, not the project file, so they need manual reconnection
After the move or ownership transfer, check three things on the new side: the Lovable Cloud connection (database, auth, storage) may need re-verification or a fresh migration if the recipient is on a different Cloud instance; the custom domain will likely need to be reconnected and re-verified through DNS from the new workspace's Publish settings; and workspace credits do not follow the project, so the new owner's workspace needs its own active plan to keep building or publishing. This is the step people forget, and it is where transfers appear to have failed even though the code moved successfully.
Expected result: The project is fully functional under the new account: Cloud, domain, and publishing all confirmed working, not just the code.
Use a GitHub export as a fallback for a clean handoff
When the recipient will never join your workspace, exporting the code directly avoids workspace entanglement entirely
Connect the project to GitHub (Settings then Connectors then GitHub) if it is not already synced. Share the repository with the recipient's GitHub account. They can then either run the code independently outside Lovable, or create a new Lovable project of their own and continue development from that repository's code as a fresh starting point (Lovable cannot directly import the repo, but they can reference it while rebuilding). For transfers involving a live production app with paying users, RapidDev's engineers handle the full handoff, including database migration and DNS cutover, as part of their standard $13K-$25K engagements, so nothing breaks mid-transfer.
Expected result: The recipient has full, independent access to the code with no dependency on your original workspace.
Complete code example
1# Project Handoff Checklist23## Before the transfer4- [ ] Confirm the recipient has a Lovable account and workspace5- [ ] Export a GitHub/GitLab backup regardless of transfer method6- [ ] List every custom domain connected to this project7- [ ] List every Secret name used (not values) in the Cloud tab8- [ ] Note whether Lovable Cloud (managed Supabase) is connected910## Transfer method used11- [ ] Move workspace (Project settings)12- [ ] Transfer ownership (within shared workspace)13- [ ] GitHub/GitLab export handoff (no shared workspace)1415## After the transfer — verify on the new side16- [ ] Project appears in the destination workspace17- [ ] Custom domain reconnected and DNS re-verified18- [ ] Lovable Cloud connection confirmed working (database, auth, storage)19- [ ] Third-party Secrets re-added under the new workspace20- [ ] New workspace has an active plan with enough credits21- [ ] Published app still loads correctly at its live URLBest practices to prevent this
- Confirm which of the three transfer paths fits your situation before starting — Move workspace, Transfer ownership, or GitHub export solve different problems
- Invite the recipient to a shared workspace first if they do not already have one you can move the project into
- Write down every custom domain, Cloud connection, and Secret the project uses before transferring, since none of these move automatically
- Re-verify DNS for any custom domain from the new workspace immediately after the transfer to avoid downtime
- Never rely on transferring a project as a substitute for exporting a backup — do a GitHub sync export first if the transfer is at all high-stakes
- Confirm the recipient's workspace has an active plan with enough credits before the transfer, or publishing and building will stall immediately
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I need to transfer a Lovable.dev project to another account. Here is my situation: - Recipient already has a Lovable workspace: [yes/no] - Project uses Lovable Cloud (database/auth): [yes/no] - Project has a custom domain connected: [yes/no] - Recipient is inside my company or an external client: [describe] Please help me: 1. Decide between Move workspace, Transfer ownership, or a GitHub export handoff 2. List everything I need to reconnect on the recipient's side after the transfer 3. Write a handoff checklist I can send to the recipient 4. Flag any risk of downtime for a live, published app during the transfer
Create a HANDOFF.md file documenting everything a new project owner needs to reconnect after a workspace transfer: the Lovable Cloud connection, any custom domain and its DNS records, third-party API keys stored in Secrets (list the key names only, not values), and the current subscription plan requirements for this project to keep working.
Frequently asked questions
How do I transfer a Lovable project to another account?
Open Project settings and use Move workspace to move the project into a workspace the other person belongs to, or invite them to your current workspace and use Transfer ownership. If they have no Lovable account at all, export the code via GitHub sync and have them remix or reconnect it in their own workspace instead.
Is there a direct 'transfer to another account' button in Lovable?
Not exactly. There is no single button that moves a project straight to an email address that has never touched the workspace. Instead, Lovable's official path is workspace-based: Move workspace (Project settings) moves a project between workspaces you already have access to, and Transfer ownership hands off ownership within a shared workspace.
What actually transfers when I move a Lovable project?
The project's code, chat history, and edit history move with it. What does not automatically transfer: connected Lovable Cloud data (database rows, storage files, auth users), the custom domain, and remaining workspace credits, since credits belong to the workspace, not the project. Each of these needs to be reconnected or reconfigured after the move.
Can I transfer a project to someone who doesn't have a Lovable account yet?
They need a Lovable account and to either join your workspace or have a workspace of their own for you to move the project into. If they truly cannot create an account, the fallback is exporting the project through GitHub sync and having them import that code manually outside Lovable, since Lovable projects cannot be transferred as a standalone file.
How do I move a project between two of my own workspaces?
Open the project, go to Project settings, and choose Move workspace. Pick the destination workspace from the list of workspaces you belong to, then confirm. This is the same mechanism used for cross-account transfers, since moving to a workspace the recipient owns is how a cross-account transfer actually happens.
Does transferring a project also transfer its custom domain?
No. Custom domains are tied to billing and DNS configuration on the workspace that originally purchased or connected them, so after a transfer you generally need to reconnect the domain, and possibly re-verify DNS records, from the new owner's workspace.
Can I use a GitHub export as a workaround instead of transferring the project itself?
Yes, and it is the most reliable option when the recipient will not be part of your workspace at all. Connect the project to GitHub, share the repository with the new owner, and have them either run the code independently or create a fresh Lovable project and remix or rebuild from that repository.
What if I can't fix this myself?
Project transfers get messy fast when Lovable Cloud data, custom domains, and multiple team members are involved. RapidDev's engineers handle Lovable ownership transfers and account migrations as part of their standard $13K-$25K engagements, including re-wiring the database and domain on the new side.
Talk to an Expert
Our team has built 1,000+ apps. Get personalized help with your issue.
Book a free consultation