Blockchain node as a service vs dedicated nodes: how to choose

Almost every crypto product reads from a blockchain node: to show balances, detect deposits, broadcast withdrawals or index events. The question is not whether you need nodes, but who runs them and who else shares them.

Three ways to get blockchain data

1. Shared RPC or node as a service. A provider runs large fleets of nodes and sells access by request or by plan. You get an endpoint in minutes. Many customers share the same nodes, so there are rate limits, and the provider sees your requests: which addresses you watch and which transactions you send.

2. Dedicated nodes run by a provider. Nodes serve only you. Someone else handles the servers, the sync, client upgrades, hard forks and failover. The best version puts the servers in your name, so you keep the infrastructure if you change provider.

3. Nodes run by your own team. Full control, and full responsibility. Nodes need care: clients release often, hard forks have deadlines, disks fill up, and a node that falls behind looks healthy to a simple port check.

How the options compare

	Shared RPC	Dedicated, managed	Self-run
Time to first request	Minutes	1–2 weeks (mostly initial sync)	Weeks, plus learning
Rate limits	Plan limits, shared	Only your hardware	Only your hardware
Privacy of requests	Provider sees them	Only you	Only you
Cost as volume grows	Grows with requests	Flat per node	Flat per node, plus staff time
Upgrades and hard forks	Provider	Provider	You
Evidence for an auditor	Provider’s reports	Your own records and code	Your own records and code

Where shared RPC is the right answer

• Prototypes, hackathons and early products.
• Low-volume reads, where a short outage or a stale block costs nothing.
• Occasional deep-history queries that would need an expensive archive node.
• A fallback behind your own nodes.

Where dedicated nodes pay off

• Deposits and withdrawals. A stale or missing block looks like a missing payment to your customer and your support team.
• High or spiky volume. Request-priced plans get expensive, and rate limits hit at the worst moment, such as a market spike.
• Privacy. The addresses you watch and the transactions you broadcast reveal your business. With dedicated nodes on a private network, nobody else sees them.
• Regulation. Under MiCA, crypto-asset service providers are financial entities under DORA. A node provider that supports a critical function goes into your register of ICT providers, needs contract clauses and an exit plan. Infrastructure in your own name, defined as code, is easier to explain.

Questions to ask any node provider

1. Who else uses the nodes that serve my requests?
2. What are the rate limits, and what happens when I hit them: errors, queueing or extra charges?
3. Who can see my requests and the addresses I query, and how long are logs kept?
4. How do you detect a node that is up but behind the chain? What happens to my traffic then?
5. How are client upgrades and hard forks handled, and how much notice do I get?
6. Who owns the servers? If I leave, what do I keep?
7. Where are the servers, and which subcontractors are involved?
8. Can you give me what I need for my DORA register and audit: service description, locations, subcontractors, an exit plan?

If you run nodes yourself: five basics

• Never expose admin interfaces. Bitcoin Core RPC should listen only on a private network (rpcbind, rpcallowip). On Ethereum clients, keep namespaces such as admin and debug off any endpoint others can reach.
• Check sync, not ports. Compare each node’s block height with the network, and take lagging nodes out of the load balancer automatically.
• Run at least two nodes per network that matters, so you can upgrade one at a time.
• Watch disk growth. Chains grow constantly; a full disk is one of the most common node outages.
• Describe everything as code. Servers in Terraform, configuration in Ansible, access rules in Git. Rebuilding a node should be a command, not an afternoon of memory work.

Our approach

We run dedicated blockchain nodes as a service for any public chain, on servers rented in your name, with chain-aware health checks, rolling upgrades and monitoring. Eight networks run in our production fleet today; you can read how in our blockchain node fleet case.