System requirements

This page outlines the hardware, software, and network requirements for running Chainstack Self-Hosted.

​

Overview

Chainstack Self-Hosted consists of two main components with different resource requirements:

1. Control Panel — the management platform that handles deployments, authentication, and orchestration
2. Blockchain nodes — the actual blockchain clients that you deploy and manage

​

Control Panel requirements

The Control Panel runs inside a Kubernetes cluster and includes the web interface, API services, database, and workflow orchestration.

​

Hardware requirements

​

Software requirements

​

Operating systems

The Control Panel is distributed as an umbrella Helm chart and runs on any Kubernetes-compatible environment. The underlying host operating system should be a modern Linux distribution capable of running Kubernetes. Tested configurations:

• Ubuntu 22.04 LTS with k3s
• Ubuntu 24.04 LTS with k3s

​

Kubernetes storage requirements

A storage class with dynamic provisioning is required for persistent volumes. The installer creates PersistentVolumeClaims for the PostgreSQL database. Tips for storage classes:

• k3s — local-path (default) or TopoLVM for multi-disk setups
• Cloud providers — use the default storage class (gp2/gp3 for AWS, standard for GCP, managed-premium for Azure)
• On-premises — any CSI-compatible storage provisioner

​

Blockchain node requirements

Resource requirements vary by protocol, network, and client. The full per-deployment breakdown — clients, versions, vCPU, RAM, storage, and exposed ports — lives in Supported deployments. The table below summarizes the standard preset totals by architecture family. Use it to size a host, then see the catalog for the exact figures per network.

​

Snapshot bootstrap and storage headroom

​

Storage considerations

• SSD type — TLC NVMe drives are strongly recommended. Avoid QLC drives due to lower write endurance and performance.
• Storage growth — chain data grows over time, so provision headroom beyond the steady-state figure. Ethereum Mainnet, for example, grows approximately 1 TB per year.
• IOPS and throughput — high random read/write IOPS are critical for block processing. Target NVMe drives with sustained write throughput of 1+ GB/s.

For a deep dive on SSD selection for Ethereum nodes, see yorickdowne’s SSD guide.

​

CPU considerations

• Clock speed matters more than core count for blockchain nodes
• Higher single-thread performance improves block processing
• AMD Ryzen 7000/9000 series or Intel Core 12th gen+ recommended

​

Initial sync time

Snapshot-bootstrapped deployments (Ethereum and Optimism Mainnet) start from a pre-built chain snapshot rather than syncing from genesis. Initial bootstrap completes in minutes to hours depending on network conditions; the node then catches up to the chain head in the background. Other deployments sync conventionally and reach the chain head over a longer period. See Initial sync times for the breakdown.

​

Network requirements

​

Internal communication (within Kubernetes cluster)

All Control Panel services communicate internally within the Kubernetes cluster. The following ports are used for internal service-to-service communication:

​

External access

For browser-based UI access, you need to expose both the UI service (cp-cp-ui) and the deployments API service (cp-cp-deployments-api). The browser loads the UI page from cp-cp-ui and then calls cp-cp-deployments-api directly using the --backend-url you set at install time. Either service can be exposed using:

​

Firewall rules

The UI service port (default 80) and the deployments API port (default 8081) must both be reachable from clients that will access the Control Panel through a browser. All other Control Panel services communicate internally inside the cluster. For blockchain nodes, the exposed ports depend on the client. Each deployment’s exposed ports are listed per family in Supported deployments. For example, EVM execution clients expose 8545 (HTTP JSON-RPC) and 8546 (WS JSON-RPC), and Prysm exposes 5052 (Beacon API). Internal ports — engine auth, P2P, and gRPC — are not exposed.

​

Combined infrastructure example

Size a host by adding the Control Panel baseline to the deployment you pick from Supported deployments. As a worked example, the Control Panel plus one Ethereum Mainnet full node: For other deployments, substitute the totals from the catalog and apply the 2× storage peak only to snapshot-bootstrapped deployments (see above).

​

Example server configurations

​

Budget configuration (single Ethereum Mainnet node)

• CPU — AMD Ryzen 5 7600 or Intel Core i5-13400
• RAM — 32 GB DDR5
• Storage — 4 TB NVMe SSD

​

Testnet configuration (2 Ethereum testnet nodes)

• CPU — AMD Ryzen 5 7600 or Intel Core i5-13400
• RAM — 32 GB DDR5
• Storage — 3 TB NVMe SSDs

​

Trusted infrastructure partners

Chainstack Self-Hosted works on any compatible infrastructure you provision yourself. To simplify hardware procurement, you can use one of our trusted partners that offer servers meeting the requirements above.

​

Next steps

Once you’ve verified your system meets these requirements:

1. Environment setup — Install Kubernetes and required tools
2. Quick start guide — Complete walkthrough from zero to running
3. Installation guide — Detailed installation instructions