Your Ethereum node synced for 18 hours, then ran out of disk space at 94%. You resize the volume, restart the sync, and wait another day.
A client update drops. Your Geth version is two minor releases behind. Meanwhile, the team building the actual product is blocked - waiting for a stable RPC endpoint to test against.
This scenario plays out constantly. Teams choose self-hosting for control and cost savings, only to discover that "running a node" and "operating production infrastructure" are fundamentally different problems. Teams that default to managed providers sometimes pay 10x more than necessary, or hit rate limits at the worst possible moment.
The right choice depends on your specific situation: team size, request volume, compliance requirements, chain coverage, and tolerance for operational complexity. This guide breaks down the concrete costs, hardware requirements, and operational realities behind each option so you can make that decision with real numbers.
The Fundamental Trade-Off
Self-hosting gives you control. You own the hardware, configure the client software, and set your own rate limits. No third party can throttle your requests, change pricing, or block access to specific regions.
Managed providers give you speed and simplicity. Your first RPC call happens in minutes instead of days. Failover, monitoring, and client upgrades become someone else's problem. You pay per request instead of per server.
The trade-off sounds clean in theory. In practice, both options carry hidden costs that shift the equation. Self-hosting demands ongoing DevOps investment that often exceeds hardware costs. Managed providers introduce dependency on third-party uptime and pricing decisions.
What Self-Hosting Actually Requires
Running your own node starts with hardware. But hardware requirements vary dramatically by chain, and undersizing any component creates problems that are expensive to fix.
Hardware Requirements by Chain
| Chain | CPU | RAM | Storage | Growth Rate | Sync Time |
|---|---|---|---|---|---|
| Ethereum (full) | 4+ cores | 16 GB | 2 TB NVMe | ~14 GB/week | 6-24 hrs (snap sync) |
| Ethereum (archive, Geth) | 8+ cores | 32 GB | 18-20 TB | ~14 GB/week | 4-8 weeks |
| Ethereum (archive, Erigon v3) | 8+ cores | 32 GB | ~1.77 TB | ~14 GB/week | ~2 hrs |
| Solana | AMD EPYC (single-socket) | 512 GB (1 TB rec.) | 3x NVMe (OS+accounts+ledger) | Terabytes/month | Days |
| BSC | 16+ cores | 128 GB | 4+ TB NVMe | ~110 GB/day | Snapshot required |
| Polygon (full) | 8+ cores | 32 GB | 2 TB SSD | Variable | Hours |
| Polygon (archive) | 16+ cores | 64 GB | 16+ TB (Geth), 4.5 TB (Erigon) | Variable | 1-2 weeks |
| Arbitrum | 4+ vCPU | 16 GB | 4+ TB NVMe | ~3 GB/day | Days-weeks |
| Arbitrum (archive) | 8+ cores | 32 GB | 38+ TB | ~3 GB/day | 1-3 weeks |
| Optimism/Base | 4+ cores | 16 GB | 2+ TB NVMe | ~5-6 GB/day | ~20 hrs (snap) |
A few chain-specific details stand out.
Solana is in a class of its own. The 512 GB RAM minimum (with 1 TB recommended), 10 Gbps network requirement, and multi-drive NVMe configuration make it one of the most demanding chains to self-host. Archive storage exceeds 300 TB and grows by terabytes per month. Running Solana on cloud VMs is essentially cost-prohibitive.
BSC growth rate is extreme. At 110 GB per day, a 4 TB drive fills in roughly 36 days beyond the initial snapshot. Syncing from genesis is impractical - you must start from the latest snapshot and plan for rapid storage expansion.
L2 nodes have hidden dependencies. Arbitrum, Optimism, and Base all require access to an L1 Ethereum RPC endpoint. If you self-host the L2 node, you either self-host an Ethereum node too (doubling your infrastructure) or pay a managed provider for L1 access - creating a hybrid setup whether you planned for one or not.
Client choice matters enormously. Ethereum archive storage ranges from 1.77 TB (Erigon v3) to 20 TB (Geth) - an 11x difference. Polygon shows a similar 3.5x gap between Erigon and Geth. Choosing the right client software is as important as choosing the right hardware.
Bandwidth and Networking
Teams focus on storage and compute, but bandwidth is a significant cost driver:
- Ethereum: 30-40 TB/month of network transfer
- Solana: Requires 10 Gbps dedicated connection
- BSC: High bandwidth due to data volume
On cloud providers, egress charges add up quickly. AWS charges $0.09/GB for outbound data transfer in many regions. At 30 TB/month, that is $2,700 in bandwidth alone - before compute or storage costs.
Bare metal providers like Hetzner include generous or unlimited bandwidth, which is one reason they are popular for node hosting. But they come with other trade-offs: limited geographic distribution, less flexible scaling, and longer provisioning times.
The Operational Reality
Hardware is the straightforward part. Ongoing operations are where self-hosting costs compound.
Client Updates and Hard Forks
Ethereum averages 2 major forks per year plus monthly minor client releases. The Pectra upgrade in May 2025 required all operators to update both execution and consensus layer clients before a hard deadline. Missing a fork means your node follows a dead chain, and your applications read incorrect state - silently.
Every chain has its own upgrade cadence. If you run nodes for 5 chains, you are tracking 5 different release schedules, testing 5 different client updates, and coordinating 5 different upgrade windows.
Monitoring Requirements
A node that appears healthy might be falling behind the chain tip, losing peers, or serving stale data. At minimum, you need to monitor:
- Block lag: How far behind the chain tip is your node?
- Peer count: Is the node maintaining healthy connections?
- Disk space: How close are you to capacity?
- RPC latency: Are response times degrading?
- RAM and CPU utilization: Is the node under resource pressure?
- Sync status: Has the node fallen out of sync?
Most teams use Prometheus for metrics collection and Grafana for dashboards and alerting. Setting this up properly takes days, and maintaining it is ongoing work.
Failover and Redundancy
A single node is a single point of failure. Any maintenance window, client update, or hardware issue means downtime for every application depending on that endpoint.
Production deployments require at minimum 2 nodes behind a load balancer (HAProxy or Nginx). Serious production environments run 3+ nodes across geographic regions. Each additional node multiplies hardware costs and operational complexity.
Sync Time Is Downtime
When a node needs to re-sync after a crash, data corruption, or major upgrade, it is unavailable for the duration. The sync times in the hardware table represent best-case scenarios. Ethereum archive sync with Geth takes 4-8 weeks. Arbitrum archive sync takes 1-3 weeks.
During that period, you need fallback infrastructure or your application goes dark.
The Real Cost of Self-Hosting
Hardware pricing is straightforward. Total cost of ownership is harder to calculate because the largest line item is not hardware - it is people.
Hardware Costs
| Provider Type | Monthly Cost | Notes |
|---|---|---|
| Bare metal (Hetzner-class) | $250-750 | Best value for single-location deployments |
| Cloud (AWS/GCP) | $300-800 | Ethereum full node; archive $1,500+/month |
| Solana bare metal | $1,200-2,800 | Production-grade; cloud is cost-prohibitive |
The DevOps Line Item
A blockchain DevOps engineer in the US averages $147,524 per year - about $12,300 per month. Even if node operations represent only 20-30% of that person's role, the prorated cost is $2,000-4,000 per month.
This single line item often exceeds all hardware costs combined, and it is the most commonly underestimated cost when teams evaluate self-hosting.
Total Cost of Ownership by Scenario
| Scenario | Hardware/Month | DevOps (Prorated)/Month | Total/Month |
|---|---|---|---|
| Single ETH full node | $150-300 | $2,000-4,000 | $2,200-4,400 |
| ETH + 2 redundant nodes | $450-900 | $12,000-17,000 | $12,650-18,400 |
| ETH archive + redundancy | $3,000-6,000 | $12,000-17,000 | $15,500-24,000 |
| Multi-chain (5 chains, 2x redundancy) | $2,000-5,000 | $12,000-17,000 | $14,500-23,500 |
The jump from "single node, part-time management" to "production with redundancy" is dramatic. Adding redundancy and archive access pushes costs from $2,200-4,400/month to $15,500-24,000/month - almost entirely due to the dedicated DevOps engineer required at that scale.
For a deeper analysis of archive node costs specifically, see The Hidden Costs of Archive Nodes.
How Managed Providers Work
Managed RPC providers run node infrastructure on your behalf. You get an API endpoint and pay based on usage - either per request, per compute unit, or through a subscription tier.
Architecture
Most managed providers operate node clusters behind load balancers across multiple regions. Your application sends an RPC request, the provider routes it to the nearest healthy node, handles failover automatically, and returns the response. Client updates, monitoring, storage expansion, and redundancy are the provider's responsibility.
From your application's perspective, the endpoint is a single URL. The infrastructure complexity behind it is invisible.
Pricing Models
Your pricing model determines actual cost more than the base rate. Here is how major providers structure billing:
| Provider | Model | Entry Price | How It Works |
|---|---|---|---|
| Alchemy | Compute Units | Variable | Methods cost 10-26+ CUs each; opaque multiplier formula |
| Infura | Credits | $50/month | ~$8.89 per million eth_call requests |
| QuickNode | Credits | $49/month | Method multipliers redesigned in 2024; variable by method |
| Chainstack | Request Units | Variable | 1 RU for full node calls, 2 RU for archive; Unlimited Node add-on available |
| Dwellir | 1:1 credits | $49/month | 1 response = 1 credit; all methods same price including trace/debug |
| dRPC | Flat rate | $6/M requests | Simple per-request pricing with less tooling |
Compute unit billing is the primary developer pain point with managed providers. When eth_call costs 1 unit but debug_traceTransaction costs 26 units, forecasting monthly spend becomes a spreadsheet exercise. Dwellir's 1:1 credit model - where every method costs exactly 1 credit - eliminates this complexity. For a detailed comparison, see RPC Providers Without Compute Units.
SLA Expectations
Most managed providers offer 99.9% uptime SLAs on paid plans, with enterprise tiers reaching 99.99%. Achieving equivalent uptime with self-hosted infrastructure requires 3+ nodes across multiple regions with automated failover - the $15,000-24,000/month scenario from the TCO table above.
Managed providers are not immune to outages. The AWS outage in October 2025 took down Coinbase, Robinhood, Infura, and Base simultaneously. Infura's 2022 geoblocking incident accidentally blocked Venezuelan users. Relying on any single provider - managed or not - creates concentration risk.
TCO Comparison: Self-Hosted vs Managed
The following comparison maps self-hosted costs against managed provider costs at different scale levels. Managed costs use Dwellir's pricing (Developer $49/25M credits, Growth $299/150M, Scale $999/500M) as a baseline, with notes on how compute-unit providers compare.
Low Volume: Up to 25 Million Requests/Month
| Cost Category | Self-Hosted | Managed (Dwellir) |
|---|---|---|
| Infrastructure | $150-300/month | $49/month |
| DevOps (prorated) | $2,000-4,000/month | $0 |
| Monitoring/tooling | $50-100/month | Included |
| Redundancy | Not practical at this budget | Included |
| Total | $2,200-4,400/month | $49/month |
At low volumes, self-hosting is economically irrational. The DevOps overhead alone is 45-90x the managed provider cost.
Medium Volume: 150 Million Requests/Month
| Cost Category | Self-Hosted | Managed (Dwellir) |
|---|---|---|
| Infrastructure (2 nodes) | $450-900/month | $299/month |
| DevOps (prorated) | $4,000-8,000/month | $0 |
| Monitoring/tooling | $100-200/month | Included |
| Redundancy | Included (2 nodes) | Included |
| Total | $4,550-9,100/month | $299/month |
The gap narrows in relative terms as volume increases, but self-hosting remains 15-30x more expensive due to operational costs. With compute-unit providers like Alchemy, 150M requests/month with a typical method mix costs $2,000-5,000/month - cheaper than self-hosting, but significantly more than flat-rate alternatives.
High Volume: 500 Million Requests/Month
| Cost Category | Self-Hosted | Managed (Dwellir) |
|---|---|---|
| Infrastructure (3+ nodes, multi-region) | $2,000-5,000/month | $999/month |
| DevOps (dedicated) | $12,000-17,000/month | $0 |
| Monitoring/tooling | $200-500/month | Included |
| Total | $14,200-22,500/month | $999/month |
At high volume, per-request costs from managed providers become highly competitive. Dwellir's Scale plan works out to $1.96 per million requests. A comparable setup with Alchemy costs roughly $5,076/month, and QuickNode roughly $2,789/month, depending on method mix and multipliers.
Extreme Volume: Billions of Requests/Month
At the billions-of-requests scale, dedicated managed clusters become the relevant comparison:
| Cost Category | Self-Hosted | Managed Dedicated (Dwellir) |
|---|---|---|
| Infrastructure | $5,000-15,000/month | From $875/month per cluster |
| DevOps | $12,000-17,000/month | $0 |
| Total | $17,000-32,000/month | Custom pricing |
At extreme volumes, economics depend heavily on specific requirements. Dedicated clusters from providers like Dwellir start at $875/month and scale based on chain, redundancy, and throughput needs. Self-hosting becomes competitive at this scale only if you already have a dedicated infrastructure team and deep operational expertise on a single chain.
When Self-Hosting Makes Sense
The cost analysis favors managed providers in most scenarios, but self-hosting is the right choice in specific situations:
Regulatory and data sovereignty requirements. Some jurisdictions require that blockchain data processing occurs within specific geographic boundaries. If your compliance framework mandates that no third party touches your RPC traffic, self-hosting may be the only option.
MEV operations requiring sub-30ms latency. Competitive MEV extraction demands co-located infrastructure with single-digit millisecond latency to validators. Some managed providers offer co-location, but the most latency-sensitive operations benefit from fully controlled infrastructure.
Custom node configurations. If you need modified client software, non-standard RPC methods, or experimental features like custom debug_traceTransaction tracers, self-hosting gives you complete control over the node configuration.
Extreme single-chain throughput. When your request volume on a single chain reaches billions per month, the economics of dedicated hardware can shift in favor of self-hosting. This only holds if you already have the DevOps expertise.
Deep expertise in a single chain. If your team has specialized knowledge in operating a specific chain's infrastructure (common in validator operations), the marginal cost of adding RPC service to existing nodes is low.
When Managed Providers Make Sense
For the majority of teams, managed providers are the stronger choice:
Speed to market. Your first RPC call happens in minutes, not days. No sync time, no hardware provisioning, no client configuration. For startups racing to launch, this matters.
Multi-chain requirements. Supporting 5+ chains with self-hosted infrastructure means 5 separate node deployments, each with unique hardware requirements, client software, and upgrade schedules. A managed provider like Dwellir provides access to 150+ chains under a single API key.
Teams without blockchain infrastructure expertise. Blockchain node operations are a specialized skill. If your team's strengths are in application development, smart contracts, or product design, the learning curve and ongoing burden of node operations create a real opportunity cost.
Unpredictable or spiky traffic. Applications with variable request volumes (seasonal DeFi activity, NFT mint events, gaming launches) benefit from pay-per-request models that scale automatically. Self-hosted infrastructure must be provisioned for peak capacity and sits idle during low-traffic periods.
99.99% uptime without redundancy investment. Achieving four-nines uptime with self-hosted infrastructure requires 3+ nodes across regions, automated failover, and 24/7 on-call rotation. Managed providers deliver this as a standard feature of their architecture.
The Hybrid Approach
The choice is not binary. Many production teams combine self-hosted and managed infrastructure to capture the benefits of both.
Pattern 1: Managed Primary, Self-Hosted for Sensitive Operations
Use a managed provider for general RPC traffic and route sensitive operations (large transactions, proprietary trading logic) through self-hosted nodes. This limits the data exposure to third parties while keeping operational burden low for routine traffic.
Pattern 2: Self-Hosted Primary, Managed Failover
Run your own nodes as primary infrastructure but configure a managed provider as automatic failover. When your node goes down for maintenance, upgrades, or unexpected issues, traffic routes to the managed endpoint seamlessly. You get self-hosting control with managed-provider reliability as a safety net.
Pattern 3: Managed for Development, Dedicated for Production
Use shared managed endpoints during development and testing, where cost sensitivity is high and uptime requirements are low. Deploy to dedicated managed clusters or self-hosted infrastructure for production. This accelerates development velocity without compromising production quality.
Pattern 4: Fast-Path / Heavy-Path Split
Route latency-sensitive operations (transaction submission, mempool monitoring) through co-located self-hosted nodes and route heavy but latency-tolerant operations (historical queries, analytics, indexing) through managed providers with flat-rate pricing.
Common Self-Hosting Mistakes
Teams that self-host frequently hit the same problems. Avoiding these saves weeks of troubleshooting and thousands of dollars in wasted infrastructure.
1. Undersizing storage without accounting for growth. A 2 TB drive fits an Ethereum full node today but fills in months at 14 GB/week of state growth. BSC at 110 GB/day fills a 4 TB drive in just over a month. Provision 2-3x your current requirement and plan for expansion.
2. Using consumer-grade SSDs. Consumer QLC (quad-level cell) SSDs fail within 12-24 months under the sustained write loads blockchain nodes generate. Enterprise NVMe drives with high TBW (terabytes written) ratings are essential. The cost difference is small compared to data loss and a full re-sync.
3. Running without monitoring. A node can fall behind the chain tip and serve stale data without any visible error. Without Prometheus, Grafana, or equivalent tooling, you only discover the problem when users report it. Silent lag is the most common failure mode.
4. Single-node production deployments. Any maintenance, update, or hardware issue takes your only node offline. Production deployments need at minimum 2 nodes with automated failover. The cost doubles, but the alternative is accepting periodic downtime.
5. Ignoring client updates. Missing a hard fork means your node follows a dead chain. Applications read incorrect state, transactions fail, and data integrity is compromised. Subscribe to client release channels and test updates promptly.
6. Treating storage as a one-time purchase. Ethereum's state grows steadily, BSC's aggressively. Budget for storage expansion as a routine operational task, not an emergency response when your drive hits 95%.
7. Running Solana on cloud VMs. Solana's 512 GB RAM requirement and 10 Gbps network needs make cloud VMs prohibitively expensive. Bare metal at $1,200-2,800/month is the only realistic option. Cloud instances meeting Solana's requirements cost $5,000+/month.
8. Forgetting L1 dependencies for L2 nodes. Arbitrum, Optimism, and Base nodes require L1 Ethereum RPC access to verify state. Self-hosting an L2 without planning for this means either an additional self-hosted Ethereum node or a managed provider subscription. Neither appears in naive cost estimates.
9. No documented runbooks. When your on-call engineer gets paged at 3am because a node is out of sync, they need clear procedures: how to check status, when to restart, when to re-sync, and how to fail over. Without runbooks, incident response is slow and error-prone.
Industry Context
The Node-as-a-Service (NaaS) market reached an estimated $135 million in 2024 and is projected to grow to $318 million by 2032. This growth reflects a clear trend: teams are choosing managed infrastructure over self-hosting.
Recent incidents highlight the risks on both sides of that choice:
- AWS October 2025 outage: Took down Coinbase, Robinhood, Infura, Base, and parts of the Solana ecosystem simultaneously, demonstrating the concentration risk of cloud-dependent providers.
- Infura 2022 geoblocking: Accidentally blocked Venezuelan users, highlighting the sovereignty risk of centralized providers.
- Arbitrum December 2023: A 78-minute outage caused by an inscription surge overwhelmed many self-hosted nodes that lacked sufficient resources.
These incidents reinforce a key principle: no infrastructure model eliminates all risk. The goal is to understand and mitigate the specific risks relevant to your situation.
Conclusion
For most teams, the decision is clearer than it appears.
Self-hosting makes sense when you need complete control over node configuration, must comply with data sovereignty regulations, operate at extreme single-chain volumes, or run latency-sensitive MEV operations. The cost floor is $2,200/month for a single unredundant node and scales quickly to $15,000-24,000/month for production-grade multi-node deployments.
Managed providers make sense for everything else, which covers the vast majority of teams. Multi-chain support, instant setup, built-in redundancy, and zero operational overhead make managed infrastructure the economically rational choice for teams making up to hundreds of millions of requests per month.
Hybrid approaches combine self-hosted control with managed reliability when your requirements do not fit neatly into either category.
Three practical next steps:
- Calculate your actual TCO. Use the tables in this guide to estimate both self-hosted and managed costs for your specific situation. Include DevOps time.
- Start managed, self-host later if needed. Migration to self-hosted infrastructure is always possible once you understand your traffic patterns. Starting managed lets your team ship product while you evaluate long-term infrastructure needs.
- Evaluate pricing models carefully. The difference between compute-unit pricing and flat-rate pricing can be 3-5x at scale. Prioritize providers with transparent, predictable billing.
Dwellir provides RPC endpoints across 150+ networks with transparent 1:1 pricing - every method costs 1 credit, including trace, debug, and archive queries. No compute unit multipliers, no hidden formulas.
- Get started: Create your free account (100,000 requests/day)
- Compare plans: View pricing from $49/month for 25M credits
- Need dedicated infrastructure?: Contact the Dwellir team to discuss dedicated clusters starting at $875/month
- Related reading: The Hidden Costs of Archive Nodes | RPC Providers Without Compute Units