Skip to main content
Publishing turns your Lovable project into a live web app by deploying a copy of it to a URL you can share. Lovable hosts the published app for you: no servers to set up, and HTTPS included. The live site keeps showing the version you published, and later changes stay off it until you publish again. You can control who can access the published app, and the options depend on your plan.

​
Quick start: publish your first project

Publishing takes two clicks, and the defaults work for most projects:
1

Click Publish

In your project, click the Publish button in the top-right corner of the editor, next to Share. On narrow windows it collapses to an icon without a label.
2

Click Publish again

The dialog suggests a website address ending in lovable.app and runs a quick security scan. Keep the defaults and click Publish, or adjust the address and audience first. When the deploy finishes, Lovable shows your live link.Lovable generates your site title, description, and icon while it builds your app. To change them, ask Lovable in the project chat. To check how each page appears in link previews and search results, see Site metadata is generated for you.
To push later changes, open the same dialog and click Publish changes. The rest of this page covers publishing from the project chat, every dialog option, site metadata, republishing and unpublishing, and who can publish, unpublish, and view your app. To continue from publishing to a live site on your own domain, follow the guide Launch your site on a custom domain.

​
Publish from the project chat

Instead of opening the Publish dialog, you can ask Lovable in the project chat to publish for you. From Chats you can do the same for any project you can edit. Try prompts such as:
To request a specific Lovable subdomain:
Lovable respects all publish-related workspace settings and permissions. It checks your publish settings, runs the Quick scan checks on the version it publishes, and schedules the deploy. Lovable asks for approval before publishing unless you have set the publish tool to auto-approve. You can also ask Lovable in the project chat to change who can see your site or connect a custom domain. It applies visibility changes before publishing and asks you to confirm before connecting a domain. To unpublish, use one of the options in the UI. Publishing from the project chat is treated as standard build usage and consumes credits.

​
The Publish dialog, step by step

The quick start covers the defaults. This section walks through every option in the dialog, which shows everything on one page: your website URL, who can see the website, and a security check.
1

Open the Publish dialog

In your project, click the Publish button in the top-right corner. By default, editors and above can publish projects.When the publish dialog opens, Lovable automatically runs a Quick scan in the background. The scan takes about 10 seconds and checks your database access rules, including row-level security (RLS) policy mistakes, your dependencies, and MCP server exposure.
2

Set your website address

  • When you publish for the first time, edit the suggested URL directly in the Website URL field, or keep it as is. By default, your app is published to [url-subdomain].lovable.app, using your project’s URL subdomain.
    On Business and Enterprise plans, you can publish apps under a workspace-branded URL pattern, such as app-name.workspace-subdomain.lovable.app. Branded app URLs create a consistent workspace-level URL structure across all published apps and are configured in Workspace settings → Workspace → Branded app URLs. See Publish apps with branded URLs to set this up.
  • When published, you can add a custom domain (available on paid plans), or change the subdomain later in Project settings → URL subdomain.
  • On the Enterprise plan, if your workspace has a publishing domain, projects without a custom domain get a suggested address under it.
  • While Lovable is still setting up a custom domain you bought, or the first custom domain you connected for the project, the dialog shows that domain under the Website URL field with a note that it is still being set up. Lovable publishes your app to the lovable.app address until the domain connection is ready. Check for Active in Project → Settings → Domains.
    The note disappears when the setup has made no progress for 72 hours, which means DNS verification stalled. The usual cause is a missing or incorrect DNS record. Re-check the records in Project → Settings → Domains, and connect the domain again if Lovable has already retired it.
3

Choose who can see the website

