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.

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.

​
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), Activepieces will wait up to the response timeout before returning HTTP 408. 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.