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

# Overview

> How Activepieces is put together, and why it runs flows the way it does

This section explains **why** Activepieces works the way it does: the components, the execution model, and the trade-offs behind them. If you want to *do* something (size a deployment, set up SSL, scale workers), start with [Configure & Operate](../configure-operate/production-setup). Come here when you want the reasoning under those choices.

This page describes the main components, with a focus on how flows run.

## Components

<img src="https://mintcdn.com/activepieces/HPdB7kMdQC2Eh_kp/resources/diagrams/activepieces-architecture.png?fit=max&auto=format&n=HPdB7kMdQC2Eh_kp&q=85&s=c784d822d915bf50da11a7ab3a7ff6fb" alt="Activepieces production architecture: client, app, Redis job queue, Postgres, S3, and one-flow-per-worker execution tier" width="2400" height="1520" data-path="resources/diagrams/activepieces-architecture.png" />

**Activepieces:**

* **App**: The main application that organizes everything from APIs to scheduled jobs.
* **Worker**: Polls for new jobs, allocates a sandbox from the pool, executes the flows with the engine inside the sandbox, and sends results back to the app.
* **Sandbox**: An isolated execution environment that manages process lifecycle, resource limits, and communication with the engine via WebSocket.
* **Engine**: TypeScript code that parses flow JSON and executes it. It is compiled into a single JS file and runs inside the sandbox.
* **UI**: Frontend written in React.

**Third Party**:

* **Postgres**: The main database for Activepieces.
* **Redis**: Powers the queue using [BullMQ](https://docs.bullmq.io/).

## Reliability & Scalability

<Tip>
  Postgres and Redis availability is outside the scope of this documentation, as many cloud providers already implement best practices to ensure their availability.
</Tip>

Everything is queue-backed: webhooks and recurring jobs land on Redis, and workers poll them off it. A spike does not drop work. It queues and drains as slots free. For exactly what survives a crash, what runs at-least-once, and where each promise stops, see [Guarantees](../guarantees/crash-recovery).

To scale Activepieces, add replicas of the workers, the app, or the Postgres database. A small Redis instance is enough: it handles thousands of jobs per second and rarely becomes a bottleneck. For the concrete sizing model, see [Production Setup](../configure-operate/production-setup).

## Repository Structure

The repository is a monorepo built with Turbo, with TypeScript as the primary language. It is divided into several packages:

```
.
├── packages
│   ├── web
│   ├── server
│   │   ├── api
│   │   ├── worker
│   │   ├── engine
│   │   ├── sandbox
│   │   └── common
│   ├── ee
│   ├── pieces
│   └── shared
```

* `web`: This package contains the user interface, implemented using the React framework.
* `api`: This package contains the main application written in TypeScript with the Fastify framework.
* `worker`: This package contains the logic of accepting flow jobs and executing them using the engine.
* `server-sandbox`: This package contains the sandbox execution environment, including process isolation, pool management, and WebSocket communication between the worker and engine.
* `common`: This package contains the shared logic between worker and app.
* `engine`: This package contains the logic for flow execution within the sandbox. Located under `server/engine`.
* `pieces`: This package contains the implementation of triggers and actions for third-party apps.
* `shared`: This package contains shared data models and helper functions used by the other packages.
* `ee`: This package contains features that are only available in the paid edition.