Select the visibility row below the URL to open the audience picker. The row names the current audience, and reads Visible to anyone with the link while the site is public. Depending on your plan, you can control who can see the website:
  • Public: anyone with the URL can visit the published app (public website access)
  • Workspace (Business and Enterprise plans): only logged-in workspace members can visit the published app (private website access)
  • Invite only (Free and Pro plans): grant access to workspace members by name, or to people outside your workspace invited by email. See Invite people outside your workspace.
  • Custom (Business and Enterprise plans): grant access to the whole workspace, specific people, groups, or people outside your workspace invited by email. See Invite people outside your workspace.
  • Your organization (Enterprise workspaces in an organization, shown with the organization’s name): members of every workspace in the organization can visit the published app after logging in. See Publish to your organization.
Audience edits take effect when you select Publish (or Publish changes on a published project). See Who can see your published app for how website access works on each plan.
4

Check the security scan result

The dialog shows the outcome of the Quick scan on a single line: Running quick security scan while it runs, No security issues found when it passes, or the number of findings to review. Critical findings show as, for example, 2 critical security issues found, and lower-severity findings as 3 security findings. The count includes findings from your latest Deep scan as well. When Lovable has no scan result for the project, because the scan has never run or you do not have permission to run it, the line offers to run the scan instead.
  • If the scan finds issues, click the line to open the Security view, where you can review and fix them. Findings do not block publishing by default, but you should resolve critical issues before making your app available.
  • The dialog does not run the Deep scan. Run it from the Security view when you want deeper coverage before publishing.
The Deep scan is an optional in-depth review of your application code. It looks for vulnerabilities such as exposed secrets, unsafe input handling, and authorization gaps. A scan takes about 4 minutes on a small app and up to 15 minutes on a large one, and the Security view estimates it for your project.See Security overview and Project security view for scanner details.
Publishing controlsWorkspace admins and owners can enforce stricter publishing rules in Workspace settings → Security → Privacy & security → Publishing to help ensure insecure applications are never deployed. Block publishing with critical issues prevents publishing while critical findings are unresolved. When it is enabled and the scan finds critical issues, the dialog lists Resolve findings under Before you publish until you resolve them. New Enterprise workspaces that Lovable creates start with it enabled. See Block publishing with critical issues.
5

Publish your project

When ready, click Publish. The dialog shows a progress bar while Lovable deploys your project. You can close the dialog and keep working. To see the progress again, click Publish in the editor.When the deployment is complete, the dialog confirms Your website is live, or Your website was updated when you publish changes. The dialog also shows Visit site and your site’s address with a copy button. For a public site, Share it opens sharing options.During and after publishing, the dialog also shows a card that previews how your site appears in search results. Click Edit next to your site’s title in the preview to check or change any page’s social and search appearance. The card can also show next steps for your site:
  • Get visitors, on a public site: opens tools that help you bring people to your site.
  • Get custom domain, when your project has no custom domain: opens the domain setup.
The dialog can also show notices before you publish, for example:
  • Fix build errors: your latest changes failed to build, so the dialog shows Try to fix instead of the publish button. Fix the build errors, then publish.
  • Your app is under high load: your built-in database is running low on resources. The notice appears below the security scan line and does not block publishing. Click it to open Review project setup, then click Resolve to have Lovable find the likely cause and suggest query or code changes. See Check your database’s resource health.
After publishing your project, you can continue to iterate on it. To push updates later, open the dialog again and click Publish changes.
After publishing publicly, rerun your SEO review to unlock live checks for indexing, AI-search readiness, and Google Search Console setup.If you connect a custom domain, rerun the review so Lovable can help verify your domain in Google Search Console and submit your sitemap.

​
Site metadata is generated for you

