How to add a developer to your Lovable project

As of October 12, 2026, the safe way to give a developer access to a Lovable app is to invite them into each system under their own login, with the smallest role that lets them do the work. Never share your own password or paste secret keys into chat or email. In Lovable that usually means adding them to the one project as an Editor from the Share dialog, not making them a workspace admin. Then invite them to GitHub, Supabase and Stripe with each platform's own team invite and a limited role, keep a list of what you granted, and remove it all when the work ends.

This guide is for founders who built their app in Lovable and are bringing in a freelancer, an agency or a first engineer. It walks through each access point, the role to give, what to avoid, and how to offboard. For the full handover, see handing over an AI-built app to developers. Platform facts come from the official docs listed under Sources.

What does a developer actually need access to?

Usually less than they ask for on day one. A Lovable app is several accounts: the Lovable project, a GitHub repository, a database (Lovable Cloud or your own Supabase project), a payments account such as Stripe, the domain and DNS, and often a Google Cloud project for Google sign-in. Each has its own invite and roles.

The principle is called least privilege: give each person only the access their task needs, for as long as they need it. Most platforms build it into their roles, an idea our glossary explains as role-based access control. Stripe's team docs say it directly: grant the lowest permission the user needs to do their job.

Write down the task first. A layout bug needs the Lovable project and maybe GitHub. A payments bug may need Stripe, but only a test copy. Nobody needs the owner role on anything you own.

Which access should you give, system by system?

How do you add a developer in Lovable?

Invite them to the project, not the workspace. Lovable's docs describe two levels. Workspace roles (owner, admin, editor, viewer) cover every project in the workspace. A collaborator is someone you invite to a single project from that project's Share dialog; they cannot be added from the People tab, they never see it, and they only see projects shared with them.

1. 01Open Share on the projectIn the project, click Share and type the developer's email in Add people.
2. 02Pick the access levelLovable's project roles are Admin, Editor and Viewer. Editor is the default and can build and change most settings. Admin adds integrations and external connections; Admin and Viewer are on paid plans only. Choose Editor for someone building, Viewer for someone reviewing.
3. 03Prefer an email invite to a linkLovable also offers invite links: anyone who opens one joins the project with the role you set. Links last 5 days and only one can be active, but anyone the link is forwarded to gets in. An email invite reaches one named person.
4. 04Check who is on the projectThe Share dialog lists everyone with access and their role.

Mind your budget: credits belong to the workspace that owns the project, so a collaborator's prompts spend your credits. Their billing controls are disabled. If credits are already tight, read why Lovable credits run out before you add a heavy prompter.

If your app runs on Lovable Cloud, the database lives inside the project. Lovable's Cloud page describes viewing tables, editing records and running SQL there, but it does not say which project roles can see that area or its Secrets. Until it does, treat edit access to a Cloud project as access to your customers' data, and ask Lovable support if that matters for your business. A developer who needs full database tools may also raise moving off Lovable Cloud; Lovable says there is no one-click migration.

How do you give access to the GitHub code safely?

Connect the repository yourself, then invite the developer to it. In Lovable, only workspace owners and admins can create the GitHub connection, and owners and admins connect a project to a repository. Lovable then syncs one branch both ways, usually main: anything pushed to that branch flows straight back into your Lovable project. That is why the role and the branch rules matter.

GitHub has a catch for personal accounts. On a repository owned by your personal account, the owner can only grant collaborators write access, even on a private repository; there is no read-only option. GitHub's own advice for finer control is to transfer the repository to an organization. In an organization, the roles run from Read (view and discuss) through Triage, Write (push code) and Maintain to Admin (full control, including destructive actions). Give a developer Write and keep Admin for yourself. Set up Lovable's GitHub connection for the organization first, or Lovable disconnects the project.

Then protect main. In the repository's Settings, Branches, add a branch protection rule for main and turn on Require a pull request before merging, with at least one approval. Changes then arrive as reviewable pull requests, not straight into your live app. GitHub notes that restricting who can push to a branch needs a repository owned by an organization, and for private repositories a GitHub Team or Enterprise Cloud plan.

How do you add a developer to Supabase?

From your Supabase organization's team settings, invite them by email. The invite is valid for 24 hours. Supabase's roles are Owner, Administrator, Developer, Read-only and No-access. A Developer can read and change data and run SQL, but cannot change project settings, update auth settings, or delete, pause or transfer projects. Read-only can view data and run SELECT queries only. On Team and Enterprise plans, you can scope a role to a single project.

Know what Developer includes: Supabase's permissions table shows it can read the service key, which bypasses every row-level security rule. Read-only cannot. Give Read-only to a reviewer, Developer to a builder, and nobody your Owner seat. Our glossary explains the difference between the anon key and the service_role key.

How do you add a developer to Stripe?

In the Stripe Dashboard, go to Settings, Team and click Add member. Invites expire after 10 days. Start with a sandbox role. Sandbox User and Sandbox Admin can build and test payments in sandboxes but cannot view or change anything in your live account, which is all most integration work needs.

