Published

Activepieces

No-code automation platform: flows built from triggers and "pieces" (integrations), webhooks, schedules, Code steps and AI agents. Fits teams that want a business-user-friendly flow builder on their own server. The self-hosted stack is an app container, a separate worker that runs the flows, PostgreSQL and Redis.

Resources by load level

What the app itself needs at each level, next to what we recommend for a server that runs only this app.

Level	What it means	App requirements	Recommended
LightEstimate	Up to 5 builders, 20 active flows, ~500 runs/day, one flow running at a time, payloads under 1 MB; one worker, files in PostgreSQL.	2.25 vCPU · 3.5 GiB RAM · 9.25 GiB disk	2.82 vCPU · 5.7 GiB RAM · 20.298 GiB disk
MediumEstimate	Up to 20 builders, 100 active flows, ~5,000 runs/day, up to 3 flows running at once, payloads of a few MB; one worker at its default concurrency 5.	4.75 vCPU · 8.5 GiB RAM · 54.75 GiB disk	5.82 vCPU · 11.7 GiB RAM · 72.623 GiB disk
HeavyEstimate	Up to 50 builders, 300 active flows, ~25,000 runs/day, 5 flows running at once (the worker's default concurrency and per-project limit); beyond this, add workers.	6 vCPU · 11 GiB RAM · 56.25 GiB disk	7.32 vCPU · 14.7 GiB RAM · 74.348 GiB disk

Recommended = app requirements + system baseline + safety headroom, under sizing policy 2026.10.0. Options stay at their defaults. “Estimate” means the sources give no number for that case, so it is worked out from them by the method stated under Components. How the numbers are built

Size it in the Stack Sizer

Ready-to-run files

Support level Supported

Compose template from the official sources; not yet verified by a run.

Create docker-compose

Components

What each component needs at each load level, before baseline and headroom.

vCPU / GiB RAM / GiB disk
Component	Light	Medium	Heavy	Sources
Activepieces (app: API and UI) (app)	0.5 / 1 / 1.5	1 / 1 / 1.5	1 / 1 / 1.5	[7][10][11][26]
Activepieces worker (worker)	0.5 / 1 / 0.5	1.5 / 3 / 1	2.5 / 5 / 2	[6][9][10][12]
PostgreSQL (database)	1 / 1 / 6.5	2 / 4 / 51.5	2 / 4 / 51.5	[9][12][34][35][36][37][38][39][40]
Redis (BullMQ job queue) (queue)	0.25 / 0.5 / 0.75	0.25 / 0.5 / 0.75	0.5 / 1 / 1.25	[9][10][11][29]

How the estimates are worked out

Activepieces (app: API and UI) · Light: RAM: the documented app size of 1 GB (GB taken as GiB). vCPU: the documented app is 1 vCPU per ten workers and used 0.52-0.61 core per pod at 20+ req/s in the benchmark; one busy flow at a time needs about half. Disk: image 1,456,418,304 B unpacked (1.356 GiB) rounded up to 1.5 GiB; no data volume, all state is in PostgreSQL.
Activepieces (app: API and UI) · Medium: The documented app size, 1 vCPU / 1 GB, which serves up to ten concurrent-flow workers (GB taken as GiB). Disk as light: the 1.356 GiB unpacked image rounded up to 1.5 GiB.
Activepieces (app: API and UI) · Heavy: The documented app size, 1 vCPU / 1 GB, covers up to ten concurrent-flow workers; 5 concurrent flows stay within it. Disk as light: 1.5 GiB for the 1.356 GiB unpacked image.
Activepieces worker · Light: Docs size one concurrent flow at 0.5 vCPU / 1 GB (about 300 MB of it warm-process overhead); one flow at a time gives 0.5 vCPU / 1 GiB. Disk: 0.5 GiB for the piece and flow cache volume (ANAROQ assumption, no upstream figure); the image is the app's, pulled once and counted there.
Activepieces worker · Medium: 3 concurrent flows × the documented 0.5 vCPU / 1 GB per flow = 1.5 vCPU / 3 GiB; each sandboxed engine process is capped at 1 GiB (AP_SANDBOX_MEMORY_LIMIT 1048576 KB). Disk: 1 GiB cache volume for more pieces and flows (ANAROQ assumption).
Activepieces worker · Heavy: Docs give ~2.5 vCPU / 5 GB for a worker at concurrency 5 (5 × 0.5 vCPU / 1 GB); GB taken as GiB. Disk: 2 GiB cache volume for ~300 flows and their pieces (ANAROQ assumption).
PostgreSQL · Light: Embedded metadata DB with the image's default config: equals the PostgreSQL profile's light preset (≤ 5 GB data, ≤ 20 concurrent connections) at every load level. Light preset method: shared_buffers 25% of RAM, worst-case work_mem/maintenance_work_mem budget, 0.5 GiB image + 5 GiB data + 1 GiB WAL.
PostgreSQL · Medium: Run logs, step files (AP_FILE_STORAGE_LOCATION=DB) and events stay 30 days: 5,000 runs/day × 30 × an assumed 30 KB per run ≈ 4.5 GB, at the edge of the 5 GB sidecar envelope, so the PostgreSQL profile's medium preset (≤ 50 GB). Its method: shared_buffers 1 GiB = 25%, worst-case work_mem budget for 100 connections, 0.5 GiB image + 50 GiB data + 1 GiB WAL.
PostgreSQL · Heavy: 30-day retention: 25,000 runs/day × 30 × an assumed 30 KB per run ≈ 22.5 GB of run data, within the PostgreSQL profile's medium preset (≤ 50 GB). Docs say database CPU grows with throughput (~2.5 millicores per req/s); 25,000 runs/day averages 0.29 run/s. Medium method: shared_buffers 1 GiB = 25%, 0.5 GiB image + 50 GiB data + 1 GiB WAL.
Redis (BullMQ job queue) · Light: Docs size Redis at 1 vCPU / 1 GB for production fleets; the benchmark's Redis used 0.123 core at 213 req/s, far above this level, so 0.25 vCPU. RAM: half the documented 1 GB for the queue, inline webhook payloads (< 512 KB each) and failed jobs (kept 30 days, up to 100,000). Disk: 43.8 MiB compressed image × 3 (131 MiB) + an RDB snapshot up to the 0.5 GiB dataset, rounded up to 0.75 GiB.
Redis (BullMQ job queue) · Medium: As light: the benchmark's Redis used 0.123 core at 213 req/s, still far above ~5,000 runs/day; 0.5 GiB RAM and 0.75 GiB disk (131 MiB image + RDB snapshot).
Redis (BullMQ job queue) · Heavy: RAM: the documented 1 GB (GB taken as GiB). vCPU: half the documented 1 vCPU; the benchmark's Redis used 0.123 core at 213 req/s. Disk: 131 MiB image (43.8 MiB compressed × 3) + an RDB snapshot up to the 1 GiB dataset, rounded up to 1.25 GiB.

Ports

Public ports are meant to be reached from outside the stack, usually through a reverse proxy; internal ones stay on the stack's own network.

Component	Port	Exposure	Purpose	Sources
Activepieces (app: API and UI)	80/tcp	Public, through a proxy	UI, REST API, webhooks and the worker's API/Socket.IO endpoint (HTTP; put behind TLS)	[2][23]
PostgreSQL	5432/tcp	Internal only	PostgreSQL connections from the app	[3][9]
Redis (BullMQ job queue)	6379/tcp	Internal only	BullMQ job queue between the app and the workers	[9][30]

Every port in the catalog, with conflicts between apps

User and permissions (UID/GID)

The user each container's process runs as, and the paths it writes to. A bind mount for one of these paths must be writable by that UID:GID.

Component	UID:GID	User	Starts as root	Writes to	Sources
Activepieces (app: API and UI)Derived	0:0	`root`	No	—	[4][23]
Activepieces workerDerived	0:0	`root`	No	`/usr/src/app/cache`	[2][6][23]
PostgreSQL	999:999	`postgres`	Yes, prepares its directories, then drops to this user	`/var/lib/postgresql/var/run/postgresql`	[32][33][39]
Redis (BullMQ job queue)	999:999	`redis`	Yes, prepares its directories, then drops to this user	`/data`	[30][31]

Activepieces (app: API and UI): The Dockerfile sets no USER and the image config has an empty User, so node runs as root (uid 0) and never drops privileges. With AP_ENCRYPTION_KEY and AP_JWT_SECRET set, the app writes no local files; everything goes to PostgreSQL.
Activepieces worker: Same image as the app, so root (no USER in the Dockerfile). The worker writes its piece and flow cache to 'cache' under the WORKDIR /usr/src/app, the path the official Compose mounts.

Storage growth

How much each component's data grows per month at each load level, on top of the disk in the profile. A value marked Assumption is ANAROQ's stated assumption, not a figure from the sources; the notes say what it rests on.

GiB per month
Component	Light	Medium	Heavy	Sources
PostgreSQLAssumption	0.05	0.2	0.5	[9][12]

What the growth figures rest on

PostgreSQL: Run logs, step files and events are deleted after 30 days (AP_EXECUTION_DATA_RETENTION_DAYS), so run data levels off after the first month. What keeps growing: flow versions, connections, Tables records (up to 10,000 per table) and Store values. Activepieces gives no growth figure; this is an ANAROQ assumption.

Upgrade and rollback

How to move to a new version safely, and how to go back if it fails.

Back up first

Dump the database first (pg_dump of the activepieces database) and keep the .env with AP_ENCRYPTION_KEY next to it. [7][20]

Upgrade steps

Read the breaking changes of every version you skip, newest first. [7][21]
Set the same new image tag on the app and on the worker: since 0.85.4 a safeguard requires both to run the same version. [7][21]
Run docker compose pull, then docker compose up -d. [7][20]DerivedThe docs upgrade with their install script or by bumping the pinned tag in docker-compose.yml; pull and up -d is how Compose applies a new tag.

Roll back

Stop the stack, run the rollback command with the newer image (npm run rollback -- --to <old version>, --force if the release has breaking migrations), then switch both services back to the old tag and start. Or restore the dump taken before the upgrade. [20]

Known breaking changes

In 0.92.0: Files passed to AI steps (Extract Structured Data, Generate Image) are capped at AP_MAX_FILE_SIZE_MB, 25 MB by default. [21]
In 0.90.4: Telemetry is a per-platform setting in the admin UI; AP_TELEMETRY_ENABLED is only its starting value. [21]
In 0.88.2: PM2 was removed from the image: a crashed or OOM-killed process now exits the container, so a restart policy is required. [21]
In 0.85.4: The worker and the app must run the same image version. [21]
In 0.80.0: Nginx was removed from the image; Fastify serves the UI and the API, all API routes are under /api, and the health check moved to /api/v1/health. [21]

Limits

One worker runs at most 5 flows at once (AP_WORKER_CONCURRENCY), and each project is limited to 5 concurrent runs by default. More throughput means more worker containers, which this single-server template doesn't add. [9][10][14]
A run is stopped after 600 s of active time, files are capped at 25 MB and a run's log at 50 MB, and a worker process has a 1 GB memory budget (~300 MB of it overhead). Split large jobs into several flows. [12]
Code steps run in a V8 isolate (SANDBOX_CODE_ONLY): no npm packages, no filesystem. Modes that allow npm with isolation need a privileged container, which this template doesn't grant. [13]
Files and run data live in PostgreSQL by default (no S3), and the bundled PostgreSQL has no pgvector, so agent knowledge bases stay hidden. [9][22][24]

Security

Serve Activepieces over HTTPS from a reverse proxy that passes WebSockets, and set AP_FRONTEND_URL to that public URL: webhooks and app triggers are built from it, and test runs need the WebSocket. [9][17][18]
Flow code can reach anything the worker can reach (AP_NETWORK_MODE defaults to UNRESTRICTED), including the stack's password-less Redis. Only let trusted people build flows, or block internal ranges in the firewall. [16]
There is no default login: the first account created becomes the platform administrator. Create it right after the first start. [7]

Backup

Back up PostgreSQL (pg_dump): flows, runs, connections and schedules live there, not in the install folder. Keep AP_ENCRYPTION_KEY with it; without the key, stored connections can't be decrypted even from a full backup. [7][19]
Keep the Redis volume: async webhooks are acknowledged once queued in Redis, before PostgreSQL has a record, so jobs lost with Redis are gone for good. Everything else is rebuilt from PostgreSQL. [19]