Skip to main content
When you publish an app, it goes live on its built-in environment: the latest published version starts serving your web app and API right away. You can also run the app in more separate environments (created in the Enterprise Dashboard), such as staging and production, each serving the version you deploy there. These environments are isolated from each other, with their own model and integration credentials, environment variables, and access settings. Your end users can keep using a stable version in production while you test the next one in staging.

​
How Deployment Works

Deployment starts with a publish: each publish creates a version, a snapshot of the app at that moment. Deploying pins a version to an environment. When deploying an app, you choose the version, provide the credentials and environment variable values the app uses there, and the environment serves that version until you deploy another: a newer one to update it, or an earlier one to roll back. For example, you might publish a version named v1.2 and deploy it to staging to test it. Once it’s verified, you deploy the same v1.2 to production. Later publishes keep flowing into built-in, but production stays on v1.2.

​
What You Can Deploy

These limits apply only to deployed environments. A version that doesn’t fit can’t be deployed.

​
Who Can Deploy

Deploying and undeploying an app require the Deploy app permission. The workspace Owner, Admins, Editors, and the app’s creator have it by default. Other members can hold it through a custom role or a per-app exception. Changing a deployed app’s access points requires both View access points and Manage access points. The workspace Owner, Admins, and the app’s creator have them by default; Editors and other members need Manage access points through a custom role or a per-app exception.