---
title: Requirements
description: Hardware and software specifications required to host the Reloop stack.
---
> For the complete documentation index, see [llms-docs.txt](/llms-docs.txt) or the site index [llms.txt](/llms.txt). Full docs corpus: [llms-full-docs.txt](/llms-full-docs.txt). Prefer markdown URLs (append `.md`) for agent consumption. Product skill: [skill.md](/skill.md).


Before deploying the Reloop stack, ensure your server environment meets the hardware and software specifications outlined below.

## Hardware Requirements

Reloop's performance is highly dependent on database throughput and the speed of processing background queues.

| Resource | Minimum Requirement | Recommended (Production) |
| :--- | :--- | :--- |
| **CPU** | 2 vCPUs | 4+ vCPUs |
| **RAM** | 4 GB | 8 GB+ |
| **Storage** | 20 GB SSD | 50 GB+ NVMe SSD |

> [!NOTE]
> The Docker Compose deployment needs more disk than the numbers above: the container images alone are about 22 GB, so plan for 35 GB minimum and 50 GB comfortably. See [Deploy on VPS](/self-host/vps).

> [!NOTE]
> SSD/NVMe storage is highly recommended. PostgreSQL stores relational data and telemetry logs, which benefit from fast disk I/O speeds to prevent latency.

---

## Software Requirements

Verify the following software and runtimes are installed on your hosting server:

* **Docker**: Version `24.0.0+`
* **Docker Compose**: Version `2.20.0+`
* **Bun**: Version `1.3.0+` (Only required if you run the microservices natively outside of Docker containers, or during the initial environment variables setup).
* **Git**: For cloning the repository and checking out configurations.

---

## Network Requirements

Domain verification reads your published SPF, DKIM, DMARC and MX records from
public DNS. It queries upstream resolvers directly rather than the host's
resolver, because a host resolver is frequently a link-local or VPN address that
is unreachable from inside the container network. The symptom is every record
failing with `ENOTFOUND` while the same lookup succeeds from the host shell.

The `domain` and `workflow` services need:

* **Outbound UDP port 53** to the resolvers they are configured to use. Allow **TCP port 53** as well; responses larger than 512 bytes fall back to TCP, which DKIM keys routinely exceed.

### Choosing resolvers

`DNS_RESOLVERS` in your `.env` sets the upstream resolvers, as a comma-separated
list of IP addresses. It defaults to `8.8.8.8,8.8.4.4`, and falls back to that
default if the value is empty or is not a valid address.

```bash
DNS_RESOLVERS=1.1.1.1,9.9.9.9
```

Point this at a reachable resolver when outbound 53 to the public resolvers is
blocked, or when you run an internal resolver you would rather use. Restart the
two services afterwards:

```bash
reloop restart domain workflow
```

> [!NOTE]
> Use resolvers that answer for the public internet. An internal split-horizon
> resolver may return private answers for your sending domain, or none at all,
> and verification will fail even though the records are published correctly.

### Docker resolver configuration

`docker-compose.yml` also sets `dns` on every backend service, so containers
that fall back to the system resolver still reach a working one:

```yaml
x-backend: &backend
  dns:
    - 1.1.1.1
    - 8.8.8.8
```

This does not affect service discovery. Docker keeps its embedded resolver at
`127.0.0.11` inside the container and uses the `dns` list only as upstream
forwarders, so `postgres`, `redis` and `nats` continue to resolve by name.