---
title: "Publish your RShift Sites project"
description: "Deploy your project to a live URL, control who can access the published app, configure site metadata, and update or unpublish at any time."
image: "https://help.rshift.com/og.svg"
---

> Documentation Index
> Fetch the complete documentation index at: https://help.rshift.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Publish your RShift Sites project

&lt;head>
  &lt;script type="application/ld+json">
    &#123;`{"@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [{"@type": "Question", "name": "Can I publish by asking RShift Sites in the project chat?", "acceptedAnswer": {"@type": "Answer", "text": "Yes. Ask RShift Sites to publish, deploy, ship, or go live, and it handles the deploy for you while respecting all publish-related workspace settings and permissions. It checks your publish settings, runs the same security checks used by the Publish dialog, and schedules the deploy. You can also request a specific RShift Sites subdomain, such as my-todos.lovable.app. RShift Sites asks for approval before publishing unless you have set the publish tool to auto-approve. You can also ask RShift Sites 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."}}, {"@type": "Question", "name": "Does my published site expire?", "acceptedAnswer": {"@type": "Answer", "text": "No. A published site stays live indefinitely. There is no expiry and no automatic unpublishing for inactivity. Only share preview links expire, after 7 days by default. Apps that use the built-in backend (Cloud) or AI features do need available credits to serve requests."}}, {"@type": "Question", "name": "Where is the Publish button?", "acceptedAnswer": {"@type": "Answer", "text": "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 RShift Sites in the project chat to publish your app."}}, {"@type": "Question", "name": "Does publishing cost credits?", "acceptedAnswer": {"@type": "Answer", "text": "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 RShift Sites to publish in the project chat is treated as standard build usage and consumes credits."}}, {"@type": "Question", "name": "What happens to my published app if I downgrade or cancel my plan?", "acceptedAnswer": {"@type": "Answer", "text": "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. You can still change the setting to public access on any plan, but restricting access requires a Business or Enterprise plan. On a Free or Pro plan, RShift Sites does not publish changes to an app that is published to your workspace or to a custom audience. When you select Publish changes, RShift Sites shows the message Publish to workspace requires a Business plan and the live version stays online. To publish your changes, change website access to Public first, or upgrade to a Business plan. You can still 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 RShift Sites are billed separately from your subscription. Apps that use the built-in backend (Cloud) or AI features still need available credits to serve requests."}}, {"@type": "Question", "name": "Does publishing expose my project and code?", "acceptedAnswer": {"@type": "Answer", "text": "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."}}, {"@type": "Question", "name": "How do project access and website access work together?", "acceptedAnswer": {"@type": "Answer", "text": "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. Below are common configurations: 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. 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. 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. 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."}}, {"@type": "Question", "name": "Can I restrict who can access my published app?", "acceptedAnswer": {"@type": "Answer", "text": "Yes, on Business and Enterprise plans you can restrict who can access your published app. In the publish dialog, select the visibility row to open Who can view your site?, then choose your workspace to publish internally, or choose Custom to compose the audience: the whole workspace, specific people, groups, and people outside your workspace invited by email."}}, {"@type": "Question", "name": "How do people outside my workspace get access to my internally published app?", "acceptedAnswer": {"@type": "Answer", "text": "Invite them by email from the Custom audience 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 RShift Sites also get an in-app notification. To open the site, they sign in with the invited email address, or create a RShift Sites 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."}}, {"@type": "Question", "name": "Why don't I see my latest changes on the live site?", "acceptedAnswer": {"@type": "Answer", "text": "Publishing deploys a snapshot. Changes aren't automatically pushed to your live app. To publish updates, click Publish and then Publish changes."}}, {"@type": "Question", "name": "How do I change my site metadata such as favicon, site title, meta description, or OG image?", "acceptedAnswer": {"@type": "Answer", "text": "You can customize how your site appears in browser tabs, search results, and link previews. RShift Sites generates your site metadata while it builds your app: the site title, meta description, and site icon (favicon). The social sharing Open Graph (OG) image is chosen when your site is served: RShift Sites uses an image you've asked it to set, or the latest screenshot of your app, and sites that aren't publicly visible don't get an automatic one. Metadata is set per page: RShift Sites generates unique values for each page of your app based on its content. To see how any page looks when shared and in search results, check its Social and Search cards in the page selector above the preview. To open the cards from the Publish dialog, select Social & search appearance in the menu, or click the favicon next to the website URL. Right after you publish, you can also click Edit next to your site's title on the Your website is live screen. To change any of it, ask RShift Sites in the project chat, for example: Change my site title, write a new meta description, or generate a new social sharing image. Metadata edits are treated as standard build usage and consume credits, like any other build request. Like any other edit, a metadata change reaches your live site on the next publish. When the project is already published, RShift Sites ends its reply with a Publish to update the live site button so you can publish from the project chat. See Optimize your app for SEO and AI search for more information on optimizing your RShift Sites apps for search engines, social media previews, and AI systems."}}, {"@type": "Question", "name": "How do I change my published URL (website address)?", "acceptedAnswer": {"@type": "Answer", "text": "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. On a first publish, you can also edit the URL directly in the Website URL field of the publish dialog before you publish. 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."}}, {"@type": "Question", "name": "Why can't I publish my RShift Sites project?", "acceptedAnswer": {"@type": "Answer", "text": "When a publish fails, RShift Sites 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 RShift Sites investigate an error in your app. If the Publish button is disabled instead, there are two common causes. The button shows You don't have permission to publish this project when you hover it: publishing needs editor access or above, and on Enterprise plans workspace admins and owners can restrict publishing further. Or your workspace admin or owner enabled Block publishing with critical issues in Settings → Security → Privacy & security, which prevents publishing while error-level findings are unresolved. Open the Security view, fix them, and try again."}}, {"@type": "Question", "name": "Why isn't my published app live at my URL?", "acceptedAnswer": {"@type": "Answer", "text": "First check that the publish finished: the dialog confirms Your website is live when the deploy completes, and shows a Publishing failed message when it didn't. 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."}}, {"@type": "Question", "name": "Should I run an SEO review after publishing?", "acceptedAnswer": {"@type": "Answer", "text": "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 RShift Sites can re-check the new host, verify Google Search Console, and submit your sitemap."}}, {"@type": "Question", "name": "Can I publish my project as a native iOS or Android app to the App Store or Play Store?", "acceptedAnswer": {"@type": "Answer", "text": "RShift Sites builds web apps and publishing always deploys to a web URL (for example, yourproject.lovable.app or your 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 outside of RShift Sites, 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. RShift Sites does not generate projects in React Native, a developer framework for building native mobile apps. If you need a React Native app, use RShift Sites to prototype your app's screens and flows in the browser, then rebuild them with React Native outside of RShift Sites. The separate RShift Sites mobile app is for building projects from your phone. It does not turn your project into a native app for end users."}}]}`&#125;
  &lt;/script>
