---
title: "Hardware Requirements"
icon: "server"
description: "Specifications for hosting Activepieces"
---

More information about architecture please visit our [architecture](../architecture/overview) 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.

| Component  | Memory (RAM) | CPU Cores | Disk Space | Notes                              |
| ---------- | ------------ | --------- | ---------- | ---------------------------------- |
| PostgreSQL | 1 GB         | 1         | —          |                                    |
| Redis      | 1 GB         | 1         | —          |                                    |
| App        | 2 GB         | 1         | 30 GB      | API server, UI, webhook routing    |
| Worker     | 1 GB         | 0.5       | —          | Per replica; add replicas to scale |

<Tip>
The above recommendations are designed to meet the needs of the majority of use cases.
</Tip>

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

<Tip>
**Scaling Tip:** Since files are stored in the database, you can alleviate the load by configuring S3 storage for file management.
</Tip>

PostgreSQL is typically not the system's bottleneck.

### App Container

<Tip>
**Scaling Tip:** The App container is stateless, allowing for seamless horizontal scaling.
</Tip>

### Worker Container

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

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