Run Chainstack Nodes on a Dedicated Server

Self-host a full or archive blockchain node on bare metal you don't share. Bring your own node to Chainstack (BYOC), keep root and IPMI from day one, and drop the rate limits that come with a managed endpoint.

What you can do with Chainstack on a dedicated server

Chainstack is managed blockchain infrastructure for 70+ chains. Run a dedicated server, and you handle the node yourself, while Chainstack's tooling manages it.

Run a full or archive node with no rate limits

A node you run yourself has no RPS cap and no monthly request-unit budget. Run one full node, or an archive node that keeps every historical state; the only ceiling is the hardware.

Bring Your Own Cloud (BYOC)

Chainstack's BYOC deploys its node software and management layer onto infrastructure you own. You get Chainstack's orchestration and monitoring; is*hosting provides the metal underneath.

Power a production dApp or RPC backend

A self-hosted node handles millions of RPC calls a day at flat cost. Put it behind your own load balancer and add boxes to scale reads, and latency stays predictable as nothing is throttling you.

Index at scale — every transaction, no sampling

A node you own lets an indexer read every pending transaction. Mempool indexers, subgraph backends, and analytics pipelines run at full throughput here, which a rate-limited endpoint can't sustain.

Run a validator or staking node

A dedicated box gives a validator cores that won't get rescheduled mid-epoch and an IP that doesn't rotate. For chains where signing speed affects rewards, pick a high-frequency CPU.

Consolidate multi-chain nodes on one box

A high-core EPYC box with plenty of RAM runs several chains' nodes side by side. Combine servers in one location under a single traffic plan with the bandwidth pool feature and manage them as one fleet.
Choose a dedicated server for Chainstack
Storage matters more than CPU as one of the main Chainstack server requirements. A full node and an archive node differ mostly in how much disk they need, so choose the config by disk first.

How to deploy a Chainstack node on a dedicated server

A full Ethereum node takes hours to days to sync and an archive node needs multiple terabytes. These steps take you from an empty box to a syncing node with a working RPC endpoint. Hardening, monitoring, and reverse-proxy setup are listed as next steps at the end.

Step 01 — Order the server and get access

Pick a config from the block above (a single-chain full node fits the smaller NVMe tier). After provisioning, you receive the IP, root credentials, and IPMI details by email. Connect over SSH:

ssh root@YOUR_SERVER_IP

IPMI lets you reinstall or console in if the OS won't boot, without a support ticket.

Step 02 — Prepare the NVMe for chain data

Confirm the drives are present and mount the one that will hold chain state:

lsblkmkfs.ext4 /dev/nvme1n1mkdir -p /data/ethereummount /dev/nvme1n1 /data/ethereumecho '/dev/nvme1n1 /data/ethereum ext4 defaults 0 0' >> /etc/fstab

Keep chain data on the dedicated NVMe, not the root disk.

Step 03 — Install the execution client

Install Geth from the official PPA:

add-apt-repository -y ppa:ethereum/ethereumapt update && apt install -y ethereumgeth version

Step 04 — Install a consensus client

Post-Merge Ethereum needs a consensus client alongside Geth. Install Lighthouse and generate the shared JWT secret the two clients authenticate with:

openssl rand -hex 32 | tr -d '\n' > /data/ethereum/jwt.hex

Point Lighthouse at Geth's engine API on port 8551.

Step 05 — Start Geth and expose the RPC endpoint

Run Geth against the NVMe path and enable the HTTP-RPC API:

geth --datadir /data/ethereum \  --authrpc.jwtsecret /data/ethereum/jwt.hex \  --http --http.api eth,net,web3 \  --http.addr 0.0.0.0 --http.port 8545

Binding to 0.0.0.0 exposes the endpoint on all interfaces — fine while you verify, but lock it down before production.

Step 06 — Run as a service and confirm the sync

Wrap Geth in a systemd unit so it survives reboots and restarts on failure, then watch the sync begin:

systemctl enable --now gethgeth attach --exec 'eth.syncing'

While syncing you'll see the block numbers rising:

{  currentBlock: 2148740,  highestBlock: 21463991,  ...}

When eth.syncing returns false, the node is fully synced and the RPC endpoint is live.

Step 07 — Verify the endpoint answers

From your app server, confirm the node responds to a JSON-RPC call:

curl -s -X POST http://YOUR_SERVER_IP:8545 \  -H "Content-Type: application/json" \  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

A hex block number in the response means your self-hosted node is serving requests.

Next steps (do these before production): restrict the RPC port with UFW and a reverse proxy, add TLS, set up monitoring for peer count and disk usage, and — if you're using Chainstack BYOC — connect the node to your self-hosted Chainstack project so it appears in the console.

Common gotchas

Sync looks stuck at a low block for hours. That's usually normal for the state-download phase, not a fault. Check peer count with admin.peers.length in geth attach — if it's zero, your firewall is blocking the P2P port (30303). Open it and peers will come.

