# Limits

Sydekyks user and operator guide. Check feature availability and release-specific installation requirements.

These are defaults from the pinned underlying source. Your operator can configure different values. Verify the actual deployment before relying on a limit.

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

 | Limit | Env var | Self-hosted default

 | Flow run timeout | AP_FLOW_TIMEOUT_SECONDS | 600

 | Single action run timeout | AP_FLOW_TIMEOUT_SECONDS | 600

 | Worker process memory | the worker container’s memory cap | 1 GB

 | Paused flow lifetime | AP_PAUSED_FLOW_TIMEOUT_DAYS | 30

 | Execution data retention | AP_EXECUTION_DATA_RETENTION_DAYS | 30

 | Worker concurrency (per worker) | AP_WORKER_CONCURRENCY | 5 (set to 1 - see Production Setup (https://docs.sydekyks.com/install/configure-operate/production-setup))

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.

Where supported, platform admins can shorten the execution-data retention window for a single
project by setting executionDataRetentionDays on the
update project endpoint (https://docs.sydekyks.com/features/availability); 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.

 | Limit | Env var | Self-hosted default

 | Step file size | AP_MAX_FILE_SIZE_MB | 25

 | Flow run log size (combined inputs + outputs, includes sliced payloads) | AP_MAX_FLOW_RUN_LOG_SIZE_MB | 50

 | Step output slice threshold | AP_FLOW_RUN_LOG_SLICE_THRESHOLD_KB | 32

 | Step input truncate threshold | AP_FLOW_RUN_LOG_INPUT_TRUNCATE_THRESHOLD_KB | 2

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.

 | Limit | Env var | Self-hosted default

 | Sync webhook response timeout | AP_WEBHOOK_TIMEOUT_SECONDS | 30

 | Max webhook payload size | AP_MAX_WEBHOOK_PAYLOAD_SIZE_MB | 25

 | Webhook payload inline threshold | AP_WEBHOOK_PAYLOAD_INLINE_THRESHOLD_KB | 512

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.

 | Limit | Env var | Self-hosted default

 | Maximum key length | not configurable | 128

 | Maximum value size | AP_MAX_STORE_ENTRY_VALUE_SIZE_KB | 512

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.