> ## Documentation Index
> Fetch the complete documentation index at: https://enterprise-docs.dify.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> Learn how deployment works, what can be deployed, and who can deploy

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

| | Supported |
| :- | :- |
| App types | Workflow (starting with User Input) and Chatflow |
| Nodes | **All nodes except** Knowledge Retrieval, Agent, Human Input, and Triggers |
| Integrations | Model providers, tool plugins, and workflows published as tools. Custom API tools, MCP tools, and built-in tools (Audio, Code Interpreter, CurrentTime, and WebScraper) aren't supported. |

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](/en/3.13.x/use/workspace/roles-and-permissions).

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.