Self-hosted RPC vs managed RPC: cost and control trade-offs

Most teams pick their RPC setup once, early, and never revisit it. Then traffic grows, a few users start complaining that quotes do not match execution, and the question comes back: do we run this ourselves or pay someone to run it for us.

This is the self-hosted versus managed RPC decision. It is not really about price per request. It is about who carries the operational weight when an endpoint falls behind, and how much control you are willing to trade for that.

What an RPC endpoint actually does for you

An RPC endpoint is the door between your application and the chain. Every read, every transaction broadcast, every event subscription goes through it. When it is healthy, nobody thinks about it. When it lags, the symptoms show up somewhere else entirely.

A pattern worth noticing: users on r/defi have started tracking the gap between a quoted swap output and the amount that actually lands. The quote looks fine, the execution does not match. Some of that is slippage and MEV. But a slow or stale RPC node feeding the front end stale state is a real contributor, and it is invisible until someone measures it. The same week, three separate threads asked which bridge to trust after getting three different quotes from three different bridges for the same transfer.

These are not bridge problems or DEX problems in isolation. They are downstream of how fresh and how fast the underlying node data is. The RPC layer is where that freshness is won or lost.

The case for self-hosting

Running your own node gives you control. You choose the client, the hardware, the sync mode, and the geography. You see the raw mempool. There is no third party between you and the chain, which matters for latency-sensitive work like sequencing, oracle updates, or MEV.

The costs are operational, not just financial:

• Sync and maintenance. Full and archive nodes need babysitting. Reorgs, client upgrades, disk pressure, state bloat. A team running its own archive node is signing up for ongoing work, not a one-time setup.
• Storage growth. Archive state grows continuously. An archive node workload that needs around 16 TB of fast storage is not unusual, and that footprint only goes up. On hyperscalers the storage line alone gets painful fast.
• Egress. A public-facing RPC endpoint serves continuous JSON-RPC traffic. On cloud, outbound data is metered per gigabyte, and a busy endpoint can generate several terabytes a month. We broke the egress maths down in our RPC endpoint hosting cost comparison, and egress is often the line that surprises people.
• On-call. Someone has to wake up when the node falls behind at 3am. For a small team that is the founder or the one infra engineer, which means it is the most expensive time you have.

Self-hosting wins when you need control you cannot buy: custom client config, private mempool access, a specific geography, or sub-millisecond latency where the network path matters.

The case for managed RPC

Managed RPC means someone else runs the node and you call an endpoint. You trade direct control for not carrying the operational weight.

The honest version of the trade-off:

• You stop maintaining sync. Client upgrades, reorgs, disk pressure, and archive growth become the provider's problem.
• Pricing becomes predictable, or it does not. This is where managed providers differ sharply. Credit and compute-unit billing means your bill moves with traffic and can spike without warning. Fixed request-per-second pricing means you know the number in advance. We price RPC at a fixed sustained request rate with no monthly cap and no overage charges, which is unusual in the market.
• You inherit the provider's reliability, good or bad. A managed endpoint is only as good as the infrastructure under it. If the provider runs on shared cloud capacity, you inherit their noisy-neighbour risk and their SLA ceiling.

Managed wins when RPC is not your differentiator. If you are a protocol team, your edge is your protocol, not your node-ops practice. Paying someone to run the endpoint properly frees the team to build.

The reliability point most comparisons skip

Cost is the easy axis to compare because it is a number. Reliability is the one users actually feel, and it rarely appears in a pricing table.

When a quote does not match execution, when a bridge returns a stale balance, when a transaction sits unconfirmed, the user blames the app. They do not know or care whether the RPC node behind it was three blocks behind. The reliability of that node is your product experience, whether you run it or rent it.

So the real question is not only "what does this cost per month". It is "what happens to my users when this endpoint degrades, and who is accountable for fixing it". Self-hosting makes you accountable. Managed makes the provider accountable, which is only worth something if the provider is actually good.

A simple way to decide

• Run it yourself if RPC performance is a core part of your edge, you need control you cannot buy, and you have or will hire the operational capacity to run nodes properly around the clock.
• Buy managed if RPC is plumbing rather than differentiation, you want predictable cost and predictable reliability, and you would rather your team spent its time on the product.

Either way, measure the gap between quoted and actual behaviour your users see. That number tells you more about your RPC layer than the line item ever will.

LinkPool runs validator and RPC infrastructure on our own hardware across three availability zones in Manchester, and we have operated mainnet infrastructure since 2017 with zero slashing. If you are weighing the self-hosted versus managed decision, that operating history is the lens we bring to it.