Deploying turns a published bundle into a running Langflow runtime hosted in a Hybrid Manager (HM) project. Each deployment is an independent workload with its own parameter values, resource configuration, and endpoints.
Starting a deployment
Navigate to Asset Library > Published Flows. In the row for the bundle you want to deploy, select the Deploy icon. The Deploy dialog opens.
You can also reach the same action from Estate > Flows by selecting + Add Flow and choosing the bundle.
Deploy dialog
The dialog has four steps.
Step 1: Configure
| Field | Required | Notes |
|---|---|---|
| Display Name | Yes | Up to 63 characters. Used as the deployed flow's name in the Estate UI and in Kubernetes resource names. |
| Project | Yes | A single project. The drop-down lists only projects where you have permission to create deployed flows. A deployed flow lives in exactly one project. |
| Network Access Type | Yes | Public or private. Determines whether the HM gateway routes for the flow are reachable from outside the HM network. |
| Runtime Configuration | Yes | Settings that apply to the Langflow runtime itself, separate from your flow's parameters (for example, service-level configuration). |
Note that a deployment belongs to exactly one project and cannot be moved after creation.
Select Next to proceed to step 2.
Step 2: Credentials
Every credential parameter in the bundle (any parameter whose Langflow input type is SecretStrInput) is listed here. Each must be set before the deployment can proceed.
Credential values are stored as a Kubernetes Secret in the deployment's namespace and mounted as environment variables into the runtime container. They are not visible after deployment. The Estate UI redacts them.
Non-credential parameters that were given defaults at publish time inherit those defaults, but can be overridden here.
Enter the production value for each credential field — the field name matches the Langflow Global Variable name used in the flow (for example, HM_DB_PASSWORD or HM_API_KEY). The Next button remains disabled until every required field has a value.
Select Next to proceed to step 3.
Step 3: Task Configuration
Set the deployment's resource constraints. The fields surface a subset of the underlying Kubernetes resource model:
| Setting | Default | Range |
|---|---|---|
| Replicas | 1 | 1–5 |
| CPU request / limit | 500m request, 1000m limit | Configurable |
| Memory request / limit | 512Mi request, 1Gi limit | Configurable |
For production workloads, set Replicas to at least 2 so the flow stays available if a pod restarts. If unsure on CPU and memory values, start with the defaults and adjust based on observed usage in Estate > Flows.
Select Next to proceed to the review step.
Step 4: Review
A summary of every setting from steps 1–3, with passwords masked. Before selecting Deploy, confirm that every credential field shows a masked value — a blank field means the credential was not filled in step 2 and the deployment will fail to start. Use Back to return and fill any missing values.
Selecting Deploy submits the deployment. Credential values are written to a Kubernetes Secret immediately and the workload begins reconciling. The new deployment appears in Estate > Flows with status Provisioning. Provisioning typically completes within a few minutes; once the status changes to Ready, the flow's HTTP and MCP endpoints are live.
Understanding deployment resources
Each deployment provisions a set of Kubernetes resources in its own isolated namespace:
| Resource | Purpose |
|---|---|
Deployment | Runs the Langflow runtime container. Replicated per the configured replica count. |
Service | Exposes the runtime's HTTP API and MCP server inside the cluster. The HM gateway routes external traffic to this Service. |
Secret | Holds all parameter values (credentials and non-credentials). Mounted into the runtime container as environment variables. |
ServiceAccount | Pod identity used for secure communication with internal HM services. |
NetworkPolicy | Restricts pod egress to DNS, the HM services the runtime needs at startup, public HTTPS (port 443), and Postgres (port 5432). |
Note
Flows that need to reach hosts on protocols or ports outside the NetworkPolicy's allowlist (DNS, HTTPS/443, Postgres/5432) will fail to connect. Contact your HM administrator if your flow requires additional egress.
At pod startup the runtime downloads the bundle (pinned to the version the deployment was created from) before the HTTP and MCP endpoints become ready. Cold start therefore has a small delay. Subsequent restarts repeat the same download step.
Managing deployments
- Edit deployment parameters. From Estate > Flows, open the deployed flow and edit the parameter values. Saving rewrites the deployment's parameter Secret and triggers a rolling restart of the runtime pods. The runtime re-downloads the bundle at startup (still pinned to the version the deployment was created from).
- Update the bundle version. A deployed flow is pinned to the version it was deployed from. To run a newer version of the same bundle, edit the deployment and change the version, or undeploy and deploy again from the new version. Existing deployments are not auto-upgraded when a new bundle version is published.
- Undeploy. From the Estate UI, delete the deployed flow. HM deletes the deployment's resources, including the Secret holding its parameter values. The HM gateway routes for the flow are removed.
To invoke the deployed flow over HTTP or MCP, see Accessing deployed flows.