Deploying Workflows

Once your workflow is tested, deploy it to make it available for production execution. Deployment provisions dedicated compute for the workflow and (for webhook and schedule triggers) arms its external entry points.

Deployment Process

Step 1: Prepare for Deployment

Before deploying, ensure:

• All nodes are configured correctly
• Workflow has been tested with representative inputs
• Data source credentials are valid
• Required add-ons are running
• AI Gateway models are accessible (if using AI nodes)

Step 2: Configure Deployment

Click the Deploy button in the workflow builder toolbar. The builder first validates the workflow (node configuration and control-flow wiring, for example a loop with no terminating merge) and blocks deployment with actionable errors if anything is misconfigured. It then saves the workflow and opens the deploy dialog:

Setting	Description	Default
Environment	Runtime image the workflow's workers run on. "Default (Strongly workflow-worker image)" or a custom environment	Default
Environment version	Pin a specific version of a custom environment, or follow "Latest"	Latest
CPU (vCPU)	CPU allocation for the worker	0.5
Memory	Memory allocation (1GB to 16GB)	1GB
Disk Space	Disk allocation (1GB to 100GB)	5GB
GPU Count	Number of GPUs (0, 1, 2, 4, 8)	0
GPU Type	Specific GPU type, shown when GPU Count > 0	None

Step 3: Deploy

Click Deploy Workflow. The deployment process:

1. Creates an immutable version snapshot of the workflow (nodes, connections, settings) and marks it as the deployed version
2. Generates STRONGLY_SERVICES dynamically from the workflow's node dependencies (data sources, add-ons, AI models, MCP servers)
3. Resolves the selected environment (default worker image or a built custom environment, honoring a pinned version)
4. Provisions dedicated compute for the workflow
5. Updates the workflow with deployment metadata and sets its status to active

For webhook triggers, the deployed workflow is reachable at /api/v1/webhooks/{workflowId} for external systems to call.

For schedule triggers, the scheduler begins firing at the configured cron interval.

Streaming workflows deploy through a session-based path instead of a persistent worker: capacity scales with active sessions using the streaming autoscaling settings on the workflow (min/max replicas, target sessions per worker, idle timeout, max session duration). Workflow-level CPU/memory are only applied when you set them explicitly in the deploy dialog; otherwise the platform sizes the worker from the nodes in the graph.

Updating a Deployment (Zero Downtime)

If the workflow is already deployed, the toolbar shows Update instead of Deploy. Updating:

1. Creates a new version snapshot (v(N+1))
2. Pushes the new definition and services to the running deployment
3. Rolls the change out in place -- the existing infrastructure is reused, and the workflow keeps serving during the update

The deploy dialog shows "Currently running vN. This will deploy v(N+1) with your latest changes."

Lifecycle Policy

Batch workflows have a Lifecycle Policy (Workflow Settings dialog) that controls how the deployed workflow runs. It affects cost and availability. Streaming workflows do not have a lifecycle policy -- their capacity is session-bound and governed by the streaming autoscaling settings instead.

Policy	Builder description	Behavior
Always On (default)	"Pod runs 24/7. Best for high-traffic workflows."	The workflow stays running continuously
Idle Shutdown	"Auto-stops after idle period. ~10s cold start on next trigger. Best balance of cost and latency."	Stops after the configured idle timeout (5-1440 minutes, default 30) with no executions. Auto-starts on the next trigger
On-Demand	"Always off. Starts on trigger (~10s), stops after execution completes. Lowest cost."	Stopped immediately after deploy; starts when triggered, stops again when no executions remain active
Scheduled Window	"Runs only during configured hours. $0 cost outside window."	Started/stopped automatically based on timezone-aware time windows (days of week + start/end time; multiple windows supported)

When a policy stops a workflow, its deployment status shows Stopped with the reason (for example idle-shutdown, on-demand-complete, scheduled-window). A webhook call to a stopped workflow with one of these policies auto-starts it; while it is starting, callers receive a "Workflow is starting, retry shortly" response.

