Skip to main content

Publish an app

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.

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 function runs 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 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.
    • URLs are constructed in the following format: <orgSubdomain>--<appName>.retool.app.
  3. Choose whether you want to tag this release.
    • Tagging the release means that end users will see this version of the app until a new version is tagged.
    • If you choose not to tag the version, and no other version is tagged, end users will see this version of the app.
    • If you choose not to tag the version, and another version is tagged, end users will continue to see the tagged version.
  4. 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.
  5. Click Publish.
  6. Click to copy the link to your published app.

Once you publish your app, your thread is considered closed, and further prompting is disabled. Create a new thread to continue iterating on your app. Learn more about threads.

Tag a release

To show app users a particular published version of your app, tag a new release using the following steps:

  1. In the navbar, 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 release modal that opens, choose whether you want to tag your release as a Major, Minor, or Patch version. In response to Which version of this app should be published?, choose This tagged release.
  4. Click Tag release.

If you want to return to the default behavior, in which the published app version updates automatically according to your main branch, tag the most recent release. In response to Which version of this app should be published?, choose Latest release.

Restore a previous version

You can restore a previous version of your app to your thread using the following steps:

  1. Start a new 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.

You can then publish the restored version.

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.

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