Skip to main content
The numbers in the Cloud column are the limits enforced on cloud.activepieces.com. On self-hosted installations every limit is configurable through the environment variable shown in the table — the Self-hosted default column lists the value applied when the variable is unset.

Execution

Run timeout, worker memory, retention.

Concurrent runs

How many flow runs a project can execute at once.

Files & flow run logs

File sizes, log size, slicing thresholds.

Webhooks

Response timeout, payload size, inline threshold.

Key / value storage

Store piece key length and value size.

​
Execution

Limits on how long a flow runs, how much memory and concurrency a worker gets, and how long run data is kept. The run timeout counts only active execution time — flows paused by Wait for Approval or Delay don’t count against it.
Run logs, step files, and execution events are deleted after the retention window. AP_PAUSED_FLOW_TIMEOUT_DAYS cannot exceed AP_EXECUTION_DATA_RETENTION_DAYS — a paused flow can’t outlive the data it needs to resume.
Platform admins can shorten the execution-data retention window for a single project by setting executionDataRetentionDays on the update project endpoint; null reverts the project to the instance-wide value. The value must be between AP_PAUSED_FLOW_TIMEOUT_DAYS (a shorter window would delete the data a still-paused run needs to resume) and AP_EXECUTION_DATA_RETENTION_DAYS (the instance value is the ceiling). Raise the instance value if you need a wider range to place projects in. If either variable changes after an override was saved, the override is clamped back into the new bounds at cleanup time.
At the recommended concurrency of 1, the worker container’s memory cap (1 GB) is the memory limit for the flow. If a flow exhausts it, that one worker is OOM-killed and the job is requeued (about 300 MB of the budget is overhead for a warm process with pieces loaded). To handle larger or longer processes, split them into multiple flows — e.g. one flow calls another via webhook, or each flow processes a smaller batch of items.

​
Concurrent runs

A project can only execute a certain number of flow runs at the same time. On Cloud, that number depends on your plan: These limits exist because Cloud runs everyone’s flows on shared machines. If one project could start thousands of runs at once, it would take over the capacity that other customers’ runs need, and their flows would slow down or stall. Capping how many runs each project executes at a time keeps start times predictable for everyone. A run that arrives while the project is at its limit is not lost or failed. It waits in a queue and starts automatically as soon as one of the running flows finishes. For most workloads this queuing is invisible; it only becomes noticeable when a flow receives a large burst of triggers at once, in which case the burst is worked through a few runs at a time. Platform admins can give a specific project a different limit in its settings; see Manage Concurrency. On Cloud a per-project value can lower the limit but never raise it above what the plan allows. On self-hosted installations plans don’t apply. Enforcement is off by default and uses a single limit for every project when enabled:

​
Files & flow run logs

Files emitted by actions or triggers are persisted to the database or S3 so a flow can retry from a later step. The log-size limit covers the combined inputs and outputs of every step in a single run. How it works
  • Input — values above AP_FLOW_RUN_LOG_INPUT_TRUNCATE_THRESHOLD_KB are replaced with a placeholder in the log; the step still receives the full value at runtime.
  • Output — outputs above AP_FLOW_RUN_LOG_SLICE_THRESHOLD_KB are offloaded to object storage and replaced with a reference in the log; the payload is re-hydrated on demand.
  • Total — the cumulative size of inputs and outputs (counting the original size of offloaded outputs) is capped by AP_MAX_FLOW_RUN_LOG_SIZE_MB. Runs that exceed it end with status LOG_SIZE_EXCEEDED — regardless of how many outputs were offloaded to object storage. Lowering AP_FLOW_RUN_LOG_SLICE_THRESHOLD_KB will not buy more log headroom; only raising AP_MAX_FLOW_RUN_LOG_SIZE_MB does.

​
Webhooks

Limits on how long a synchronous webhook waits for a response and how large an incoming payload can be.
For synchronous webhook requests (URLs ending in /sync), a run that fails answers straight away with HTTP 500. HTTP 408 is returned only when the run never produced a response at all within the timeout, which is the case for a flow that is still running or one that finishes without a Return Response step. Payloads above the inline threshold are offloaded from Redis to file storage to protect Redis memory; smaller payloads stay inline for the fastest path.

​
Key / value storage

Used by the built-in Store piece and any piece that calls context.store. Values are stored directly in Postgres (jsonb), so unlike files and run logs they are not offloaded to object storage. Every stored value counts toward your database size and is read and written in full on each access.
Raising the value size lets a flow stash bigger payloads (for example, data gathered inside router branches and re-read after the branches join). But large values live in the database with no object-storage offload. For payloads in the MB range, prefer the Tables piece or pass data as files between steps.