Self-Hosted Node vs RPC Provider: The Cost Math

By John Sullivan · June 23, 2026 · updated November 1, 2026 · 6 min read · #self-hosted node #rpc provider #comparison #infrastructure

"Why pay a provider when I can just run my own node?" It's the most natural question in the world, and the math that follows it is almost always wrong — not because self-hosting is a bad idea, but because the comparison people run is rigged from the start. They put a provider's monthly bill on one side of the scale and a cloud instance's price on the other, see that the instance is cheaper, and call it settled. The instance is the one line item self-hosting advertises. It's the four or five it doesn't that decide the real answer.

This post is the honest version of that comparison: every cost on both sides, and the point where the scale actually tips.

The cost self-hosting shows you

A single Ethereum full node needs real hardware: a fast multi-core CPU, 32 GB of RAM, and — the part that bites — a large, fast NVMe SSD, because consensus and execution clients punish slow disks. Budget 2–4 TB for a full node today; an archive node needs substantially more and keeps growing. A useful 2026 planning range is $150–250/month on bare metal per node, or $300–500/month on a cloud instance with equivalent disk and IOPS.

That's the number people quote. Now the rest of the bill.

The costs it doesn't

  • Storage growth. Chains only get bigger. The disk that's 60% full today is full in a year, and "migrate to a bigger volume" is a maintenance window, not a line item you forget. Archive nodes make this worse because you cannot prune your way out of it.
  • Bandwidth. A node gossiping with peers and serving your own queries moves real data. On cloud, egress is metered and adds up; budget $20–100/month depending on peering and load.
  • Sync time. A full node takes hours to a couple of days to sync; an archive node can take a week or more. That's a week before the box earns anything, and it recurs every time you rebuild, migrate, or corrupt a database.
  • Engineer hours — the big one. Someone has to monitor it, patch it, restart it when it wedges, and stay awake for hard forks where a missed client upgrade means your node silently follows the wrong chain. Even a quiet month is a few hours; a fork month or a disk-full incident is a lot more. At a loaded rate of $100–150/hour, two to four hours a month is $200–600 — the calm estimate.
  • Redundancy. One node is a single point of failure. The moment it's in front of users, you need at least two so an upgrade or a crash doesn't take you down — which roughly doubles the hardware line and adds a load balancer to babysit.
  • The per-chain multiplier. Every cost above is per chain. Need Ethereum, Base, Arbitrum, and Polygon? That's four node stacks, four sync processes, four upgrade calendars, four things that can break at 3 a.m.

Add it up for one production-grade, minimally redundant Ethereum full node and you're realistically at $600–1,200/month all-in — most of which is people, not metal. Multiply per chain from there.

What a provider actually costs

A managed RPC provider folds all of that — hardware, redundancy, multi-region routing, upgrades, fork handling, archive storage, every chain — into one predictable bill. With a flat-rate provider there are no compute units to forecast and no per-chain stacks to operate; you point your app at an endpoint and move on:

https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY

SwiftNodes' current published plans make the comparison concrete: the free tier covers 20 HTTP requests/second and 250,000 requests/month; Starter is $49/month for 70 req/s, Growth $89 for 150 req/s, Scale $149 for 300 req/s, and Pro $249 for 600 req/s. Paid plans have no monthly request cap — the limit is the rate, not the volume.

For most applications, that means the provider side of the table is $49–89/month and the bill is knowable before you ship. The value isn't only the dollar figure; it's that none of the hours behind it are yours.

The real comparison

Cost Self-hosted (1 chain, production HA) RPC provider
Hardware / hosting $300–1,000/mo for two nodes included
Bandwidth $20–100/mo included
Redundancy (HA) already in the two-node figure included
Engineer time $200–600+/mo ~zero
Each additional chain +$600–1,200/mo included
Sync / setup hours to weeks minutes
All-in $600–1,200+/mo per chain $49–89/mo for most teams

The ranges are deliberately wide. A used bare-metal box in one region is not the same as two cloud instances with regional failover, and a team that already runs infrastructure is not the same as a two-person dApp team. The point is the shape: the server is not the expensive part, and the per-chain multiplier is brutal.

The break-even that usually doesn't arrive

For ordinary JSON-RPC, there is no volume break-even to wait for. A flat-rate plan is limited by requests per second, not by total requests, so sending more monthly calls does not make self-hosting cheaper by comparison. One high-availability chain at $600–1,200/month is roughly 7–24× a $49–89 provider plan before you count the next chain.

That changes only when one of these is true:

  • You need something a provider cannot sell you. A private mempool, custom tracing, MEV infrastructure, a non-standard client configuration, or data-residency requirements can make your own node non-optional regardless of price.
  • You already have the operations team. If node operations fit into an existing on-call rotation, the marginal people-cost really is lower than the table implies. It is not zero, though: someone still owns upgrades, disk capacity and incidents.
  • Your only alternative is an enterprise quote above your fully loaded cost. That is a real case at very large sustained throughput, but compare the quote with the all-in number — including the engineer hours — rather than with a list price for a shared plan.

A provider wins — usually decisively — when you're multi-chain, when load is variable or spiky, when you're a small team without a dedicated infra function, when you need archive access across several chains, or when time-to-market matters more than squeezing the last dollar at scale.

What to measure before you decide

  1. Peak requests per second, not just monthly requests. Flat-rate plans are sold on this number.
  2. How many chains you need in production, including testnets and archive reads.
  3. Your real on-call cost. If nobody on the team has patched a client during a hard fork, that work is a new hire or a contractor, not a free side task.
  4. The capabilities that are non-negotiable: WebSocket subscriptions, trace/debug methods, archive depth, private transaction routing, data residency.

If the answer is “one chain, standard reads, a small team,” a flat-rate endpoint is almost always cheaper all-in. If the answer involves custom node behaviour or a compliance requirement, price the node honestly — including the second one.

The honest verdict

Self-hosting isn't free; the server is the cheap part. What sinks the naive comparison is everything attached to keeping that server correct and redundant across every chain you touch — and that's mostly engineer-hours, the most expensive resource you have. A provider isn't always cheaper on paper, but for standard RPC it is usually cheaper all-in at the volumes most teams actually run.

Still deciding between a full and an archive node for a future self-hosted setup? Full Node vs Archive Node breaks down which one you actually need.

SwiftNodes is flat-rate RPC across Ethereum, Base, and dozens of other chains — predictable pricing, every chain included, none of the 3 a.m. pages. See the current plans and rate limits, or grab a free key at swiftnodes.io and measure before you build.

J
John Sullivan
Infrastructure Writer, SwiftNodes

John Sullivan covers RPC infrastructure, node operations, and multi-chain development at SwiftNodes — what it actually takes to keep endpoints fast, fresh, and reliable across EVM and non-EVM networks.

Related posts

Try SwiftNodes free — multi-chain RPC across 83 networks, flat-rate pricing, pay by card or crypto, no KYC. Get an API key in 30 seconds →