Limits and Boundaries

Limits keep workflows, diagnostics, and durable data bounded.

Important limits

Webhook bodies: 1 MiB.
Step retries: 1–10 total attempts.
For-each items: at most 10,000; concurrency 1–64.
Local module graph: at most 512 sources and 16 MiB.
Runtime workers: 1–256.
Run list limit: 1–200.

Deployment boundaries

The local state database is owner-only on Unix but not transparently encrypted. Admin operations remain loopback and state scoped. Public ingress requires deliberate TLS and authentication.

Review Current Limitations before assuming support for distributed control planes, NoSQL, queue services, arbitrary DAG edges, or untrusted code.

Why limits are part of the product

Durable systems must bound payloads, outputs, worker frames, module graphs, list responses, loops, and storage values. Without limits, one workflow could make recovery, inspection, or process memory unbounded.

Validation rejects known static limit violations. Runtime checks reject dynamic values such as an oversized webhook, too many loop items, or a non-JSON result with a stable diagnostic instead of truncating business data silently.

Plan around limits

Put large response bodies directly into storage rather than context. Split very large datasets at the source rather than trying to push more than 10,000 items through one for-each. Keep module graphs project-sized and vendor only reviewed code.

Limits are not capacity recommendations. A workflow below every hard maximum can still overwhelm an external API if concurrency and rate policy are poorly chosen.

Separate local and hostile trust profiles

The local runtime assumes trusted project code. State files use owner protections where supported but are not transparently encrypted. Public ingress needs TLS, authentication, reverse-proxy limits, and persistent storage chosen by the operator.

WOML does not currently claim a multi-region control plane, hostile multi-tenant sandbox, NoSQL service, public queue capability, or arbitrary custom structural tags.