Size your infrastructure correctly before deploying an OpenScan.AI explorer — undersized disks and slow storage are the most common causes of trouble.
Components to Size
A self-hosted deployment has four workloads: the EVM chain node, the indexer, PostgreSQL, and the API/frontend. They can share one server for smaller chains or be split across machines for production.
Recommended Specifications
Minimum (small/new chain, evaluation)
| Component | Spec |
|---|---|
| CPU | 8 cores |
| RAM | 32 GB |
| Disk | 1 TB NVMe SSD |
| Network | 1 Gbps |
Production (established chain with real history)
| Component | Spec |
|---|---|
| CPU | 16+ cores |
| RAM | 64–128 GB |
| Disk | 2–8+ TB NVMe SSD (depends on chain age and archive size) |
| Network | 1+ Gbps, unmetered preferred |
Disk Planning
Storage is the constraint that bites first. Budget for:
- Chain node (archive) — often the largest consumer; check your chain’s current archive size and growth rate.
- Explorer database — typically a substantial fraction of the chain size, plus indexes.
- Headroom — keep at least 25–30% free space; database vacuums and migrations need working room.
Use NVMe SSDs. Spinning disks and network storage with high latency will make initial indexing painfully slow and hurt API response times.
CPU and RAM Notes
- The indexer is CPU-hungry during the initial backfill (parallel fetch + decode) and light afterwards.
- PostgreSQL benefits from RAM for caching — give it the largest share on a shared host.
- The API/frontend are modest; 2–4 cores and a few GB of RAM serve most chains.
Network
- The indexer-to-node link should be local or very low latency.
- Public API traffic is usually a few hundred GB/month for an active chain’s explorer.
Scaling Out
For high-traffic deployments:
- Put the chain node on its own machine.
- Run PostgreSQL on a dedicated host with fast storage.
- Scale the API horizontally behind a load balancer.
See Architecture for how the pieces connect, and Monitoring for keeping them healthy.