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 run live sessions instead of executions, and their deploy dialog has its own settings: session idle timeout, maximum session length, maximum concurrent sessions and scaling (one worker started by the first session, or a minimum to maximum number of workers per sessions). They have no Environment choice. See Streaming Workflows.

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, Lifecycle tab) that controls how the deployed workflow runs. It affects cost and availability. Streaming workflows do not have a lifecycle policy: their capacity follows their sessions, set by the scaling settings in their deploy dialog.

• A workflow whose trigger is a Schedule, Email, RSS or File trigger has no lifecycle policy: each run starts a worker of its own and ends with it.
• A workflow whose trigger is a Queue trigger consumes its queue while its pod runs, so its policy is Always On or Scheduled Window; the other two are refused.

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; scaled to zero outside them."	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.

Max Concurrent Runs

The Lifecycle tab also sets Max Concurrent Runs: how many of the workflow's runs may be in flight at once, 1 to 10 (default 1). A run started beyond it is refused (a webhook or form caller gets 409). A Queue trigger keeps this many messages' runs going. Like the rest of the workflow's settings, it changes while the workflow is undeployed; through the API it is maxConcurrentExecutions on PATCH /api/v1/workflows/:id.

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.

After a platform update

A running deployed workflow (batch or streaming) is deployed again on the new platform version for you: its deployed version, never your draft. A stopped one is deployed again when it starts. If the redeploy is refused for the user who deployed it (no access, an exhausted budget, a governance gate), the toolbar shows Restart needed beside "vN deployed"; it deploys that version again. See Platform Updates.

Sharing

Share Workflow

Share a workflow from the Permissions tab of its Settings in the builder (save a new workflow first). Workflows are shared with individual users:

• The workflow owner has full access
• Can edit: the person can open, run, change, start, stop and delete the workflow
• Can use: the person can open the workflow read-only, run it and clone it, but not change or delete it. In their workflow list the row has an open button in place of edit, and no start, stop, promote or delete buttons
• 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

Workflows open to all users

Choose Allow all users on a workflow to make it visible to all users in the organization. Everyone gets Can use access to it: they can open, run and clone it, never change or delete it.

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

Templates, including the platform's public scaffolds (such as Scaffold: RAG Knowledge Ingest), are not listed in the workflow list or the Workflow Monitor, and are not counted in their totals: those show your workflows. List templates with GET /api/v1/workflows/templates (the Python SDK's client.workflows.templates()), or ask STAN to start a workflow from one.

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, start and end time, and duration. A run is Pending or Running until it finishes, then shows one of:

Status	Meaning
Completed	Every node finished and produced its output
Completed with gaps (warning)	The run reached the end, but some nodes produced no output. Open the trace to see which
Partial success (warning)	A distributed run finished with only some of its items delivered. Open the trace to see which items failed
Failed	A node failed; the trace shows its error
Cancelled / Stopped	Ended by a user

The status filter can select each finished status except Stopped.

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

Health Column

The workflow list's Health column shows what the platform last saw of a deployment, and when it checked. The platform checks every running deployment about every 30 seconds by calling its server's health endpoint.

• A running workflow or agent shows Healthy, Unhealthy, Unreachable or Error from its last check (hover for the detail), or No health data yet until the first check
• A deployment that is changing shows its state (Deploying, Starting, Stopping); a schedule-only workflow shows Scheduled, a stopped one Stopped and a failed one Failed with the reason
• An on-demand agent scaled to zero while idle shows Idle
• A workflow that is not deployed, or an agent that is not running, shows -

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
• Govern what gets deployed
• Configure data sources
• Set up user permissions