Give the Developer role only when the person must work in the live account, and know what it carries. Stripe's docs say it can create secret keys that grant access to almost all API resources, refund payments and pay out your balance to an external bank account. It cannot invite team members. The Administrator role can, and Stripe warns that an attacker who compromises a user with a role that can invite people can add users of their own. Stripe keeps 180 days of team activity under Security history. Our Lovable Stripe integration guide covers the keys the app itself should use.

What about the domain, DNS and Google sign-in?

Whoever controls your DNS controls where your users and your email go. Never share the registrar login. Some registrars offer delegate or team access; if yours does not, make DNS changes yourself on a short call while the developer tells you what to enter. In Lovable, the workspace's primary owner is the one used for domain claims.

Google sign-in on your own Google Cloud project is set up in that project. On its IAM page, click Grant access, enter the developer's Google account and choose a role. Google's guidance is to choose a role with only the permissions the person needs. For sign-in work that is a narrow role such as OAuth Config Editor, listed as read and write access to OAuth configuration and marked Beta, not the project-wide Owner or Editor roles, which include it. If Google sign-in is the problem, see Lovable Google login not working.

What should you never share with a developer?

• Your own password to any of these accounts. With a shared login you cannot tell who did what or remove one person without changing your password.
• The Supabase service_role or secret key in chat, email or SMS. Supabase's docs list all three as places a secret key must never travel. Share it through an encrypted tool, or let the developer read it from the dashboard under their own login.
• A live Stripe secret key over email. If the developer needs live access, invite them with a role; the app's own key belongs in your backend secrets.
• Your workspace owner seat, anywhere.

When something must be passed by hand, use your password manager's secure share or the platform's own invite, never a message. Our glossary covers secrets management. If a key has already gone out by chat or email, treat it as leaked and rotate it; what to do when a Lovable API key is exposed walks through that.

What paperwork should you have before granting access?

A signed contract before any access goes out. It should cover confidentiality (an NDA, or a confidentiality clause), a clause assigning the intellectual property in the work to your company, and how customer data must be handled. Who owns code a contractor writes depends on the contract and the law where you are, so ask a lawyer to review it. This is general information, not legal advice. Our guide to hiring a Lovable developer covers choosing the person.

How do you remove access when the work ends?

Work from the access list you kept while granting: person, system, role, date granted, date removed. A spreadsheet is enough.

1. 01LovableIn the project's Share dialog, open the access dropdown next to their name and choose Remove. A workspace member is removed from Settings, People; their access ends immediately and they are emailed.
2. 02GitHubIn the repository's Settings, Collaborators, click Remove. GitHub deletes their fork of a private repository, but any copy already on their computer stays with them.
3. 03Supabase, Stripe and Google CloudRemove them from the Supabase team, the Stripe Team settings and the Google Cloud IAM page.
4. 04Rotate anything they sawIf they could read a secret key, assume they still have it. Create a new key, swap it in, then retire the old one; Supabase recommends a separate secret key per component so one rotation stays small.

When should you stop prompting and get help?

You can do all of this yourself. Get help when someone has left and you are not sure what customer data they could reach, when money is involved and you cannot tell which keys are live, or when a developer's changes keep breaking the app you prompt in. Our vibe-coding rescue service starts with exactly that audit. The free production-readiness check shows where your app stands in a few minutes.

On a Plutonapps plan, named engineers work inside accounts you own, under their own logins and roles, and hand everything back if you stop. Plans are on our pricing page.

Sources

All checked on October 12, 2026.

• Lovable documentation: People, on workspace roles, external collaborators, removal and credits (docs.lovable.dev/features/people).
• Lovable documentation: Share a project, on project roles, invite links and removing access (docs.lovable.dev/features/share-project).
• Lovable documentation: GitHub integration, on who can connect and the two-way branch sync (docs.lovable.dev/integrations/github).
• Lovable documentation: Lovable Cloud, on the database area, secrets and migration (docs.lovable.dev/features/cloud).
• GitHub Docs: Permission levels for a personal account repository, on write-only collaborators and fork deletion (docs.github.com/en/account-and-profile/reference/permission-levels-for-a-personal-account-repository).
• GitHub Docs: Repository roles for an organization (docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization).
• GitHub Docs: Inviting and removing collaborators on a personal repository (docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-access-to-your-personal-repositories).
• GitHub Docs: About protected branches, and Managing a branch protection rule (docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches).
• Supabase documentation: Access control, on organization roles and the service key (supabase.com/docs/guides/platform/access-control).
• Supabase documentation: API keys, on secret keys, where they must never travel, and rotation (supabase.com/docs/guides/api/api-keys).
• Stripe documentation: Start a team, on inviting members and security history (docs.stripe.com/get-started/account/teams).
• Stripe documentation: User roles, on Developer, Administrator and sandbox roles (docs.stripe.com/get-started/account/teams/roles).
• Google Cloud documentation: Manage access to projects, and OAuthConfig roles and permissions (docs.cloud.google.com/iam/docs/granting-changing-revoking-access; docs.cloud.google.com/iam/docs/roles-permissions/oauthconfig).