A Polkadot node is a software client that connects to the Polkadot network, synchronizes blockchain data, and provides RPC endpoints for querying state, submitting transactions, and interacting with parachains. Running your own node gives you direct, trustless access to the network, but it requires significant hardware, storage, and ongoing maintenance. For many developers and dApps, using a managed RPC service like OnFinality offers a practical alternative with high availability and reduced operational overhead.
This guide covers the different types of Polkadot nodes, how to set up and configure your own node, and when to consider a professional RPC provider for production workloads.
Key takeaways
- Polkadot nodes come in several types: full (pruned), archive, validator, collator, and light nodes, each serving different use cases.
- Running a full node requires at least 4 CPU cores, 16 GB RAM, and several hundred GB of SSD storage; archive nodes need significantly more.
- Setting up a node involves installing the polkadot binary, configuring chain data flags, and syncing the network, which can take days.
- RPC nodes expose endpoints for dApps and wallets but must be secured against unauthorized access and rate-limited to prevent abuse.
- Managed RPC services like OnFinality eliminate the need to run your own node, offering scalable endpoints with built-in redundancy.
- For production dApps, a dedicated node from OnFinality provides guaranteed performance and dedicated resources.
- Choosing between self-hosted and managed infrastructure depends on your team's DevOps capacity, budget, and reliability requirements.
Types of Polkadot Nodes
Polkadot nodes are categorized by their role in the network and the amount of data they store. Understanding these types helps you choose the right infrastructure for your use case.
- Full (pruned) node: Stores recent state and a limited number of finalized blocks. Suitable for most dApps and wallets that only need current state and recent history. Requires less storage and syncs faster.
- Archive node: Maintains complete historical state and all blocks since genesis. Required for block explorers, analytics platforms, and applications that query historical data at any point in time. Storage requirements are significantly higher.
- Validator node: Participates in consensus on the relay chain. Requires a full node with additional configuration for staking and block production.
- Collator node: Produces blocks for parachains. Runs a full node for the relay chain and a collator client for the parachain.
- Light node: Downloads only block headers and requests state proofs from full nodes. Ideal for mobile wallets and low-resource environments.
| Criterion | What to check | Why it matters |
|---|---|---|
| Node Type | Data retention | Determines storage cost and sync time |
| Full (pruned) | Recent state + last ~1000 blocks | Balances storage and functionality |
| Archive | All blocks since genesis | Enables historical queries but requires terabytes of storage |
| Validator | Full node + staking keys | Needed for consensus participation |
| Collator | Full relay node + parachain client | Required for parachain block production |
| Light | Block headers only | Minimal resource usage, trust-assumed |
Get started with free tier Polkadot RPC endpoints or upgrade to a dedicated node for production workloads. Explore Polkadot RPC.
How to Set Up a Polkadot Node
Setting up a Polkadot node involves installing the polkadot binary, configuring it for your desired node type, and syncing the network. Below are the essential steps.
- Prerequisites: Linux or macOS, at least 4 CPU cores, 16 GB RAM, and a fast SSD with 500 GB+ free space (for a full node).
- Install Rust and build the polkadot binary from source, or download a pre-built binary from the official releases.
- Alternatively, use Docker:
docker run -d --name polkadot-node -v /path/to/data:/data parity/polkadot:latest --base-path /data --chain polkadot --pruning archive. - Configure flags:
--pruning(archive or number of blocks),--rpc-external(expose RPC),--ws-external(expose WebSocket). - Sync the node: initial sync can take 24–72 hours depending on hardware and network conditions.
- Secure your node: use a firewall, enable authentication for RPC endpoints, and consider a reverse proxy for TLS termination.
| Criterion | What to check | Why it matters |
|---|---|---|
| Hardware | CPU, RAM, SSD | Directly affects sync speed and reliability |
| Storage | 500 GB+ for full, 2 TB+ for archive | Archive nodes require significantly more disk space |
| Network | Stable internet connection with public IP | Needed for peer discovery and RPC access |
| Security | Firewall, rate limiting, authentication | Prevents unauthorized access and DoS attacks |
Understand the trade-offs between shared and dedicated Polkadot nodes for your project. View Pricing.
RPC Node Configuration Best Practices
If you are running an RPC node for dApps or wallets, proper configuration is critical for security and performance.
- Use
--rpc-cors allcarefully; restrict to specific origins in production. - Enable
--rpc-methods Unsafeonly for development; useSafeor custom methods for production. - Set
--ws-max-connectionsto limit WebSocket connections and prevent resource exhaustion. - Consider using a load balancer in front of multiple RPC nodes for high availability.
- Monitor node health with Prometheus metrics exposed via
--prometheus-external. - Regularly update the polkadot binary to stay in sync with network upgrades.
| Criterion | What to check | Why it matters |
|---|---|---|
| Configuration | rpc-cors | Controls cross-origin requests, security risk if too permissive |
| Configuration | rpc-methods | Unsafe methods can expose node to attacks |
| Configuration | ws-max-connections | Prevents resource exhaustion from too many clients |
| Configuration | prometheus-external | Enables monitoring and alerting |
Read our guide on selecting the right RPC provider for your Web3 application. Read the Guide.
When to Use a Managed RPC Provider
Running your own Polkadot node gives you full control, but it comes with operational costs: hardware, bandwidth, storage, maintenance, and monitoring. For many projects, a managed RPC provider like OnFinality is a more practical choice.
- No DevOps overhead: managed providers handle node setup, upgrades, and monitoring.
- High availability: multiple nodes behind load balancers ensure uptime even if one node fails.
- Scalability: automatically handle traffic spikes without manual intervention.
- Global distribution: endpoints served from multiple regions reduce latency.
- Cost-effective for small to medium projects: shared endpoints are often free or low-cost.
- Dedicated nodes available for projects with high throughput or compliance needs.
| Criterion | What to check | Why it matters |
|---|---|---|
| Factor | Self-hosted | Requires DevOps skills and ongoing maintenance |
| Factor | Managed (OnFinality) | Zero maintenance, built-in redundancy |
| Cost | Self-hosted | Hardware + bandwidth + engineering time |
| Cost | Managed | Predictable subscription, free tier available |
See all supported networks including Polkadot, Kusama, Moonbeam, and more. View Networks.
Choosing Between Self-Hosted and Managed Nodes
The decision depends on your team's resources, reliability requirements, and budget. Here are some guidelines.
- Choose self-hosted if you need full control over node configuration, have dedicated DevOps support, and require custom modifications.
- Choose managed if you want to focus on application development, need guaranteed uptime, or have variable traffic patterns.
- Hybrid approach: run a self-hosted node for development/testing and use a managed provider for production.
- Evaluate total cost of ownership: include hardware, electricity, bandwidth, and engineering time for self-hosted.
- Consider compliance: some regulated applications may require self-hosted infrastructure for data sovereignty.
| Criterion | What to check | Why it matters |
|---|---|---|
| Use Case | Development/Testing | Self-hosted or free managed tier both work |
| Use Case | Production dApp | Managed provider recommended for reliability |
| Use Case | High-frequency trading | Dedicated managed node for low latency |
| Use Case | Block explorer | Archive node needed, managed or self-hosted |
OnFinality's Polkadot Node Services
OnFinality provides both shared and dedicated Polkadot RPC endpoints, as well as dedicated node infrastructure for projects that need guaranteed performance. Our service includes automatic upgrades, monitoring, and 24/7 support.
- Shared endpoints: free tier with rate limits, suitable for development and low-traffic applications.
- Dedicated nodes: reserved resources, no rate limits, ideal for production dApps and high-throughput use cases.
- Multi-region deployment: endpoints served from multiple global locations for low latency.
- Easy integration: simple API key access, compatible with all Polkadot SDK-based chains.
- Network coverage: supports Polkadot, Kusama, Westend, and major parachains like Moonbeam and Astar.
| Criterion | What to check | Why it matters |
|---|---|---|
| Service | Shared RPC | Free, rate-limited, good for testing |
| Service | Dedicated Node | Guaranteed performance, no rate limits |
| Service | Archive Node | Full historical data access |
FAQ
What hardware do I need to run a Polkadot full node?
At minimum, you need a machine with 4 CPU cores, 16 GB RAM, and a fast SSD with at least 500 GB of free space. Archive nodes require 2 TB or more. A stable internet connection with a public IP is also required.
How long does it take to sync a Polkadot node?
Initial sync can take 24 to 72 hours depending on your hardware, network speed, and whether you are syncing a full or archive node. Using a fast SSD and a good internet connection helps reduce sync time.
Can I use a managed RPC provider instead of running my own node?
Yes, managed RPC providers like OnFinality offer Polkadot endpoints that are always up-to-date, highly available, and require no maintenance. This is often the preferred choice for production dApps.
What is the difference between a full node and an archive node?
A full node (pruned) stores only recent state and a limited number of finalized blocks, while an archive node stores all blocks and state since genesis. Archive nodes are needed for historical queries but require much more storage.
How do I secure my Polkadot RPC node?
Use a firewall to restrict access to trusted IPs, enable authentication for RPC endpoints, set appropriate CORS origins, and use rate limiting to prevent abuse. Consider a reverse proxy for TLS termination.
Related resources
Originally published at OnFinality.
Top comments (0)