> ## Documentation Index > Fetch the complete documentation index at: https://docs.lovable.dev/llms.txt > Use this file to discover all available pages before exploring further. # Publish your Lovable project > Deploy your project to a live URL, control who can access the published app, configure site metadata, and update or unpublish at any time. Publishing turns your Lovable project into a live web app by deploying a snapshot to a URL you can share. Lovable [hosts the published app](/features/hosting) for you: no servers to set up, and HTTPS included. Only the current version is deployed, and depending on your plan, you can control who can access the published app. ## Quick start: publish your first project If you just want to get a project live, follow these three steps. The rest of this page covers plans, access control, metadata, security checks, and updating a published app. 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. Lovable auto-fills a URL (`[name].lovable.app`), site title, description, and icon. You can edit any of these now or later. A basic security scan runs automatically while the dialog is open. When the deploy finishes, Lovable shows the live link. To push later changes, open the same dialog and click **Update**. You can also publish from chat. Ask Lovable to **publish**, **deploy**, **ship**, or **go live**, and the agent handles the deploy while respecting your workspace settings. See [Publish from chat](#publish-from-chat). ## Who can publish projects? By default, **editors and above** can publish projects on all plans. On **Enterprise plans**, admins and owners can restrict who is allowed to publish externally to the web. Go to **Workspace settings → Privacy & security → Who can publish externally** and select: * Admins & owners * Owners only ## Internal and external publishing and website access control Publishing options and website access control depend on your plan. ### Free and Pro plans **Anyone with the link** can visit your published app. This means you publish externally to the web. **Website access** cannot be restricted on these plans, so make sure you’re ready to share before publishing. ### Business and Enterprise plans You can choose who can access your published app under **Who can see this website** in the publish dialog: * **Public**: Anyone with the URL can visit your published app, meaning you publish externally to the web. * **Workspace** (shown with your workspace name): Only workspace members can visit the published app after signing in, meaning you publish internally to the workspace. * **Custom**: You compose the exact audience: the whole workspace, [groups](/features/groups), individual members, and people outside your workspace invited by email. See [Invite people outside your workspace](#invite-people-outside-your-workspace). This allows you to: * 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 * Prevent accidental external publishing * Support governance and compliance for sensitive data Audience edits are saved as a draft first: who can access the site doesn't change while you edit. When you select **Publish**, **Update**, or **Save changes**, Lovable updates who has access and sends any invite emails. Workspace admins and owners can also set a **default website access** policy for all published projects in **Workspace settings → Privacy & security → Default website access**. 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. ### Invite people outside your workspace On the Business and Enterprise plans, 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. In the publish dialog, under **Who can see this website**, select **Custom**, then select **View and edit** on the Custom card. 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 a note such as *Shared with 2 external people* appears below the Custom card. If the workspace has turned off external invites, the email option doesn't appear. Select **Done** to close the picker, then **Publish**, **Update**, or **Save changes**. Lovable then sends each invited person an email and updates who has access. Until you select one of these three buttons, invites stay in draft 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 sign 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. Keep in mind: * Invites don't expire. Removing someone from the audience revokes their access when you apply the change, and re-inviting an address sends a fresh email. * Workspace members can't be invited as external viewers. Add them through the workspace, people, or group options instead. * You can add up to 10 email invites per update, and each address can receive at most 10 invite emails per day. * Workspace admins and owners can turn off external invites for the whole workspace with the [External invites](/features/privacy-and-security-settings#external-invites) setting in **Settings → Security → Privacy & security**. People who were already invited keep their access. * [Workspace insights](/features/workspace-insights) flags internally published projects that have external viewers, so admins can review who has access. ## Publish from the Publish dialog To publish, follow the steps below: In your project, click the **Publish** icon in the top-right corner. Review and configure the publish settings as explained below. When the publish dialog opens, Lovable automatically runs a [Basic security scan](/features/security) in the background while you configure the rest of the settings. This scan takes 10-15 seconds and checks your database for common security issues, including row-level security (RLS) policy mistakes and schema-level access control risks. * Enter your preferred website URL or leave the input field empty for Lovable to auto-generate a URL. By default, your app is published to `[published-url].lovable.app` 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 → Branded app URLs**. See [Publish apps with branded URLs](/features/branded-workspace-urls) to set this up. * When published, you can add a [custom domain](/features/custom-domain) (available on paid plans). 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 signed-in workspace members can visit the published app (private website access) * **Custom** (Business and Enterprise plans): grant access to the whole workspace, specific people, [groups](/features/groups), or people outside your workspace invited by email. See [Invite people outside your workspace](#invite-people-outside-your-workspace). Audience edits are saved as a draft first. When you select **Publish**, **Update**, or **Save changes**, Lovable updates who has access and sends any invite emails. Lovable provides **site metadata**, but you can customize how your site appears in browser tabs, search results, and link previews. Add the following info to help people find your site: * **Icon & title**: the site icon (**favicon**) and **site title** shown in browser tabs, search results, and link previews. * Click on the icon to upload a new one. * Click on the title text to update it. * **Description**: the **meta description** used in search results and link previews. * Click on the text to update it, or leave empty and Lovable will auto-generate a description. * **Social image**: the social sharing image (**OG image**) shown when your website link is shared, for example, on social media and messaging apps. * Click to upload an image or choose to generate one (title and description need to be filled out to generate). See [Optimize your app for SEO and AI search](/features/seo-aeo) for more information on optimizing your Lovable apps for search engines, social media previews, and AI systems. Review all info and optionally run an [SEO review](/features/seo-aeo). Click on any of the fields to update the settings. * URL * Published website visibility * Website info (icon & title, description, social image) Always review security findings before publishing to reduce the risk of data leaks, unauthorized access, and sensitive information exposure. Before you publish, review the outcome of the **Basic scan** that ran automatically in the background. * If the Basic scan finds issues, Lovable shows a warning with a summary of the findings. Click it 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. * If the Basic scan passes, you can continue publishing. You can also run the optional **Deep scan** for additional coverage. The Deep scan is an optional agentic codebase review that usually takes around 4 minutes. It looks for application-code vulnerabilities such as exposed secrets, unsafe input handling, and authorization gaps. If you run the Deep scan, Lovable shows either a warning with any findings, or a `Basic & Deep security scans passed message` when both scans complete with no findings. In either case, you can continue publishing unless your workspace has stricter publishing controls enabled. See [Security overview](https://docs.lovable.dev/features/security) and [Project security view](https://docs.lovable.dev/features/security-view) for more information. **Publishing controls** Workspace admins and owners can enforce stricter publishing rules in **Workspace settings → Privacy & security** to help ensure insecure applications are never deployed. * **Block publishing with critical findings** prevents publishing while error-level findings are unresolved. * **Require security scan before first publish** prevents the first publish of a project until a security scan has completed. When ready, click **Publish**. When the deployment is complete, you'll receive a pop-up with the published link. After publishing your project, you can continue to iterate on it. To push updates later, click **Publish → Update**. When published, you can update your live app at any time, change the website address (published URL), or connect a [custom domain](/features/custom-domain) for a polished, on-brand experience. After publishing publicly, rerun your [SEO review](/features/seo-aeo) to unlock live checks for indexing, performance, accessibility, AI-search readiness, and Google Search Console setup. If you connect a custom domain, rerun the review again so Lovable can help verify your domain in Google Search Console and submit your sitemap. ## Publish from chat You can also ask the Lovable agent to publish for you instead of opening the Publish dialog. Try prompts like: ```text wrap theme={null} Publish my app ``` ```text wrap theme={null} Deploy this project ``` ```text wrap theme={null} Ship it ``` ```text wrap theme={null} Go live ``` To request a specific Lovable subdomain: ```text theme={null} Publish to my-todos.lovable.app ``` The agent respects all publish-related workspace settings and permissions. It checks your publish settings, confirms required page information (such as title, description, and social image), runs the same [security checks](/features/security) used by the Publish dialog, and schedules the deploy. Lovable asks for approval before publishing unless you have set the publish tool to auto-approve. For related settings such as changing visibility, connecting a [custom domain](/features/custom-domain), or unpublishing, the agent points you to the right place in the UI. Publishing from chat is treated as standard chat usage and consumes credits. ## How publishing works in Lovable Each time you publish, Lovable deploys a snapshot of your project to a live URL. Only the current version is deployed, and future changes are not automatically published. * Changes are not automatically published and pushed live. * To deploy new changes, click **Publish → Update**. If you don’t see recent changes on your live site, you need to republish. ### See when you have unpublished changes 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 two ways: * Go to **Project settings → Unpublish project → Unpublish** * Click **Publish → Edit settings → Unpublish** (top-right corner) Once unpublished: * The live URL becomes inaccessible * Your project remains in the editor ## FAQ Yes. Ask Lovable to publish, deploy, ship, or go live, and the agent handles the deploy for you while respecting all publish-related workspace settings and permissions. It checks your publish settings, confirms required page information, runs the same [security checks](/features/security) used by the Publish dialog, and schedules the deploy. You can also request a specific Lovable subdomain, such as `my-todos.lovable.app`. Lovable asks for approval before publishing unless you have set the publish tool to auto-approve. For related actions such as changing visibility, connecting a [custom domain](/features/custom-domain), or unpublishing, the agent points you to the right place in the UI. Publishing from chat is treated as standard chat usage and consumes credits. No. A published site stays live indefinitely. There is no expiry and no automatic unpublishing for inactivity. Only [share preview links](/features/share-project) expire, after 7 days. Apps that use the built-in backend (Cloud) or AI features do need available credits to serve requests. 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 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 (Cloud) consumes Run credits as your app is used, and asking the agent to publish in chat counts as a standard chat message. Your published app stays live. Downgrading or canceling does not unpublish your project. * **Website access settings keep working.** If you restricted access to workspace members or selected people on a Business plan, the published app keeps requiring sign-in after a downgrade. The setting is enforced as stored. After a downgrade you can still change the setting to public access, which is available on all plans. Restricting access to workspace members or selected people requires a Business or Enterprise 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?](/features/custom-domain#what-happens-to-my-custom-domain-if-i-downgrade-or-cancel-my-plan) * **Apps that use the built-in backend (Cloud) or AI features still need available credits** to serve requests. See [Credits and usage](/introduction/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, chat history, and unpublished changes is always controlled by [project access](/features/project-visibility). 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, 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. Below are common configurations: 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 can view and edit the project in the editor, but anyone with the published URL link can visit the published app. Keep in mind that workspace owners have full access to **all** projects in the workspace and can view and edit them. 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 link can visit the published app. 4. **Private prototype shared internally** * Project access: `Restricted` * Website access: `Workspace` **Result:** Only you can view and edit the project in the editor, and only workspace members can visit the published app. Keep in mind that workspace owners have full access to **all** projects in the workspace and can view and edit them. **Key reminder:** 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 Business and Enterprise plans you can restrict who can access your published app. Under **Who can see this website** in the publish dialog, choose your workspace to publish internally, or choose **Custom** to compose the audience: the whole workspace, specific people, [groups](/features/groups), and people outside your workspace invited by email. See [Invite people outside your workspace](#invite-people-outside-your-workspace). Invite them by email from the **Custom** audience in the publish dialog. When you select **Publish**, **Update**, or **Save changes**, 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 sign 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. Re-inviting the same address doesn't send duplicate emails, and workspace members can't be invited as external viewers. Publishing deploys a snapshot. Changes aren't automatically pushed to your live app. To publish updates, click **Publish** and then **Update**. You can customize how your site appears in browser tabs, search results, and link previews. By default, Lovable generates site metadata, adds a Lovable logo as the favicon, and a screenshot of your app as the Open Graph (OG) image. To change this, click **Publish** and review and configure the **website info**, and optionally run an [SEO review](/features/seo-aeo): * **Icon & title**: the site icon (favicon) and page title shown in browser tabs, search results, and link previews. Click on the icon to upload a new one. Click on the page title text to update it. * **Description**: the meta description used in search results and link previews. Click on the text to update it. * **Share image**: the social sharing image (OG image) shown when your website link is shared, for example, on social media and messaging apps. Click to upload an image. See [Optimize your app for SEO and AI search](/features/seo-aeo) for more information on optimizing your Lovable apps for search engines, social media previews, and AI systems. You can change your project **URL subdomain**, which forms your [lovable.app](http://lovable.app) website address in two ways: 1. Click **Publish → Edit settings → URL**, edit your subdomain, save the change, and click **Done**. 2. Go to [**Project settings → URL subdomain**](/features/projects/settings#details), change the subdomain, and click **Update URL subdomain**. Note that renaming the project does not change the project URL, it only changes the project display name. On paid plans, you can also add a [custom domain](/features/custom-domain). When a publish fails, Lovable shows a **Publishing failed** message explaining what went wrong, along with the action to take: **Try again** for temporary issues, or **Try to fix** to have the agent investigate an error in your app. See [Troubleshooting](/features/publish#troubleshooting) for each failure type and how to resolve it. If the **Publish** button is disabled instead, your workspace admin or owner probably enabled a publishing control in **Workspace settings → Privacy & security**: * **Block publishing with critical findings** prevents publishing while error-level findings are unresolved. Open the Security view, fix them, and try again. * **Require security scan before first publish** prevents the first publish of a project until a security scan has completed. Wait for the scan that started when you opened the publish dialog to finish, or run a scan from the Security view. Yes, especially if your site is public. Some SEO checks only run against the live published site, including indexing, performance, accessibility, AI-search readiness, and Google Search Console setup. After publishing, run an [SEO review](/features/seo-aeo) 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](/features/custom-domain)). There isn't a built-in flow that packages and submits your project to the App Store or Google Play, but you have two good 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](https://capacitorjs.com/) 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, push notifications, biometrics, etc.) or when a store requires a "real" native binary. The separate [Lovable mobile app](/integrations/lovable-mobile-app) is for **building** projects from your phone. It does not turn your project into a native app for end users. ## Troubleshooting When a publish fails, a **Publishing failed** banner appears in the Publish dialog with a message explaining what went wrong and how to resolve it. The agent is also notified about the failure, so you can ask it for help in chat. The publish hit 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. The agent investigates and applies a fix, and you can publish again when it's done. You can also describe the issue to the agent in chat. If the fix request can't be sent right away, for example because you hit a rate limit, the banner stays visible so you can try again. A configuration problem inside your project blocked the publish, for example a file that is too large to include. **What to do:** Click **Try to fix** in the banner. The agent 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 the agent can't change for you, such as an expired [Supabase](/integrations/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 in this publish conflicts with data that already exists in your live app's database. **What to do:** Click **Ask the assistant to help** in the banner. Because the fix affects real data, the agent 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](https://lovable.dev/support) and include your project link. Publish failure messages never include raw logs or output from connected services, so secrets and connection details stay out of the UI. Build errors are the exception: the banner shows a summary of the build failure so you can act on it.