> For the complete documentation index, see [llms.txt](https://igra-labs.gitbook.io/igralabs-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://igra-labs.gitbook.io/igralabs-docs/for-attesters/hardware-requirements.md).

# Hardware Requirements

System requirements for running an Igra node.

## Hardware

| Component | Minimum                | Recommended   |
| --------- | ---------------------- | ------------- |
| CPU       | 4 cores (64-bit)       | 8+ cores      |
| RAM       | 32 GB                  | 32 GB         |
| Storage   | 2 TB SSD (NVMe or gp3) | 2 TB NVMe SSD |
| Network   | 200 Mbps sustained     | 500+ Mbps     |

* Storage must be SSD — spinning disks will not keep up with the sync or steady-state I/O.
* RAM below 32 GB will cause out-of-memory kills during initial sync.
* The initial sync sustains high CPU and disk I/O for 4–8 hours. Machines with weak single-thread performance or throttled CPU (see Cloud section) will take significantly longer.

***

## Architecture

Igra Orchestra container images are published for:

| Architecture        | Supported |
| ------------------- | --------- |
| x86\_64 (AMD64)     | Yes       |
| ARM64 (AArch64)     | Yes       |
| 32-bit (x86, ARM32) | No        |

***

## Operating System

Igra runs inside Docker containers. Any OS that supports Docker Engine with the Compose plugin is viable.

### Linux (recommended)

The primary and most tested platform. Ubuntu 24.04 LTS is the reference OS.

* Docker Engine must be installed from the [official Docker APT/YUM repository](https://docs.docker.com/engine/install/) — not `snap`, not the distro-packaged `docker.io`.
* Common distributions: Ubuntu 22.04+, Debian 12+, Fedora 39+, RHEL 9+, Amazon Linux 2023.
* Kernel 5.10+ recommended.

### macOS

Supported via Docker Desktop for Mac.

* Apple Silicon (M1/M2/M3/M4) and Intel Macs both work.
* Docker Desktop must be configured with at least **32 GB memory** (Preferences → Resources → Memory).
* Default Docker Desktop memory is 8 GB — this must be increased or the node will crash.
* macOS Ventura 13+ recommended.
* Performance will be lower than native Linux due to the virtualisation layer.

### Windows

Supported via Docker Desktop with WSL 2 backend.

* Windows 10 (build 19041+) or Windows 11.
* WSL 2 must be enabled with a Linux distribution installed (Ubuntu recommended).
* Docker Desktop must be configured with at least **32 GB memory** (Settings → Resources → Memory).
* In `.wslconfig` (located at `%USERPROFILE%\.wslconfig`), ensure sufficient memory is allocated:

  ```ini
  [wsl2]
  memory=32GB
  swap=0
  ```
* Restart WSL after changing `.wslconfig`: `wsl --shutdown`
* NTFS volumes are too slow for the datadir — store Docker volumes on the ext4 filesystem inside WSL 2, not on a Windows-mounted path.
* Performance will be lower than native Linux.

***

## Software Prerequisites

| Software              | Version                                                                         |
| --------------------- | ------------------------------------------------------------------------------- |
| Docker Engine         | 24.0+                                                                           |
| Docker Compose plugin | 2.20+ (the `docker compose` subcommand, not the legacy `docker-compose` binary) |
| Git                   | 2.x                                                                             |
| OpenSSL               | Any (for JWT secret generation)                                                 |
| curl, jq              | Any (for verification and scripting)                                            |

Rust and build tools (`build-essential`, `pkg-config`, `libssl-dev`) are only needed if building from source. Pre-built Docker images do not require them.

***

## Network

### Bandwidth

* **Initial sync**: downloads \~80–100 GB of blockchain data. A 200 Mbps connection completes this in approximately 1 hour; slower connections extend the total sync time proportionally.
* **Steady state**: moderate bandwidth for P2P block propagation and RPC traffic. Expect 1–5 GB/day depending on peer count and RPC usage.

### Ports

| Port  | Protocol | Direction | Required | Purpose                                                          |
| ----- | -------- | --------- | -------- | ---------------------------------------------------------------- |
| 16111 | TCP      | Inbound   | **Yes**  | Kaspa P2P — must be open to all (`0.0.0.0/0`) for peer discovery |
| 16110 | TCP      | Inbound   | Optional | Kaspa gRPC — restrict to trusted IPs                             |
| 80    | TCP      | Inbound   | Optional | Let's Encrypt HTTP challenge (if using a domain)                 |
| 443   | TCP      | Inbound   | Optional | HTTPS RPC endpoint (if using a domain)                           |
| 8545  | TCP      | Inbound   | Optional | EVM JSON-RPC (restrict unless operating a public RPC)            |

Port 16111 is the only port that **must** be publicly reachable. All others can be restricted or omitted depending on your use case.

### Domain (recommended)

A domain with an A record pointing to the node's public IP enables:

* Automatic TLS via Let's Encrypt (managed by Traefik)
* HTTPS RPC endpoint for external consumers

Not required for node operation — the node syncs and builds blocks without a domain.

***

## Cloud Provider Guidance

### AWS

| Setting       | Recommended                                                   |
| ------------- | ------------------------------------------------------------- |
| Instance type | `m5.2xlarge`, `m6i.2xlarge`, or `c5.2xlarge` (8 vCPU / 32 GB) |
| Storage       | 2 TB `gp3` EBS volume (3,000 IOPS baseline is sufficient)     |
| AMI           | Ubuntu 24.04 LTS                                              |

**Avoid T2/T3 burstable instances.** The initial sync sustains high CPU for 4–8+ hours and will exhaust burst credits, throttling the instance to a fraction of its capacity.

### GCP

| Setting      | Recommended                                         |
| ------------ | --------------------------------------------------- |
| Machine type | `e2-standard-8` or `n2-standard-8` (8 vCPU / 32 GB) |
| Disk         | 2 TB SSD Persistent Disk (`pd-ssd`)                 |

### Azure

| Setting | Recommended                        |
| ------- | ---------------------------------- |
| VM size | `Standard_D8s_v5` (8 vCPU / 32 GB) |
| Disk    | 2 TB Premium SSD (`P40` or larger) |

### Bare Metal / VPS

Any provider offering dedicated (non-shared) CPU, 32 GB RAM, and 2 TB SSD. Hetzner, OVH, and Vultr bare-metal plans are commonly used.

***

## Initial Sync Time Estimates

| Phase                  | Description                                            | Typical Duration |
| ---------------------- | ------------------------------------------------------ | ---------------- |
| Kaspa IBD              | Full blockchain header + block download and validation | 4–6 hours        |
| ATAN Historical Import | Finality period download and validation                | 1–3 hours        |
| Igra Catch-up          | Building blocks from genesis to network tip            | 1–2 hours        |

Total first-run time: **6–10 hours** on recommended hardware. Performance scales roughly linearly with CPU speed and disk IOPS.

***

## Steady-State Resource Usage

Once fully synced, resource consumption drops significantly:

| Resource    | Typical Usage                                                                   |
| ----------- | ------------------------------------------------------------------------------- |
| CPU         | 10–30% of 8 cores                                                               |
| RAM         | 10–14 GB                                                                        |
| Disk I/O    | Moderate (block writes, UTXO updates)                                           |
| Disk growth | Varies — monitor with `df -h` and plan for periodic pruning or volume expansion |