Lovable generates your site’s metadata while it builds your app: the site title, meta description, and site icon (favicon) shown in browser tabs and search results. The social sharing image (OG image) shown in link previews is chosen when your site is served: Lovable uses an image you’ve asked it to set, or the latest screenshot of your app. Sites that aren’t publicly visible don’t get an automatic social sharing image. To change any of it, ask Lovable in the project chat:
The site icon is one icon for your whole site. The title, description, and social sharing image start as one set that applies to every page, and a page can override them with values Lovable generates from its content. That is why viewing and changing metadata goes through chat, where you can also name the page you mean, for example: “Update the meta description of the pricing page.”
Metadata edits are treated as standard build usage and consume credits. A metadata change reaches your live site on the next publish, like any other edit. When the project is already published, Lovable ends its reply with a Publish to update the live site button so you can publish from the project chat. To check the result, open the page selector above the preview: each page has a Social card showing how the page looks when shared and a Search card showing how the page appears in search results. You can also reach the Social and Search cards while publishing:
  • In the Publish dialog, open the ⋮ menu in the top-right corner and select Social & search appearance, or click the favicon next to the website URL. Both options work whether or not your site is published yet.
  • While you publish and right after, the Publish dialog previews how your site appears in search results. Click Edit next to your site’s title in the preview to open the page selector, then hover over the preview icon on a page to see its Social and Search cards.
See Optimize your app for SEO and AI search for more information on optimizing your Lovable apps for search engines, social media previews, and AI systems.

​
Republish to make new changes live

Each time you publish, Lovable deploys a copy of your project to a live URL. The live site keeps showing that version, so when you keep working on a published project, publish again to update it. To deploy new changes, click Publish, then Publish changes. Accepting a draft is not publishing. When you accept a draft, its edits join your project’s unpublished changes, and visitors see them only after you publish the project. When your published project has changes that are newer than the live version, a small dot appears on the Publish button. It tells you at a glance that you have updates to deploy, without opening the dialog. The dot clears once you publish. It stays hidden when there is nothing new to publish, and when you do not have permission to publish.

​
How to unpublish your project

You can unpublish and remove your live app in three ways: After you unpublish:
  • The live URL becomes inaccessible
  • Your project remains in the editor
Lovable can also unpublish a project in a Free workspace after 12 months of inactivity. See Does my published site expire? for the conditions.
This section is about unpublishing, which takes the live app offline while the project stays in your workspace. Looking for a way to remove the project itself? See Delete a project. The two are different actions.

​
Who can publish and unpublish projects?

By default, editors and above can publish projects on all plans. Unpublishing takes the same permission, so anyone who can publish a project can also take it offline. You do not have to be the person who published it. Workspace admins and owners can publish and unpublish a project they were never invited to:
  • Owners: every project in the workspace, including Restricted ones.
  • Admins: every project except a Restricted one they were not invited to.
On Enterprise plans, admins and owners can set workspace policies that require approval before publishing or block it. See Request approval to publish for what you see when a policy applies. A policy never stops you from taking a live app offline.

​
Request approval to publish

On Enterprise workspaces, a workspace policy can require an admin or owner to approve before you publish, for example when the app uses a connector or when the app is public. The publish dialog shows Approval needed, and its tooltip says what the policy requires.
1

Request approval

Select Request approval and write a short note for the approvers: what the app is for and why it should go live now. Approvers see the note and a screenshot of the app, so a specific note speeds up the answer. The dialog shows how many workspace admins and owners receive the request.
2

Send the request

Select Send request. The dialog shows Awaiting review. Every admin and owner of the workspace receives a notification in Lovable and by email.
3

Wait for the decision

You get a notification in Lovable when an approver approves or denies the request. After a denial you also get an email with the reason. After an approval you get an email when the app is live.
While the request waits, you can keep editing and previewing the app. To add changes to the request, open it with View and select Update request. To withdraw it, select Cancel request. After an approval, Lovable publishes the app, and the dialog shows Approved by with the approver’s name. The dialog also shows Publish (or Publish changes on an app that is already published). Select it to publish now instead of waiting for Lovable. The approval covers this app the next times you publish, until something the policy checks changes, such as a new connector or a change in who can view the app. For public apps, it lasts for the time your workspace set. See How approvals work. After a denial, the dialog shows Request denied. Select View to read the approver’s reason. Make the changes they asked for and select Request again. A request that no admin or owner approves or denies within 30 days expires, and the dialog shows Request expired. Nothing is published, and you can request again. If the dialog shows Approval unavailable, approvals are temporarily unavailable, and Lovable cannot send your request. Select Try again after a few minutes. If the dialog shows Publishing blocked instead, your workspace does not allow publishing this way. See Publishing blocked in Troubleshooting.