Disk fills up faster than expected. You deployed an archive node by accident. Full (“snap”) sync keeps recent state; archive keeps everything and needs multiple TB. Confirm which mode you started, and size the NVMe to the mode, not the other way around.

RPC endpoint refuses connections from your app. Geth binds to localhost unless told otherwise. Either it's not started with --http.addr 0.0.0.0, or a firewall rule is dropping 8545. Check both before assuming the node is broken.

Ready to run your own node?

Configure a dedicated server, get root and IPMI on delivery, and start syncing. Full and archive-node configs across five locations.

Configure a Dedicated Server

is*hosting infrastructure is a solid base for Chainstack

Bare metal, not a slice of it

A high-core AMD EPYC platform, hundreds of gigabytes of RAM, no hypervisor in the path. Chain sync is I/O-bound, and nothing else competes for the disk. Root and IPMI from the first boot.

NVMe built for chain state

Archive nodes hammer storage with random reads that wear out consumer SSDs. Enterprise NVMe in multi-drive configurations, with soft-RAID set up at deployment, is built for that workload.

DDoS-protected, migration included

Free DDoS protection in the Netherlands, rated 95% effective, and free project migration if you're moving a node off another host. Our own hardware in Tier-3+ data centers across five locations, monitored 24/7.

Frequently asked questions about Chainstack dedicated server hosting

What is Chainstack dedicated server hosting?

It's running a blockchain node yourself on dedicated hardware, instead of consuming Chainstack's managed endpoints. You get self-hosted Chainstack's node software and management tooling (via BYOC) on an is*hosting bare-metal server you control.

Do I need a dedicated server, or is a VPS enough?

Depends on whether you run the node or just talk to one. If you're consuming a managed Chainstack endpoint — a monitor, a bot, a dev script — a VPS is plenty and cheaper (from $10.19/mo across 40+ locations). If you're self-hosting a full or archive node, you need dedicated NVMe and RAM that a VPS doesn't provide.

Which chains can I run on a dedicated server?

Any chain Chainstack supports (70+), constrained only by the hardware. Ethereum and other EVM chains run on the standard EPYC configurations; some of our boxes are tagged for Solana, which is heavier on I/O and RAM. Archive nodes and high-throughput chains want the larger multi-drive NVMe configuration with maximum RAM.

Do I need a GPU for a Chainstack node?

No. A blockchain node is CPU, RAM, disk, and network — a GPU does nothing for sync or RPC and only adds to the bill. Pick a configuration without one. GPU dedicated servers are for AI, ML, and rendering workloads.

How long does a full node take to sync?

Hours to a few days for a snap-synced Ethereum full node, depending on the chain and client. An archive node takes longer and needs multiple terabytes. Sync time is a client-and-chain property, not a hosting one — the NVMe and bandwidth here remove the storage and network bottlenecks, but the chain still has to download.

How does this compare to Chainstack RPC node providers?

Chainstack is one of several Chainstack RPC node providers offering managed endpoints — you send requests to their infrastructure and pay per request unit. Running the node yourself flips that: you own the Chainstack RPC endpoint, set no rate limits, and keep the data on your hardware. Managed is simpler to start; self-hosted wins once your call volume, archive needs, or compliance rules outgrow a shared endpoint.

Do you offer managed dedicated servers?

Yes. Choose unmanaged for full root-level control of the node, or managed if you'd rather the is*hosting team handle OS updates, monitoring, and backups while you focus on the application. Managed dedicated servers are available in Finland, Germany, the Netherlands, Ukraine, and the USA.

More from is*hosting

VPS

Deploy VPS instances across 40+ locations for lighter Chainstack workloads — monitors, bots, and dev scripts that consume a managed endpoint.
Explore
From $5.94 /mo

Data Storage

Off-server backups for your node's keys and snapshots. Faster to restore a targeted backup than to re-sync a full node.
Explore
From $1.00 /mo

Recent Posts

  • MiMo-V2.5

    MiMo-V2.5: Open-Weight Omnimodal AI That Sees, Hears, and Acts

    Meet MiMo-V2.5, Xiaomi's MIT-licensed omnimodal model with audio, vision, a 1M-token context, and frontier agentic ability. See how it fits into is*smart.

    UTC 2026-09-08 2 min reading
  • MiniMax M3

    MiniMax M3: Open-Weight Frontier AI for Coding and Agents

    Meet MiniMax M3, an open-weight model with frontier coding, a 1M-token context, and native multimodality, built for long agentic runs. See it in is*smart.

    UTC 2026-09-08 2 min reading
  • Gemini 3.1 Flash-Lite

    Gemini 3.1 Flash-Lite: Low-Cost, Fast, Multimodal AI for High-Volume Work

    Meet Gemini 3.1 Flash-Lite, Google's most cost-efficient multimodal model, built for high-volume translation, classification, and data extraction at scale.

    UTC 2026-09-08 2 min reading