Skip to main content
This is the production setup we recommend. It is sized from a single number — your peak concurrent flows — and everything else follows from there.

​
What it looks like

One flow per worker. A small fleet of those. A thin tier of apps in front. Managed Postgres, Redis, and S3 behind — all in the same region. Activepieces production architecture: client, app, Redis job queue, Postgres, S3, and one-flow-per-worker execution tier
ComponentSize eachHow many
Worker0.5 vCPU / 1 GB, concurrency 1one per concurrent flow
App1 vCPU / 1 GBone per ten workers
Postgres2 vCPU / 4 GB, managedone, grows with the fleet
Redis1 vCPU / 1 GB, managedone
Object storage (S3)same region, signed URLs onrequired
S3 is a hard requirement, not a nice-to-have: without it, every flow bundle and piece archive funnels through the app tier and the throughput numbers below no longer hold. (Walkthrough: S3 Storage.) Copy this — it’s the exact configuration the benchmark below was measured on: 
AP_WORKER_CONCURRENCY=1
AP_REUSE_SANDBOX=true
AP_EXECUTION_MODE=SANDBOX_CODE_ONLY
AP_FILE_STORAGE_LOCATION=S3
AP_S3_USE_SIGNED_URLS=true

​
Sizing

A concurrency-1 worker is busy for a flow’s whole duration (up to 10 min), so size by concurrent flows, not trigger rate: 
workers = peak concurrent flows
apps    = ceil(workers / 10)
At 50 concurrent flows: 50 workers (25 vCPU / 50 GB) + 5 apps (5 vCPU / 5 GB). Overflow queues in Redis and drains as slots free.
Size statically for peak — autoscaling’s boot and scheduling lag can’t defend the 30 s sync-webhook budget. A pre-sized fleet keeps a slot warm and waiting.
And it scales with your fleet: 1:10 app-to-worker scaling: 4 apps / 40 workers at 93.5 req/s grows to 8 apps / 80 workers at 148.9 req/s Full methodology and the ratio comparison: Benchmark.

​
Limits

LimitDefaultEnv var
Flow run timeout600 sAP_FLOW_TIMEOUT_SECONDS
Sync webhook response30 sAP_WEBHOOK_TIMEOUT_SECONDS
Max webhook payload25 MBAP_MAX_WEBHOOK_PAYLOAD_SIZE_MB
Step file size25 MBAP_MAX_FILE_SIZE_MB
Flow run log size50 MBAP_MAX_FLOW_RUN_LOG_SIZE_MB
The complete table lives in Limits.
Need to reserve dedicated capacity for specific tenants? See Worker Groups.

​
Migrating from an earlier setup

Upgrading breaks nothing: the default AP_WORKER_CONCURRENCY=5 keeps each container running five flows at once. Reshaping to one flow per worker is opt-in, at the same total capacity. Keep total slots constant: slots = containers × concurrency.
BeforeAfter
Per worker~2.5 vCPU / 5 GB, concurrency 50.5 vCPU / 1 GB, concurrency 1
For 50 slots10 workers50 workers
1

Apply the recommended config

AP_WORKER_CONCURRENCY=1
AP_REUSE_SANDBOX=true
AP_EXECUTION_MODE=SANDBOX_CODE_ONLY
On Worker Groups, keep AP_EXECUTION_MODE=SANDBOX_PROCESS; code-only mode is rejected for grouped workers.
2

Resize and scale

Drop each worker to 0.5 vCPU / 1 GB, then run one replica per slot.
3

Co-locate S3

AP_FILE_STORAGE_LOCATION=S3
AP_S3_USE_SIGNED_URLS=true
Keep the bucket in the same region as your workers. See S3 Storage.
4

Drop dead vars

Remove AP_PRE_WARM_CACHE; it no longer does anything (0.86.0).
Not ready to reshape? Leave concurrency at 5 and size each container ~5× (≈5 GB).