Stopping scales the deployment to zero but keeps its resources, so restart takes about 10 seconds instead of a full redeploy.

Environments

The deploy dialog's Environment setting selects the runtime image the workflow's workers run on.

Default Environment

The default option runs the platform's standard workflow-worker image with common Python dependencies pre-installed.

Custom Environments

Custom environments (managed in the Environments section) can add system tools or Python packages (for example LibreOffice for legacy .DOC conversion). Only environments that are built from the Strongly workflow-worker image and have finished building can be selected -- the picker filters to those, and the server enforces the same rule on deploy.

You can pin a specific environment version so later edits to the environment never change the image this deployment runs, or follow Latest to always use the environment's newest built version.

A plain redeploy that does not specify an environment keeps the workflow's already-bound environment; it is never silently reset to the default.

GPU Support

For workflows that require GPU resources (for example ML inference, image generation):

1. Set GPU Count to the number of GPUs needed
2. Select the GPU Type
3. The workflow is scheduled on GPU-capable compute

Undeployment

To undeploy a workflow, click Undeploy in the workflow builder toolbar (shown while the workflow is deployed) and confirm. Undeployment:

1. Tears down the workflow's provisioned compute
2. Clears all deployment metadata from the workflow
3. Sets the workflow status back to draft

The workflow definition, version history, and execution history are preserved. For workflows with a schedule trigger, undeploying also disarms the schedule so it stops firing.

Execution Infrastructure

Deployed workflows use pre-provisioned compute for fast execution dispatch. When an execution is triggered, work is dispatched to the workflow's deployment with its runtime environment and dependencies pre-loaded.

STRONGLY_SERVICES

The STRONGLY_SERVICES configuration is generated dynamically for the workflow based on its node dependencies:

• AI Gateway models: Base AI Gateway configuration is always included, plus any explicitly selected models
• Data sources: Database connection details for source/destination nodes
• Add-ons: Add-on service endpoints and credentials
• MCP servers: Tool endpoints for MCP Tools Provider nodes
• Service discovery: Automatically scans workflow nodes and builds the service configuration

If the workflow references services and generation fails, the deploy fails with a clear error rather than deploying without them.

Version Management

Workflows have immutable version snapshots:

• Every deploy creates a new version automatically (v1, v2, v3, ...) capturing the workflow's nodes, connections, and settings at that moment. Production runs the frozen snapshot, not the live editing document.
• Manual versions can also be created from the builder's Version Control dialog (the "Version N" button in the toolbar), which lists versions and supports restore.
• Rollback: any existing version can be deployed directly from the Version Control dialog without modifying your current draft.

The toolbar shows the current version and, when deployed, a "vN deployed" badge.

Sharing

Share Workflow

Workflows are shared with individual users:

• The workflow owner has full access
• Shared users have read and write access -- there are no granular permission levels (Viewer/Editor/Admin)
• In multi-tenant mode, sharing is restricted to users in the same organization
• Unsharing removes the user's access; the list of shared users is visible to anyone with access to the workflow

Public Workflows

Workflows can be marked public to make them visible to all users in the organization.

Cloning

Cloning a workflow (the clone action in the workflow list) creates an independent copy:

• Deep-copies nodes, connections, and settings
• Names it "<name> (Copy)" unless you provide a name
• Resets status to draft and clears all deployment metadata
• Sets the current user as owner and resets sharing to empty
• Resets execution stats to zero
• Preserves tags from the source workflow

Templates

A workflow can be saved as a reusable template. Templates keep a reference to their source workflow and are excluded from normal execution. Creating a workflow from a template copies the template's nodes, connections, and settings into a new draft owned by you; you can customize the name, description, and tags at creation time. Templates respect the same access control as regular workflows (owned, shared, or public templates are visible).

Monitoring Executions

Execution List

View executions for a workflow:

1. Navigate to Workflow Monitor
2. Click a workflow to open its Execution History
3. Filter by status, execution type, or date range