​
Who can see your published app

Website access control depends on your plan. You choose who can access your published app from the visibility row in the publish dialog, which opens the Who can view your site? picker. When you select Publish (or Publish changes on a published project), Lovable updates who has access and sends any invite emails.

​
Free and Pro plans

The picker shows three rows, and you can choose two of them:
  • Public: Anyone with the URL can visit your published app. This is the default.
  • Invite only: Only people you add can visit the published app, after logging in. Add workspace members by name, or invite people outside your workspace by email. You can invite up to 10 people per project. See Invite people outside your workspace.
The third row, Workspace, is not available to you: publishing to your whole workspace or to groups requires a Business or Enterprise plan. The project owner, workspace owners, and people the project is shared with directly can always open an invite-only site.

​
Business and Enterprise plans

The picker has three options, and Enterprise workspaces in an organization have a fourth:
  • Public (external publishing): Anyone with the URL can visit your published app.
  • Workspace (internal publishing, shown with your workspace name): Only workspace members can visit the published app after logging in.
  • Custom: You compose the exact audience: the whole workspace, groups, individual members, people in your organization, and people outside your workspace invited by email. See Invite people outside your workspace.
  • Your organization (Enterprise workspaces in an organization, shown with the organization’s name): Members of every workspace in the organization can visit the published app after logging in. See Publish to your organization.
Custom is the same option that Free and Pro plans call Invite only, widened to admit the workspace, groups, and your organization as well as people you name. With these options you can:
  • Build and share internal apps that stay private to your workspace
  • Show a private app to a client or contractor without adding them to your workspace
  • Share an app with colleagues in other workspaces of your organization
Workspace admins and owners can also set the default audience for all published projects with Default published app access in Workspace settings → Security → Privacy & security → Publishing. You can override the workspace default for individual projects in the publish dialog by choosing who can see the website. If unchanged, the project inherits the workspace default.

​
Publish to your organization

When your Enterprise workspace belongs to an organization, you can publish an app to everyone in the organization. Colleagues in other workspaces of your company can then open it, and the app stays private. To publish to the organization:
  1. In your project, click Publish.
  2. Select the visibility row to open Who can view your site?.
  3. Choose the option named after your organization.
  4. Select Publish (or Publish changes on a published project). When the dialog confirms Your website is live, members of every workspace in the organization can open the app after logging in to Lovable.
External collaborators, people with a pending invitation, and people outside the organization cannot open the app through this option. A colleague who has never joined a workspace in the organization must join one first, for example by invitation or through the organization’s SSO. Viewing the app does not give anyone access to the project itself. Visitors log in to Lovable to open the app. A visitor who has no access can request it. Colleagues in other workspaces of your organization are not people outside your workspace, so you do not invite them by email. To give one colleague from another workspace access without publishing to the whole organization, choose Custom and search for them by name or email. The picker offers only people who already belong to a workspace in the organization. To give access to the organization and to specific people, for example a client outside the company, choose Custom and add both. The Custom card then includes the organization in its summary of who has access.

​
Invite people outside your workspace

You can give people outside your workspace viewer access to an internally published app, for example a client or a contractor, without adding them to your workspace and without making the site public. Project editors and above can manage the website audience.
1

Open the audience picker

In the publish dialog, select the visibility row to open Who can view your site?, select Invite only (Free and Pro plans) or Custom (Business and Enterprise plans), then select View and edit on that card.
2

Invite by email

Type the person’s email address in the search field. For an address outside your workspace, an Invite option appears. Select it to add the person. They appear under Added, and the card shows who has access.If the workspace has set External viewer invites to Off, the email option doesn’t appear. If the workspace limits invites to specific email domains, addresses on other domains can’t be added, and the picker says which domains are allowed.
3

Publish your changes