&lt;/head>

Publishing turns your RShift Sites project into a live web app by deploying a snapshot to a URL you can share. RShift Sites [hosts the published app](/sites/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

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

**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.

**Click Publish again**

The dialog suggests a website address ending in `lovable.app` and runs a basic security scan. Keep the defaults and click **Publish**, or adjust the address and [audience](#who-can-see-your-published-app) first. When the deploy finishes, RShift Sites shows your live link.

    RShift Sites generates your site title, description, and icon while it builds your app. To change them, ask RShift Sites in the project chat. To check how each page appears in link previews and search results, see [Site metadata is generated for you](#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 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](/sites/tips-tricks/launch-on-a-custom-domain/).

## Publish from the project chat

You can also ask RShift Sites to publish a project you can edit from [Chats](/sites/features/chats/#plan-test-or-publish).

You can also ask RShift Sites in the project chat to publish for you instead of opening the Publish dialog. Try prompts like:

```text
Publish my app
```

```text
Deploy this project
```

```text
Ship it
```

```text
Go live
```

To request a specific RShift Sites subdomain:

```text
Publish to my-todos.lovable.app
```

RShift Sites respects all publish-related workspace settings and permissions. It checks your publish settings, runs the same [security checks](/sites/features/security/) used by the Publish dialog, and schedules the deploy.

RShift Sites asks for approval before publishing unless you have set the publish tool to auto-approve. You can also ask RShift Sites in the project chat to change who can see your site or connect a [custom domain](/sites/features/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](#how-to-unpublish-your-project).

Publishing from the project chat is treated as standard build usage and consumes credits.

## The Publish dialog, step by step

The [quick start](#quick-start-publish-your-first-project) 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.

**Open the Publish dialog**

In your project, click the **Publish** button in the top-right corner. By default, editors and above can [publish projects](#who-can-publish-projects).

    When the publish dialog opens, RShift Sites automatically runs a [Basic security scan](/sites/features/security/) in the background. The scan takes about 10 seconds and covers database misconfigurations, including row-level security (RLS) policy mistakes, plus dependency and connector risks.

**Set your website address**

* On a first publish, 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](/sites/features/projects/settings/#details).

> **Note**
>
> 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 [**Settings → Workspace → Branded app URLs**](https://lovable.dev/settings/workspace). See [Publish apps with branded URLs](/sites/features/branded-workspace-urls/) to set this up.

    * When published, you can add a [custom domain](/sites/features/custom-domain/) (available on paid plans), or change the subdomain later in [**Project settings → URL subdomain**](/sites/features/projects/settings/#details).
    * While RShift Sites 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. RShift Sites publishes your app to the `lovable.app` address until the domain is **Live**. The note disappears if the setup has not progressed for 72 hours.

**Choose who can see the website**

Select the visibility row below the URL (for example, **Visible to anyone with the link**) to open the audience picker. 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](/sites/features/groups/), or people outside your workspace invited by email. See [Invite people outside your workspace](#invite-people-outside-your-workspace).

    Audience edits take effect when you select **Publish** (or **Publish changes** on a published project). See [Who can see your published app](#who-can-see-your-published-app) for how website access works on each plan.

**Check the security scan result**

The dialog shows the outcome of the **Basic scan** on a single line: **No security issues found** when the scan passes, or the number of issues to review.

    * If the scan finds issues, select the row 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.
    * For critical findings, the dialog shows the full scan details and offers 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.

    See [Security overview](/sites/features/security/) and [Project security view](/sites/features/security-view/) for more information.

> **Tip**
>
> **Publishing controls**
>
> Workspace admins and owners can enforce stricter publishing rules in [**Settings → Security → Privacy & security**](https://lovable.dev/settings/privacy-security) to help ensure insecure applications are never deployed. **Block publishing with critical issues** prevents publishing while error-level findings are unresolved.

**Publish your project**

When ready, click **Publish**. When the deployment is complete, RShift Sites confirms **Your website is live** with buttons to copy the link and visit the site, and a preview of how your site appears in search results. Click **Edit** next to your site's title to check or change any page's [social and search appearance](#site-metadata-is-generated-for-you).

    After publishing your project, you can continue to iterate on it. To push updates later, open the dialog again and click **Publish changes**.

> **Tip**
>
> After publishing publicly, rerun your [SEO review](/sites/features/seo-aeo/) to unlock live checks for indexing, AI-search readiness, and Google Search Console setup.
>
> If you connect a custom domain, rerun the review so RShift Sites can help verify your domain in Google Search Console and submit your sitemap.

## Site metadata is generated for you

RShift Sites 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: RShift Sites 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 RShift Sites in the project chat:

```text
Change my site title to "Acme Task Tracker", write a meta description about team to-do lists, and generate a new social sharing image.
```

> **Note**
>
> Metadata is set per page, not once for the whole site. RShift Sites generates a unique title and description for every page of your app based on its content, and a page can have its own social sharing image too. That is why viewing and changing metadata goes through chat, where you can also target a specific page, for example: "Update the meta description of the pricing page."

Metadata edits are treated as standard build usage and consume credits, like any other build request. Like any other edit, a metadata change reaches your live site on the next publish. When the project is already published, RShift Sites 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](/sites/features/projects/preview/#preview-controls) 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.
* Right after you publish, the **Your website is live** screen previews how your site appears in search results. Click **Edit** next to your site's title to open the **Social** and **Search** cards in the page selector.

See [Optimize your app for SEO and AI search](/sites/features/seo-aeo/) for more information on optimizing your RShift Sites apps for search engines, social media previews, and AI systems.

## Republish to make new changes live

Each time you publish, RShift Sites deploys a snapshot of your project to a live URL. Only the current version is deployed, and later changes are not automatically pushed live: when you keep working on a published project, republish to update your live app. To deploy new changes, click **Publish**, then **Publish changes**.

Accepting a [draft](/sites/features/drafts/) 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:

* Go to [**Project settings → Unpublish project → Unpublish**](/sites/features/projects/settings/#publishing)
* Click **Publish**, open the **⋮** menu in the top-right corner of the dialog, and select **Unpublish**
* Unpublish several projects at once from the [dashboard](/sites/introduction/dashboard-overview/#select-several-projects-at-once): select the published projects, then click **Unpublish** in the toolbar and confirm

Once unpublished:

* The live URL becomes inaccessible
* Your project remains in the editor

## 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 [**Settings → Security → Privacy & security → Who can publish externally**](https://lovable.dev/settings/privacy-security) and select:

* **Editors and above** (the default)
* **Admins and owners**
* **Owners only**

Only a workspace owner can select **Owners only** or change away from it.

## Who can see your published app

Website access control depends on your plan.

### Free and Pro plans

**Anyone with the link** can visit your published app: publishing is always external to the web. You cannot restrict website access 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 from the visibility row in the publish dialog, which opens the **Who can view your site?** picker:

* **Public**: Anyone with the URL can visit your published app. This is external publishing.
* **Workspace** (shown with your workspace name): Only workspace members can visit the published app after signing in. This is internal publishing.
* **Custom**: You compose the exact audience: the whole workspace, [groups](/sites/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 don't take effect while you edit. When you select **Publish** (or **Publish changes** on a published project), RShift Sites 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 [**Settings → Security → Privacy & security → Default website access**](https://lovable.dev/settings/privacy-security).

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 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.

**Open the audience picker**

In the publish dialog, select the visibility row to open **Who can view your site?**, select **Custom**, then select **View and edit** on the Custom card.

**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 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. If the workspace restricts external invites to your company's [verified domains](/sites/features/privacy-and-security-settings/#who-can-receive-external-invites), addresses on other domains show **Only verified-domain emails can be invited** and can't be added.

**Publish your changes**

Select **Done** to close the picker, then **Publish** (or **Publish changes** on a published project). RShift Sites 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 RShift Sites, 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 RShift Sites 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](/sites/features/privacy-and-security-settings/#external-invites) setting in [**Settings → Security → Privacy & security**](https://lovable.dev/settings/privacy-security). People who were already invited keep their access.
* Admins and owners can also restrict external invites to your company's [verified domains](/sites/features/verified-domains/) with the [Who can receive external invites](/sites/features/privacy-and-security-settings/#who-can-receive-external-invites) setting. Other addresses can't be added, and the picker shows why.
* [Security insights](/sites/features/security-insights/) flags internally published projects that have external viewers, so admins can review who has access.

## Trust center

Externally published apps can also have a [Trust center](/sites/features/trust-center/): a security page RShift Sites 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

**Can I publish by asking RShift Sites in the project chat?**

Yes. Ask RShift Sites to publish, deploy, ship, or go live, and it handles the deploy for you while respecting all publish-related workspace settings and permissions. It checks your publish settings, runs the same [security checks](/sites/features/security/) used by the Publish dialog, and schedules the deploy. You can also request a specific RShift Sites subdomain, such as `my-todos.lovable.app`.

    RShift Sites asks for approval before publishing unless you have set the publish tool to auto-approve. You can also ask RShift Sites in the project chat to change who can see your site or connect a [custom domain](/sites/features/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](#how-to-unpublish-your-project).

    Publishing from the project chat is treated as standard build usage and consumes credits.

**Does my published site expire?**

No. A published site stays live indefinitely. There is no expiry and no automatic unpublishing for inactivity. Only [share preview links](/sites/features/share-project/) expire, after 7 days by default. Apps that use the built-in backend (Cloud) or AI features do need available credits to serve requests.

**Where is the Publish button?**

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 RShift Sites in the project chat to publish your app.

**Does publishing cost credits?**

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 RShift Sites to publish in the project chat is treated as standard build usage and consumes credits.

**What happens to my published app if I downgrade or cancel my plan?**

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.
    * **You can't publish changes while access stays restricted.** On a Free or Pro plan, RShift Sites does not publish changes to an app that is published to your workspace or to a custom audience. When you select **Publish changes**, RShift Sites shows the message **Publish to workspace requires a Business plan** and the live version stays online. To publish your changes, change website access to **Public** first, or upgrade to a Business plan. You can still 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 RShift Sites 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?](/sites/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](/sites/introduction/credits-and-usage/).

**Does publishing expose my project and code?**

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](/sites/features/project-visibility/).

**How do project access and website access work together?**

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.

    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.

> **Note**
>
> 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.

> **Note**
>
> Keep in mind that workspace owners have full access to **all** projects in the workspace and can view and edit them.

> **Note**
>
> **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.

**Can I restrict who can access my published app?**

Yes, on Business and Enterprise plans you can restrict who can access your published app.

    In the publish dialog, select the visibility row to open **Who can view your site?**, then choose your workspace to publish internally, or choose **Custom** to compose the audience: the whole workspace, specific people, [groups](/sites/features/groups/), and people outside your workspace invited by email. See [Invite people outside your workspace](#invite-people-outside-your-workspace).

**How do people outside my workspace get access to my internally published app?**

Invite them by email from the **Custom** audience 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 RShift Sites also get an in-app notification.

    To open the site, they sign in with the invited email address, or create a RShift Sites 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.

**Why don't I see my latest changes on the live site?**

Publishing deploys a snapshot. Changes aren't automatically pushed to your live app.

    To publish updates, click **Publish** and then **Publish changes**.

**How do I change my site metadata such as favicon, site title, meta description, or OG image?**

You can customize how your site appears in browser tabs, search results, and link previews.

    RShift Sites generates your site metadata while it builds your app: the site title, meta description, and site icon (favicon). The social sharing Open Graph (OG) image is chosen when your site is served: RShift Sites uses an image you've asked it to set, or the latest screenshot of your app, and sites that aren't publicly visible don't get an automatic one. Metadata is set per page: RShift Sites generates unique values for each page of your app based on its content. To see how any page looks when shared and in search results, check its **Social** and **Search** cards in the [page selector](/sites/features/projects/preview/#preview-controls) above the preview. To open the cards from the Publish dialog, select **Social & search appearance** in the **⋮** menu, or click the favicon next to the website URL. Right after you publish, you can also click **Edit** next to your site's title on the **Your website is live** screen.

    To change any of it, ask RShift Sites in the project chat, for example:

```text
Change my site title to "Acme Task Tracker", write a meta description about team to-do lists, and generate a new social sharing image.
```

    Metadata edits are treated as standard build usage and consume credits, like any other build request. Like any other edit, a metadata change reaches your live site on the next publish. When the project is already published, RShift Sites ends its reply with a **Publish to update the live site** button so you can publish from the project chat.

    See [Optimize your app for SEO and AI search](/sites/features/seo-aeo/) for more information on optimizing your RShift Sites apps for search engines, social media previews, and AI systems.

**How do I change my published URL (website address)?**

You can change your project **URL subdomain**, which forms your `lovable.app` website address, in [**Project settings → URL subdomain**](/sites/features/projects/settings/#details): change the subdomain and click **Update URL subdomain**.

    On a first publish, you can also edit the URL directly in the **Website URL** field of the publish dialog before you publish.

    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](/sites/features/custom-domain/).

**Why can't I publish my RShift Sites project?**

When a publish fails, RShift Sites 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 RShift Sites investigate an error in your app. See [Troubleshooting](#troubleshooting) for each failure type and how to resolve it.

    If the **Publish** button is disabled instead, there are two common causes:

    * The button shows **You don't have permission to publish this project** when you hover it: publishing needs editor access or above, and on Enterprise plans workspace admins and owners can restrict publishing further. See [Who can publish projects?](#who-can-publish-projects)
    * Your workspace admin or owner enabled **Block publishing with critical issues** in [**Settings → Security → Privacy & security**](https://lovable.dev/settings/privacy-security). It prevents publishing while error-level findings are unresolved. Open the Security view, fix them, and try again.

**Why isn't my published app live at my URL?**

First check that the publish finished: the dialog confirms **Your website is live** when the deploy completes, and shows a **Publishing failed** message when it didn't. See [Troubleshooting](#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](/sites/features/projects/settings/#details), 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](/sites/features/custom-domain/), DNS changes can take time to take effect.

**Should I run an SEO review after publishing?**

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](/sites/features/seo-aeo/) to check your live site. If you connect a custom domain later, run the review again so RShift Sites can re-check the new host, verify Google Search Console, and submit your sitemap.

**Can I publish my project as a native iOS or Android app to the App Store or Play Store?**

RShift Sites builds **web apps** and publishing always deploys to a web URL (for example, `yourproject.lovable.app` or your [custom domain](/sites/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 RShift Sites, 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.

    RShift Sites does not generate projects in [React Native](https://reactnative.dev/), a developer framework for building native mobile apps. If you need a React Native app, use RShift Sites to prototype your app's screens and flows in the browser, then rebuild them with React Native outside of RShift Sites.

    The separate [RShift Sites mobile app](/sites/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. When the failure is something RShift Sites can help with, it already knows the details, so you can ask for help in the project chat.

**Publishing failed due to a temporary issue**

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.

**Publishing failed because of an error in your app**

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. RShift Sites 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 right away, for example because you hit a rate limit, the banner stays visible so you can try again.

**Publishing failed because of a configuration issue in your project**

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. RShift Sites resolves the configuration problem, and you can publish again when it's done.

**Publishing failed because of an external connection or secret that needs your attention**

The publish failed because of a connection or setting outside your project that RShift Sites can't change for you, such as an expired [Supabase](/sites/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**.

**Publishing failed because a database change conflicts with existing data**

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, RShift Sites confirms with you before changing anything.

**Publishing failed due to an internal error**

The failure happened on RShift Sites' 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.

> **Note**
>
> 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.

## Related topics

- [Work with RShift Sites in the project chat](/sites/features/projects/chat/)
- [Launch your site on a custom domain](/sites/tips-tricks/launch-on-a-custom-domain/)
- [Sync your RShift Sites project code with GitHub, GitLab, or Bitbucket](/sites/integrations/git-sync-overview/)
- [Add payments to your app](/sites/features/payments/)
- [Publish project](https://docs.lovable.dev/api-reference/deploy-domains/publish-project)

Source: https://help.rshift.com/sites/features/publish/index.mdx