Each execution shows its ID, status (pending, running, completed, failed), start and end time, and duration.

Execution Details

Open an execution's trace to view:

• Span tree: Hierarchical view of all node execution traces
• Node outputs: Data produced by each node
• Errors: Error messages and details for failed nodes
• Timing: Duration per node and total execution time

Execution History is backed by a fast-loading summary that is kept in sync as execution statuses change.

Managing Deployments

Workflow Statuses

Status	Description
draft	Not deployed (initial state, and the state after undeploy)
active	Deployed
paused	Manually paused label; the workflow is excluded from active lists
archived	No longer in active use

Deployment Statuses

Independently of the workflow status, a deployment reports its own state:

Deployment status	Description
queued	Deploy accepted, work scheduled
deploying	Deployment in progress
running / active	Deployed and serving
stopped	Scaled to zero by a lifecycle policy or a manual stop; restartable in ~10s. The builder shows the stop reason
failed	Deploy failed; the error detail is recorded on the workflow

Delete Workflow

A deployed workflow cannot be deleted -- undeploy it first. A workflow with executions still queued or running also cannot be deleted. Deleting an undeployed, idle workflow removes the workflow and all associated data: executions, execution summaries, spans, logs, sessions, and status records.

Deletion Is Permanent

Deleting a workflow removes all versions, execution history, and execution traces. This cannot be undone.

Automatic Retry

Failed execution submissions are added to a retry queue and retried automatically:

• Default 3 attempts, configurable per workflow via its retry settings
• Exponential backoff, starting one minute after the failure

Troubleshooting

Deployment Fails

Possible causes:

• Custom environment not built from the workflow-worker image, still building, or removed
• STRONGLY_SERVICES generation failed for a required service (data source, add-on, model)
• A governance gate on the workflow is not satisfied
• Insufficient compute resources for the requested CPU/memory/GPU

Solutions:

• Pick a built workflow environment or the default in the deploy dialog
• Check the referenced data sources, add-ons, and models exist and are accessible
• Resolve pending governance requirements
• Reduce the requested resources or free up capacity

Workflow Not Receiving Webhooks

Possible causes:

• Workflow not deployed (status is not active)
• Webhook URL not configured in the external system
• Missing or invalid webhook authentication (signature/secret)

Solutions:

• Verify the workflow is deployed and status is active
• Confirm the external system calls /api/v1/webhooks/{workflowId}
• Check the webhook trigger node's secret and provider settings

Execution Fails Immediately

Possible causes:

• STRONGLY_SERVICES generation failed (missing data source or add-on)
• The workflow's deployment is not ready
• The workflow already has the maximum number of in-flight executions (workflows are singletons by default; raise the per-workflow concurrency limit to allow overlap, up to 10)

Solutions:

• Review execution logs for service configuration errors
• Check the deployment status on the workflow
• Wait for the in-flight execution to finish, cancel it, or raise the workflow's concurrency limit

Slow Executions

Possible causes:

• External API latency (data sources, AI models)
• Large data volumes
• Sequential node dependencies that could be parallelized

Solutions:

• Review span timing to identify bottleneck nodes
• Use parallel-branch for independent operations
• Optimize database queries in source nodes
• Increase the deployment's CPU/memory in the deploy dialog

Production Checklist

Pre-Deployment

• Tested with realistic data
• All data source credentials verified
• Error handling nodes in place
• AI Gateway models accessible
• Custom environment image built (if using a custom environment)

Deployment

• Environment, resources, and lifecycle policy configured
• Deployment succeeded (status is active)
• Webhook URL distributed to external systems (if webhook trigger)
• Schedule verified (if schedule trigger)

Post-Deployment

• First execution completed successfully
• Execution traces show expected node flow
• Execution time is acceptable
• Error scenarios handled gracefully

Next Steps

• See workflow examples
• Learn about monitoring
• Configure data sources
• Set up user permissions