Select Done to close the picker, then Publish (or Publish changes on a published project). Lovable then sends each invited person an email and updates who has access. Until you select that button, invites are not applied and no emails are sent.
The invite email contains a link to your site. If the invited person already uses Lovable, they also get an in-app notification. To open the site, they log in with the invited email address. If they don’t have a Lovable account yet, they can create one with that address. Their access is tied to their account after that and is marked with an EXT label in the audience list. These rules apply to external viewers:
  • Invites don’t expire. Removing someone from the audience revokes their access when you apply the change.
  • Adding an address that is already in the audience sends no second email. To send a fresh invite, remove the person and add them back.
  • Workspace members can’t be invited as external viewers. Add them by name instead. On Business and Enterprise plans, you can also add the whole workspace or a group.
  • On Free and Pro plans, you can invite up to 10 people per project.
  • Each address can receive at most 10 invite emails per day.
  • On Business and Enterprise plans, workspace admins and owners control external viewer invites for the whole workspace from Workspace settings → Security → Privacy & security → Publishing. They can set External viewer invites to Off, or limit invites to specific email domains. Your company’s verified domains are always allowed.
  • People who were already invited keep their access when an admin or owner changes that setting.
  • On Business and Enterprise plans, Security insights flags internally published projects that have external viewers, so admins can review who has access.

​
Approve requests to use your published app

When someone outside the audience opens an internally published app, they can ask you for access instead of contacting you outside Lovable. They log in to Lovable, see You don’t have access, and select Request access. They add an optional message, then send the request.
This section is about access to an app you published, where someone only uses the app. Looking for requests to work on the project with you? See Project access requests. The two are different features.
Requests arrive in your Inbox, which you open from the user menu under your avatar. Each request shows who asked, their email address, the app they want, and any message they wrote. Requests go to everyone who can manage that app’s audience:
  • The project’s owner.
  • Project editors and above.
  • Workspace admins and owners who can publish that project.
Lovable emails the project’s owner, or the workspace’s admins and owners. Everyone else sees the request in the Inbox without an email. Lovable emails the requester after you approve or decline. Select Approve to give the person access, or Decline. Approving adds them to the app’s audience and takes effect immediately, so you do not publish again. Someone still waiting on the page gets into the app within a few seconds, without reloading it. An approved person gets no access to the project itself, and does not join your workspace. If the app is published to your whole workspace, the first approval moves it to a Custom audience. That audience includes your whole workspace, so everyone who could open the app still can.
If you unpublish the app while a request is waiting, Lovable refuses the approval. Lovable cannot give access to an app that is not live. The request stays open, so publish the app again, then approve it.
On Enterprise plans, a workspace policy that blocks publishing also blocks approvals, because approving gives someone access to a published app. You can still decline a request. A person whose request you decline can send a new one 24 hours later. Until then, they cannot ask again, and Lovable tells them when they can. A person whose access you remove can ask again immediately.

​
Who can ask for access to your app

Someone who is in neither your workspace nor your organization must verify their email address before Lovable accepts the request. Workspace members and colleagues in other workspaces of your organization skip that step. On Business and Enterprise plans, External viewer invites also decides who outside the workspace can ask. With Off, nobody outside your workspace can send a request. With Specific email domains only, only addresses on the domains you allow can send one. Lovable refuses an approval the setting no longer allows. On every plan, Lovable has no setting that stops requests for a single app.

​
Trust center

Externally published apps can also have a Trust center: a security page Lovable generates on your app’s own domain, with verifiable facts about how the app is served and built. Enable Trust center in Project settings → Publishing. Each publish is evaluated fresh, so the Trust center always describes the deployment that’s live.

​
FAQ

