Publish an app

Publish, tag, and restore app versions.

By default, all apps are created in your Drafts folder in an unpublished state. In order for other users to see and use your app, you must publish it.

You must be a builder to publish an app. Internal users can create apps, but they cannot publish them.

note

If you prefer to use Source Control to manage changes to your apps, refer to the Source Control guide.

Publish your app

To publish your app, click Publish in the top right corner of the app builder. Complete the following steps in the modal that appears:

1. Review the Publish checklist. Retool performs several checks to ensure that your app is ready to publish:
   • All functions are approved. If there are unapproved functions, click Review functions to view the functions that still need approval.
   • Your changes do not conflict with the published version or changes from other users. If there is a new published version of your app, click Integrate changes to ask the agent to resolve the conflict.
2. Define a descriptive name for the App URL.
   • For cloud instances without custom domains, URLs are constructed in the following format: <orgSubdomain>--<appName>.retool.app.
   • For self-hosted instances or cloud instances with custom domains, URLs are constructed in the following format: https://example.retool.com/rr/app/<appName>.
3. Choose the folder in which you want your published app to be available, and confirm your selection. All users with use access to the folder you select will be able to use your app.
4. Optionally, expand Tags & publishing and choose whether you want to tag these changes as a new release. By default, the changes are not tagged. Learn more about release tagging.
5. Click Publish.
6. Click Copy link to copy the link to your published app.
7. Once you publish your app, your branch is considered archived. You can unarchive the branch by continuing to prompt in the thread, or create a new branch to continue iterating on your app.

Tag changes as a release

By default, published changes to your app are visible to all users who have View access to that app. Leverage release tagging to apply semantic versioning to your app releases, and configure publishing behavior to show users a particular release.

During publishing

1. While publishing your app, expand the Tags & publishing section.
2. Choose whether you want to tag your changes as a Major, Minor, or Patch release.
3. In response to Which tag should be pinned for publishing?, choose:

• Latest changes: The latest published changes are automatically shown to app users.
• Current tag: The currently published tag will remain published.
• This tag: These changes will be tagged as a new release, and all end users of your app will see this version.

From Version History

1. Click to open the Version History pane. Switch to the Publish History tab, which shows all published versions.
2. Find your desired published version, and click the icon.
3. In the Tag changes modal that opens, choose whether you want to tag your changes as a Major, Minor, or Patch release.
4. In response to Which tag should be pinned for publishing?, choose:

• Latest changes: The latest published changes are automatically shown to app users.
• This tag: These changes will be tagged as a new release, and all end users of your app will see this version.

5. Click Tag changes.

Configure publishing behavior

After tagging changes as a release, you can configure your app's publishing behavior from the footer of the Version History > Publish history tab at any time. In response to Which tag should be pinned for publishing?, choose:

• Always publish latest changes: The latest published changes are automatically shown to app users.
• Select from a list of tagged releases.

Restore a previous version

You can restore a previous version of your app to your current thread. Restoring enables you to continue making changes from that version. You can restore a published app version, or you can revert to a certain point in an existing thread.

Restore published version

To restore a published version to your thread, use the following steps:

1. Ensure that there's an open thread in the Chat tab.
2. In the navbar, click to open the Version History pane. Switch to the Publish history tab, which shows all published versions.
3. Find your desired published version, and click Restore. After a few moments, the preview canvas updates to show that version of the app. The older version is restored to your thread only—the published version remains the same.
4. You can then make any further changes to your app, and publish when you're ready.

Restore from Chat tab

While prompting from the Chat tab, you can restore the app to a previous state in your current thread. Each time the agent finishes making changes, it presents a summary of the changes and a Restore button. Click this button to return your app to the state it was in when the agent finished those changes.

You can then make any further changes to your app, and publish when you're ready.

Capabilities and limitations

The following tabs show a summary of the current capabilities of the app builder. Limitations describe functionality that isn't yet supported in apps but may exist in classic apps.

Capabilities

• Publish an app to a specific folder in the organization.
• Define a custom App URL for each published app.
• Use the Publish checklist to confirm there are no conflicts and that all functions are approved.
• Restore a previous version of an app from the Publish history.
• External users (who have email domains from outside your organization) can view published apps.
• URL parameters.
• Publish an app on a custom domain. Refer to Publishing on custom domains for more information and limitations.

Limitations

Some functionality is not currently supported:

• Embedded apps in external websites or applications.
• Public links to apps.
• Exported apps for use outside of Retool.
• Shared draft apps before publishing.
• Custom pages, landing pages, or user actions.

Publishing on custom domains

If you self-host Retool (which uses domains you define) or use a custom domain on a cloud instance, your apps are published to the domain you define in the following format: https://example.retool.com/rr/app/<appName>.

In these scenarios, Retool runs your app inside a sandboxed iframe with allow-same-origin disabled. This provides additional security to isolate published apps from your Retool instance. However, because of this security mechanism, there are certain limitations that apply to published apps on custom domains.

Browser feature limitations

The sandbox has no persistent origin, so features that depend on storage, cookies, service workers, or device access are unavailable:

Category	Unavailable
Storage & cookies	localStorage, sessionStorage, IndexedDB, Cache API, persistent/Storage Access APIs. Cookie reads return empty and writes are ignored. Cookies aren't attached to the app's requests.
Background & coordination	Service Workers (and everything built on them, such as Push, Background Sync/Fetch, PWA install), BroadcastChannel, SharedWorker, Web Locks, Notifications.
Identity	WebAuthn/passkeys, Credential Management, FedCM, Web OTP, Cookie Store.
Media & clipboard	Camera, microphone, screen capture (getUserMedia, getDisplayMedia), DRM playback (EME), clipboard reads.
Files & windows	File System Access dialogs, top-level navigation (top.location), parent/top window access.
Hardware	WebUSB, Web Serial, WebHID, Web Bluetooth, Web MIDI, motion/environment sensors, Gamepad, WebXR.
Other	Payment Request/Handler, Web Share, Contact Picker, Idle Detection, Window Management, Local Font Access.

Widgets that rely on their own cookies, storage, or login session (such as Stripe Checkout, Calendly, embedded OAuth/SSO dialogs, and reCAPTCHA) may render, then fail when their storage is unavailable. This applies to any nested frame, regardless of origin. To present this content, builders should instead create resources, which are supported and leverage Retool's native authentication mechanics.

Next steps

Next, share your app with other users in your organization.