Skip to main content

Documentation Index

Fetch the complete documentation index at: https://www.activepieces.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

More information about architecture please visit our architecture page.

​
Technical Specifications

Activepieces is designed to be memory-intensive rather than CPU-intensive. A modest instance will suffice for most scenarios, but requirements can vary based on specific use cases.
ComponentMemory (RAM)CPU CoresDisk SpaceNotes
PostgreSQL1 GB1—
Redis1 GB1—
App4 GB130 GBAPI server, UI, webhook routing
Worker4 GB1—Per replica; add replicas to scale
The above recommendations are designed to meet the needs of the majority of use cases.

​
Scaling Factors

​
Redis

Redis requires minimal scaling as it primarily stores jobs during processing. Activepieces leverages BullMQ, capable of handling a substantial number of jobs per second.

​
PostgreSQL

Scaling Tip: Since files are stored in the database, you can alleviate the load by configuring S3 storage for file management.
PostgreSQL is typically not the system’s bottleneck.

​
App Container

Scaling Tip: The App container is stateless, allowing for seamless horizontal scaling.

​
Worker Container

Scaling Tip: Workers are stateless. Add more worker replicas to increase concurrent flow execution capacity. The default Docker Compose setup starts 5 replicas.

​
Expected Performance

Activepieces ensures no request is lost; all requests are queued. In the event of a spike, requests will be processed later, which is acceptable as most flows are asynchronous, with synchronous flows being prioritized. It’s hard to predict exact performance because flows can be very different. But running a flow doesn’t slow things down, as it runs as fast as regular JavaScript. (Note: This applies to SANDBOX_CODE_ONLY and UNSANDBOXED execution modes, which are recommended and used in self-hosted setups.) You can anticipate handling over 20 million executions monthly with this setup.