Yes. Ask Lovable to publish, deploy, or go live, and it respects every publish-related workspace setting and permission, runs the Quick scan checks on the version it publishes, and schedules the deploy. You can also request a specific Lovable subdomain, such as my-todos.lovable.app. Lovable asks you to approve before it publishes, unless you have set the publish tool to auto-approve.Publishing from the project chat is treated as standard build usage and consumes credits. See Publish from the project chat for the prompts to use and for changing the audience or the domain this way.
Published sites have no fixed expiry date. Only share preview links expire, after 7 days by default. Apps that use the built-in backend or AI features do need available credits to serve requests.Lovable may unpublish a project in a Free workspace that has been inactive for about a year. It checks that all of these are true:
  • The app has had no visits for 12 months or more.
  • The workspace owner has not logged in for 12 months or more.
  • Nobody has edited or published the project for 12 months or more.
  • The project has no connected custom domain.
When Lovable unpublishes a project for inactivity, it emails the workspace owners and admins. Lovable also pauses the project’s built-in backend. The built-in backend is the database, login, and file storage Lovable runs for your app. Lovable does not delete your project, code, or data. The project keeps its lovable.app address.To bring the app back online:
  • Log in and open the project.
  • Click Wake up on the paused project card in More → Database. See Resume a paused project.
  • Publish the project again.
The Publish button sits in the top right of the editor. On narrow windows it collapses to an icon without a label, so look for it next to Share. You can also ask Lovable in the project chat to publish your app.
No. Publishing from the Publish dialog is free and works even when your credit balance is zero. Hosting the published app and running its built-in backend consumes Run credits as your app is used, and asking Lovable to publish in the project chat is treated as standard build usage and consumes credits.
Your published app stays live. Downgrading or canceling does not unpublish your project.
  • Your published app stays restricted. An app you restricted to workspace members or to selected people on a Business plan keeps requiring login after a downgrade. Invited people, the project owner, workspace owners, and people the project is shared with directly keep their access. An app published to your whole workspace stays open to workspace members until you next publish changes from the publish dialog. A Custom audience behaves differently: its workspace and group entries stop granting access after the downgrade. After a downgrade you can still set website access to Public or Invite only.
  • Publishing changes switches the app to Invite only. Publishing to your workspace or to groups requires a Business or Enterprise plan. If you published an app that way before the downgrade, the next publish from the publish dialog switches it to Invite only. The dialog warns you first. Workspace members lose access to the website but keep their access to the project. Other ways of publishing, such as the project chat, do not work until you change the audience in the dialog. To keep the workspace audience, upgrade again before you publish changes. You can unpublish the app on any plan.
  • Connected custom domains keep serving your app. Connecting a new custom domain requires a paid plan, but domains that are already connected continue to work, and you can still disconnect them. Domains bought through Lovable are billed separately from your subscription, so their registration and renewal are not affected by a plan change. See What happens to my custom domain if I downgrade or cancel my plan?
  • Apps that use the built-in backend or AI features still need available credits to serve requests. See Credits and usage.
No. Publishing only makes the app available at the published URL. It does not grant anyone access to your project in the editor or your project code, and it does not make your project automatically remixable.Access to the editor, source code, project chat history, and unpublished changes is always controlled by project access.
Project access and website access are independent settings. You can combine them in different ways depending on your needs.
  • Project access controls who can access the project in the editor, including source code, project chat history, work in progress, and changes that have not yet been published.
  • Website access controls who can visit the published app at its live URL.
These are the common combinations:
  1. Internal team app
    • Project access: Workspace
    • Website access: Workspace
    • Result: Only workspace members can view and edit the project in the editor and visit the published app.
  2. Private work-in-progress, public app
    • Project access: Restricted
    • Website access: Public
    • Result: Only you and your workspace’s owners can view and edit the project in the editor, but anyone with the published URL can visit the published app.
  3. Team-built, publicly shared app
    • Project access: Workspace
    • Website access: Public
    • Result: Only workspace members can view and edit the project in the editor, but anyone with the published URL can visit the published app.
  4. Private prototype shared internally
    • Project access: Restricted
    • Website access: Workspace
    • Result: Only you and your workspace’s owners can view and edit the project in the editor, and only workspace members can visit the published app.
