RPC and blockchain nodes

Run your own blockchain full, archive, or validator nodes and the RPC endpoints in front of them on Quake AI, on customer-owned instances you control. Quake AI runs no managed node or RPC product: you operate the node software on Compute, keep chain data on NVMe Block Storage, and expose RPC through Quake AI networking. Ethereum is the strongest fit on this page; Solana, Bitcoin, and other chains differ in RAM, disk, and bandwidth needs, and the per-chain fit section below sizes each workload.

What this is for#

Run your own Ethereum, Solana, Bitcoin, and other chain nodes and RPC endpoints on Quake AI rather than paying a managed provider per request. You bring the client software (geth, erigon, reth, bitcoind, solana-validator, and the rest); Quake AI supplies the Compute, NVMe Block Storage, networking, and snapshot storage underneath. The outcome is an RPC endpoint and node fleet you own end to end, sized for the chain you run.

Reference architecture#

Download diagram: SVG, PNG, and PDF.

A single node starts from the simple VM template with two value-add variations. Put an API gateway or edge reverse proxy in front of several nodes to distribute RPC requests.

1. Compute instances. Run each node on an instance sized for the chain. Ethereum execution clients are disk-throughput and clock-speed bound rather than thread-count bound; Solana validators need more RAM and CPU. Pick a flavor from the flavor catalog and create the instance. Node software is CPU-bound, so a GPU is not required for any of the chains on this page.

2. Block Storage for chain data. Attach an NVMe Block Storage volume for chain state and history, separate from the root disk. Volumes are NVMe-backed, support online capacity extension as the chain grows, and reach up to 29,800 GiB each, which covers archive nodes whose footprint runs into the tens of terabytes.

3. Networking for the RPC endpoint. Attach a floating IP to an API gateway or reverse-proxy VM as the stable public address. Configure several node backends on the gateway, health-check them at the application layer, and restrict the RPC port to known callers. Open only the peer-to-peer ports your client needs with security groups.

4. Snapshots and recovery. Take Block Storage snapshots of synced chain data, and keep snapshot or chain exports in Object Storage so a replacement node restores from a recent snapshot instead of syncing from genesis again.

5. Observability. Deploy the monitoring stack template to watch sync height, peer count, disk throughput, and resource use, and start from the single-VM template when you scaffold a node by hand.

6. Consumers of the endpoint. Wallet back ends, keepers, and indexers point at this RPC endpoint. See Wallet and payments back end and the Web3 and stablecoin infrastructure industry leaf for the surrounding stack.

Services involved#

Self-hosted nodes and managed RPC#

Managed RPC providers such as Alchemy and QuickNode sell an endpoint billed per request, with pricing that scales with request volume; a managed-provider pricing comparison surveys that landscape. Running your own node trades that per-request bill for the operational work of sizing, syncing, monitoring, and upgrading the node yourself, plus the flat cost of the underlying Compute and Block Storage.

The trade-off favors self-hosting when request volume is high enough that managed bills dominate, when you need archive data without a metered surcharge, or when you want control over the client version and peering. Managed RPC stays the simpler choice at low or spiky traffic where you would rather not operate a node at all. Many teams run both: a self-hosted node for steady load and a managed endpoint as overflow or failover. Quake AI has no managed RPC offering, so the self-hosted path is the one this page documents.

Per-chain fit#

Ethereum (strongest fit). A full or archive Ethereum node runs well on a single instance with an NVMe volume for chain data and steady peer traffic after the initial sync. The common clients are geth, erigon, and reth. The published reth release baseline is a 2 TB NVMe SSD, at least 8 GB of RAM, a higher-clock-speed CPU, and a modest network link; production geth and erigon archive nodes now want materially more disk, and the trend over time is upward. The official geth hardware requirements track the current numbers. Size the volume for the client and node type you run, and extend it as the chain grows.

Bitcoin (straightforward). A Bitcoin full node is the lightest of the chains here. A pruned full node fits under 1 TB, and a node that keeps full history needs more but stays far below Ethereum archive sizes. CPU and bandwidth needs are modest, so a general-purpose flavor with an NVMe volume covers it.

Solana (the heaviest workload here). Solana validators need substantially more RAM and CPU per node than Ethereum, plus high sustained inbound bandwidth during normal operation. Pick a flavor from the flavor catalog, attach NVMe Block Storage, and measure inbound throughput against your validator profile before you commit. The strongest Quake AI fit is RPC and read-serving nodes; the most demanding validator configurations often run on bare-metal hosts instead.

Sui and other Move-based chains (validate sizing). Sui and the Move-based chains around it have smaller operator bases and less published reference hardware than Ethereum. Their node software (for example sui and aptos) sits between Bitcoin and Solana on hardware needs. Treat sizing as something to validate against current chain-specific guidance and your own measurements rather than a settled recipe.

Get started#

• Create an instance: provision the Compute the node runs on.
• Flavors: choose a vCPU and RAM shape for the chain and node type.
• Volumes: attach and size NVMe Block Storage for chain data.
• Create a snapshot: capture synced chain data for fast recovery.
• Floating IPs and the API gateway: publish the RPC endpoint behind a stable address and route requests across node backends.
• Monitoring stack template: track sync height, peers, and disk throughput.
• Web3 and stablecoin infrastructure: the wider Web3 stack this node serves.

Estimate the cost#

Considerations and limits#

• Sync time depends on Block Storage throughput. Block Storage volumes are premium NVMe flash (Volumes). Archive-node sync is limited by disk throughput. Quake AI publishes volume capacity, durability, and encryption in the Block Storage docs; run a timed sync test for your client, node type, and flavor before you commit to a production timeline.
• No managed node, RPC, or database service. You operate the node software, the RPC endpoint, and any indexer database yourself on customer-owned instances. There is no managed node product, no managed RPC endpoint, and no managed warehouse-class database; indexers that pair with a node run on the self-managed PostgreSQL template or a database you install on Compute.
• CPU-only compute. The flavor catalog is CPU-backed. Node and RPC software is CPU-bound and needs no GPU, so this is not a constraint for the chains here. GPU-accelerated Web3 workloads such as zero-knowledge proving are out of scope for the platform today.
• Flat egress. Quake AI applies a no-egress-fee policy, including data transfer between regions. For an RPC provider serving high outbound request volume, predictable egress is the relevant economic property; for validator operation, sustained inbound bandwidth matters more and should be measured per chain.
• Three US regions. All current regions are in the United States. A geographically distributed RPC fleet across continents is not something the platform serves today; design US-region redundancy with multiple instances and DNS or routing at the application layer, and plan non-US points of presence elsewhere.
• Validator key management. Quake AI holds SOC 2 attestations (Compliance and certifications), which cover the cloud-infrastructure role for a self-hosted node. Validator-staking workloads put node key material in a position of direct financial consequence; the platform posture does not substitute for your own key-management practice. There is no native hardware security module or remote-signer service.
• Acceptable use. Blockchain node workloads run within the Quake AI usage guidelines and Acceptable Use Policy. Review them for the authoritative statement of what is permitted on the platform.
• When this pattern is not the right fit.
  • Teams whose traffic is low or spiky enough that a managed RPC endpoint is cheaper than operating a node.
  • Validator configurations whose sustained bandwidth or hardware needs exceed what a CPU-only cloud VM serves, where bare metal is the better target.
  • Workloads that need RPC points of presence outside the United States today.