Polkadot and Substrate-based chains use a different node architecture than Bitcoin/Ethereum-style chains — this guide covers the basics of running a Substrate-based node on a VPS.
Understanding Substrate's Architecture
Substrate is a blockchain development framework, and Polkadot itself (along with many "parachains") is built on it — nodes for Substrate-based chains share common tooling patterns even across different specific chains built on the framework.
VPS Requirements for a Polkadot Node
See VPS Requirements for Running a Blockchain Node for general context — Polkadot specifically has published minimum hardware requirements (typically requiring a reasonably capable multi-core CPU, substantial RAM, and fast NVMe storage) that are more demanding than a basic Bitcoin full node.
Step 1 — Install Required Dependencies
sudo apt install -y git clang curl libssl-dev protobuf-compilerStep 2 — Download the Polkadot Binary
wget https://github.com/paritytech/polkadot-sdk/releases/download/polkadot-v1.9.0/polkadot
chmod +x polkadot
sudo mv polkadot /usr/local/bin/Using a pre-built binary release is generally simpler than compiling from source, which is also possible but considerably more resource and time-intensive.
Step 3 — Run as a Basic Full Node
polkadot --chain polkadot --name "my-node"Step 4 — Run as a systemd Service
[Unit]
Description=Polkadot Node
After=network.target
[Service]
ExecStart=/usr/local/bin/polkadot --chain polkadot --name "my-node"
Restart=always
User=polkadot
[Install]
WantedBy=multi-user.targetMonitoring Sync Progress
curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "system_health", "params":[]}' http://localhost:9933Polkadot nodes expose an RPC interface for querying sync status and general health, similar in concept to How to Monitor Blockchain Node Sync Status and Health but using Substrate's specific RPC methods.
Understanding Different Node Roles
Beyond a basic full node, Substrate-based chains support various specialized roles (validator, collator for parachains, archive nodes retaining full historical state) — each with different resource requirements and setup specifics; verify which role genuinely matches your goal before proceeding with role-specific configuration.
Running an Archive Node (If Full Historical State Is Needed)
polkadot --chain polkadot --pruning archiveRetains complete historical chain state (much larger storage requirement) versus the default pruned mode — only needed for specific use cases genuinely requiring historical state queries (like building a blockchain explorer).
Configuring RPC Access Securely
See How to Secure a Cryptocurrency Node on a VPS for general principles — if exposing RPC access beyond localhost, ensure appropriate authentication/access restriction, since RPC access provides significant node interaction capability.
Following Official Documentation for Chain-Specific Updates
Given the pace of development in the Substrate ecosystem, always consult current official documentation for the specific chain you're running — setup commands, minimum requirements, and best practices evolve meaningfully over time.
Common Errors
Node syncs very slowly or seems stuck — verify your hardware genuinely meets the chain's published minimum requirements (Substrate-based chains are often less forgiving of underpowered hardware than simpler chains), and check disk I/O performance (see How to Optimize Disk I/O for Blockchain Node Performance) as a common bottleneck.
Continue Reading
- VPS Requirements for Running a Blockchain Node
- How to Monitor Blockchain Node Sync Status and Health
- How to Optimize Disk I/O for Blockchain Node Performance
Browse more articles in Cryptocurrency & Blockchain Node Hosting.