Publishing does not change who can access your project in the editor, and project access does not affect who can visit the published app.
Yes. On every plan you can restrict your published app to invited people. On Business and Enterprise plans you can also publish it to your whole workspace or to groups. Enterprise workspaces in an organization can also publish it to everyone in the organization. See Publish to your organization.In the publish dialog, select the visibility row to open Who can view your site?. On Free and Pro plans, choose Invite only and add people by name or email, up to 10 people per project. On Business and Enterprise plans, choose your workspace to publish internally, or choose Custom to compose the audience: the whole workspace, specific people, groups, people in your organization, and people outside your workspace invited by email. See Invite people outside your workspace.
Invite them by email from the Invite only audience (Free and Pro plans) or the Custom audience (Business and Enterprise plans) in the publish dialog. When you select Publish (or Publish changes on a published project), they receive an email with a link to your site, and people who already use Lovable also get an in-app notification.To open the site, they log in with the invited email address, or create a Lovable account with that address if they don’t have one. Their access doesn’t expire, and it is marked with an EXT label in the audience list. Adding an address that is already in the audience sends no second email, and workspace members can’t be invited as external viewers.Someone who opens the app without access can also ask you to add them, instead of waiting for an invitation. See Approve requests to use your published app.
Publishing deploys a copy of your project as it was at that moment. Later changes do not reach your live app on their own.To publish updates, click Publish and then Publish changes.
Ask Lovable in the project chat. Lovable generates the title, meta description, and site icon (favicon) while it builds your app. The icon is one icon for the whole site. The title and description can differ per page, so name the page you mean.The social sharing Open Graph (OG) image is chosen when your site is served: Lovable uses an image you have asked it to set, or the latest screenshot of your app. A site that is not publicly visible gets no automatic one.For example:
Metadata edits are treated as standard build usage and consume credits. A metadata change reaches your live site on the next publish, like any other edit. When the project is already published, Lovable ends its reply with a Publish to update the live site button so you can publish from the project chat.See Site metadata is generated for you for where to check how each page looks when shared and in search results, and Optimize your app for SEO and AI search for search engines, social media previews, and AI systems.
You can change your project URL subdomain, which forms your lovable.app website address, in Project settings → URL subdomain: change the subdomain and click Update URL subdomain.When you publish for the first time, you can also edit the URL directly in the Website URL field of the publish dialog.Renaming the project does not change the project URL. It changes only the project display name.On paid plans, you can also add a custom domain.
When publishing fails, Lovable shows a Publishing failed message explaining what went wrong and what to do. Select Try again for a temporary issue, or Try to fix to have Lovable investigate an error in your app. See Troubleshooting for each failure type and how to resolve it.If the dialog blocks publishing instead, check these common causes:
  • The dialog shows Fix build errors and replaces the publish button with Try to fix. Your latest changes failed to build, so publishing them would fail the same way. Select Try to fix to have Lovable fix the build errors in the project chat, or fix them yourself, and publish again when the preview builds.
  • The button shows You don’t have permission to publish this project when you hover it: publishing needs editor access or above. See Who can publish and unpublish projects?
  • The dialog shows Approval needed or Publishing blocked. A workspace policy on your Enterprise workspace requires approval before you publish or blocks it. See Request approval to publish.
  • Your workspace admin or owner enabled Block publishing with critical issues in Workspace settings → Security → Privacy & security → Publishing. It prevents publishing while critical findings are unresolved, and the dialog lists Resolve findings under Before you publish. Select Review to open the Security view, fix the findings, and try again.
