Execution runtimes

A runtime determines where tasks execute and how resources are allocated. Choose it when deploying a flow, changing deployment settings, or submitting a run.

On this page

Runtime tiers Configure a deployment or run Local concurrency, retries, and timeouts Data exchange between tasks

Runtime tiers

`execution_mode`	Execution model	Intended workload
`nano`	Tasks share one invocation	Small, short workflows with lightweight dependencies
`micro`	Tasks execute in separate invocations	Short tasks that benefit from isolation
`small`	Dedicated compute, 0.5 vCPU / 1 GB	Workloads requiring dedicated resources
`medium`	Dedicated compute, 1 vCPU / 2 GB	Larger in-memory processing
`large`	Dedicated compute, 2 vCPU / 4 GB	Higher CPU and memory workloads
`xlarge`	Dedicated compute, 4 vCPU / 12 GB	The largest named tier

nano is the default. The console describes nano and micro as up to ten minutes per invocation or task. Actual availability and timeout ceilings depend on the hosted deployment; do not infer an unlimited workflow duration from the dedicated tiers. GET /backends reports the configured runtime capabilities, including duration, memory, parallel execution, and cancellation support. Its backend names are diagnostic identifiers; select the public execution_mode tier for ordinary integrations.

Configure a deployment or run

Shell

curl --fail-with-body -X PUT \
  "$DAGY_API_URL/deployments/$DEPLOYMENT/settings" \
  -H "Authorization: Bearer $DAGY_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"execution_mode":"small"}'

The settings operation requires flows.write. To override a single run, include "execution_mode":"small" in POST /runs with the deployment name and parameters; this requires runs.trigger. A requested tier must be available in the target deployment. Check the run response and detail for the selected mode.

Legacy mode values are still accepted: in-process and xxsmall normalize to nano; task-isolated and xsmall to micro; ecs-fargate to small. Use the current values in new clients.

Local concurrency, retries, and timeouts

flow.run_local(max_workers=4) allows independent tasks to run concurrently. Mapped items execute sequentially in the current local runtime. Per-task concurrency_limit is accepted by the SDK but is not enforced locally.

Task retries rerun a task; flow retries can rerun the whole graph. Design writes to be idempotent, and use a bounded retry policy for transient failures. See SDK reference for explicit delay lists, conditions, jitter, and lifecycle hooks.

Local task timeouts do not forcibly terminate Python threads. A timed-out function can continue writing to external systems, and the process may wait for it to finish. The same consideration applies to cancellation of already-running local tasks. Use timeouts in the external client library itself and cooperative cancellation where appropriate.

Data exchange between tasks

Prefer ordinary JSON-compatible records, arrays, and small objects. The SDK supports additional literal types for graph parameters, but referenced Python types must be importable in the target runtime. For large data, write to your own storage and pass an application-level location or identifier instead of moving entire datasets through task results.

Local artifact retention and serialization have their own limits. A successful task does not guarantee an unsupported output object was persisted for later reuse. See configuration, limits, and retry-from-failed behavior.