First check that publishing finished: the dialog confirms Your website is live when the deploy completes, and shows a Publishing failed message when it didn’t. See Troubleshooting for the failure types.Then check that you’re opening the exact published URL. The lovable.app address uses your project’s URL subdomain, which can differ from the project’s display name, and changing the subdomain moves your site to the new address. If you use a custom domain, DNS changes can take time to take effect.
Yes, especially if your site is public. Some SEO checks only run against the live published site, including indexing, AI-search readiness, and Google Search Console setup.After publishing, run an SEO review to check your live site. If you connect a custom domain later, run the review again so Lovable can re-check the new host, verify Google Search Console, and submit your sitemap.
Lovable builds web apps and publishing always deploys to a web URL (for example, yourproject.lovable.app or your custom domain). Lovable has no built-in flow that packages and submits your project to the App Store or Google Play, but you have two options if you want an installable, store-ready experience:
  • Progressive Web App (PWA): make your published app installable so users can “Add to Home Screen” and launch it like a native app, with offline support and a full-screen shell. This is the fastest path and works from any modern mobile browser.
  • Capacitor wrapper: wrap your published URL in a native shell with Capacitor outside of Lovable, then submit that shell to the App Store or Play Store. This is the right path when you need access to native device APIs (camera access, push notifications, or biometrics) or when a store requires a native binary.
Lovable does not generate projects in React Native, a developer framework for building native mobile apps. If you need a React Native app, use Lovable to prototype your app’s screens and flows in the browser, then rebuild them with React Native outside of Lovable.The separate Lovable mobile app is for building projects from your phone. It does not turn your project into a native app for end users.
Yes. Lovable can add an app you built to your team’s Slack workspace as its own Slack app, so teammates can mention it in a channel or send it a direct message. A workspace admin or owner authorizes your Slack workspace once from the Slack connector page, and after publishing you ask Lovable to add the app to Slack. See Add your app to Slack as an agent.

​
Troubleshooting

When publishing fails, a Publishing failed banner appears in the Publish dialog with a message explaining what went wrong and how to resolve it. When the failure is something Lovable can help with, it already knows the details, so you can ask for help in the project chat.
This is intended when your workspace is not on the Enterprise plan or does not belong to an organization. If your workspace is on the Enterprise plan and belongs to an organization and the option is still missing, Lovable has set a publishing policy for your workspace that does not allow publishing to the organization. Contact your account team. See Publish to your organization.
The publish failed because of a short-lived problem, such as a timeout or a rate limit on a connected service.What to do: Click Try again in the banner. Retries usually succeed.
The publish failed because of something in your app’s code, such as a build error or an edge function that couldn’t be deployed. When the cause is a build error, the banner shows a short summary of the build error instead of this message.What to do: Click Try to fix in the banner. Lovable investigates and applies a fix, and you can publish again when it’s done. You can also describe the issue in the project chat. If the fix request can’t be sent immediately, for example because you reached a rate limit, the banner stays visible so you can try again.
A configuration problem inside your project blocked publishing, for example a file that is too large to include.What to do: Click Try to fix in the banner. Lovable resolves the configuration problem, and you can publish again when it’s done.
The publish failed because of a connection or setting outside your project that Lovable can’t change for you, such as an expired Supabase connection or a connected service that reached its plan limits.What to do: Fix the underlying setting, for example reconnect the integration or update its plan or quota, then click Try again.
A database change you are publishing conflicts with data that already exists in your live app’s database.What to do: Click Ask Lovable in the banner. Because the fix affects real data, Lovable confirms with you before changing anything.
The failure happened on Lovable’s side and is not something you can resolve by changing your app or its configuration.What to do: Try publishing again after a few minutes. If the failure persists, contact support and include your project link.
This is intended. The request closed without a decision because the project or the publishing policy changed after you asked. The info icon next to the status says which one changed. Select Request again to send a new request for the app as it is now. See How approvals work.
This is intended. A workspace policy does not allow this kind of publishing. These policies can block publishing:When the sensitive data findings policy blocks publishing, the dialog lists Sensitive data under Before you publish instead, with a Review button. See Sensitive data scanning.Ask a workspace admin or owner if you think the policy should not apply to your app.
Publish failure messages never include raw logs or output from connected services, so secrets and connection details stay out of the UI. Build errors and conflicting database changes are the exceptions: the banner shows a summary of the build failure or the database’s own error message so you can act on it.