How to run a Nano node: hardware, ports, Docker setup and syncing

A Nano node is software on your own machine. It keeps a copy of the ledger, talks to other nodes and, if you switch it on, votes. Start with a plain non-voting node on Docker. It is the setup recommended for integrations, and nothing else on this page matters until it is synced.

What a node does

Running a node helps decentralize the network and gives systems built on Nano an access point. A node verifies payments for you and gives your app or business its own trusted connection to the network. It can also vote as a representative when accounts choose it.

Every node follows the same life cycle:

1. On startup it discovers other nodes through the peering process and connects to hundreds of them.
2. It bootstraps the ledger from peers by requesting chains of blocks, from the genesis block up to recent ones.
3. It then asks representatives for votes, and a block with enough voting weight is confirmed and unchangeable.
4. Once the ledger is synced and stays synced, the node can fully participate.

Each node decides for itself whether to add a valid transaction to its ledger. The node confirms a block when it sees more than 67% of online vote weight by default. See open representative voting for how that vote works.

Choose a node type

A new node does not vote. This non-voting type is common and recommended for all integrations. If your goal is to learn how to use Nano for payments, it is the best starting point.

Editor's takeStart with a non-voting node. Voting is off by default and a representative node should be dedicated to consensus, so treat it as a second project, not step one. Nobody pays you either way.

A representative node has a representative account, is configured to vote and holds less than 0.1% of online voting weight. At 0.1% or more, other nodes rebroadcast its votes. Voting is off by default and must be enabled by hand. A node set up as a representative should be dedicated to consensus. A node that serves heavy RPC or work generation should not also vote.

Nobody pays you for any of this. By design, node incentives are external, which is what allows Nano to run securely without transaction fees. Running a node earns no fees or rewards.

Hardware and bandwidth

Nodes consume CPU, RAM, disk IO and bandwidth, all of which cost money. Minimum recommended specifications:

The project’s site repeats the standard figures: 8 GB RAM, 4 cores, 400 GB+ SSD, 250 Mbps and about 4 TB a month. Actual use varies with how often you make RPC calls and what else runs on the machine. The software runs on Linux, macOS and Windows.

Set up the node with Docker

The simplest setup is a machine with the right TCP port open to the internet, running a build published by the Nano Foundation. Docker is recommended for most setups because of easier upgrades and maintenance. Do not run the Linux container on a Windows host, because known port-handling problems block communication with peers.

Open the ports

Only TCP is needed on port 7075 since V21, and UDP has been removed from the node. Anyone with access to the RPC port can control your node’s RPC.

Start it

1. Install Docker, then pull the image for the version you want with docker pull.
2. Start the container with docker run. The -p 7075:7075 flag maps the bootstrapping TCP port, and -d starts it as a daemon.
3. Point the volume at a host directory, where the ledger, configuration files and logs are stored.
4. Check the log files in that directory after startup.
5. Query the node over RPC once it is running.

The commands, with the V28.2 image tag:

docker pull nanocurrency/nano:V28.2
docker run --restart=unless-stopped -d \
  -p 7075:7075 \
  -p 127.0.0.1:7076:7076 \
  -p 127.0.0.1:7078:7078 \
  -v /srv/nano:/root \
  --name nano_node \
  nanocurrency/nano:V28.2

The -v flag maps the host’s Nano directory to /root in the container, so /srv/nano here holds config-node.toml, config-rpc.toml and the ledger. Binding 7076 to 127.0.0.1 means only RPC commands that originate from the host are accepted, which keeps your node’s RPC away from the internet. Binding 7078 the same way keeps the WebSocket server host-only. If you want different ports, change the host side of each -p flag, not the ports in the config file.

To vote, open config-node.toml in that directory, enable voting, restart the container and delegate weight to the representative account (see below):

[node]
enable_voting = true

Newly set up nodes have voting disabled by default, and the option must be updated in config-node.toml to take part in consensus.

V28.2 is the release marked Latest on the GitHub releases page, which we checked on 2026-10-21. It was published on 15 September 2025, so the project has shipped nothing newer in over a year; use the tag for the release you want, and read the release notes before you upgrade. The V28.2 notes also say the older database toml keys are being replaced by database_backend = “lmdb” or “rocksdb” under [node].

If you run more than one container, never share the host directory, because each node needs its own files. Config file changes have no effect until you restart the container. Voting stays disabled until you enable it.

The ledger is a single data.ldb file in the data directory. The default database is LMDB, and RocksDB can also be configured.

How big is the ledger, and can you prune it?

No current ledger size is published, so treat any single figure with care. The last dated figure is from September 2020: over 56 million blocks, needing at least 29GB of free space. The hardware table above asks for 400GB+ of free space because the ledger keeps growing and an upgrade can need extra room: a ledger upgrade can use up to 3x the current ledger size temporarily, for example 60GB for a 20GB ledger. To see where your own node stands, compare block_count with the disk the data directory uses.

On LMDB the ledger file does not shrink without a manual vacuum. Pruning is the other way to cut it: the V28.2 release notes call pruning experimental, say it is not currently recommended for important production services, and list a known crash when you bootstrap from scratch with pruning enabled. If you want it anyway, bootstrap first, then enable pruning.

Check that it is synced

Wait for the node to sync before you set up a representative or send and receive from a wallet it uses. Until the ledger is built out, the node may return partial data.

Use the block_count RPC. Its count is the total number of blocks in the ledger. The unchecked figure counts blocks downloaded but not yet verified and inserted. The cemented figure counts confirmed blocks. The telemetry RPC is the fastest way to compare your counts against peers.

A new node often shows a full count but a lower cemented count at first, which is normal while it bootstraps and confirms blocks. If it makes no progress for over 24 hours, ask the community on Discord or the forum.

Speed up the first sync

Bootstrapping downloads and verifies blocks from other nodes across the network. It can take hours to days. Avoid restarting the node while it bootstraps, since that adds delays.

To skip it, you can download a ledger file off-network and drop it into the node’s data directory, a process called a fast sync. The Nano Foundation uploads a new ledger file every other day in the #ledger-download channel of its Discord server (docs seen 2026-10-20).

Trust the source before you use one. Scan the ledger for integrity with the –debug_validate_blocks command.

Keep it secure

Open 7075 unrestricted, but keep the RPC port, 7076 by default, available only to those you want to control the node. The enable_control option unlocks dangerous RPC calls, and it is only recommended where RPC access is restricted to local and loopback addresses. The default Docker configuration already allows RPC access only to the machine hosting the container, which is the recommended setup for most nodes.

On the server itself, block unused ports and allow others only from trusted IP addresses. On remote servers use key pairs for SSH instead of passwords, and disable root login. Treat the built-in node wallet as a test tool, because it is for development and testing only. Support for TLS is deprecated from V27, and secure RPC and WebSockets come from a reverse proxy.

Voting and work generation

To vote, enable voting in the node configuration and set up a representative account. The account must have at least 1000 Nano delegated to it before the node will vote. Never use the same seed on multiple running nodes. Network race conditions can degrade performance, and publishing from the same account on two nodes can cause a fork.

Work generation competes with the node for CPU. GPUs are preferred for it, since they are faster and reduce RPC delays. Services with heavy RPC and work needs benefit from a separate machine.

Keep it updated

Plan routine upkeep: OS updates and security patches, upgrades to the latest node versions, and sound handling of passwords and other sensitive data. Without it, any benefit to the network could be lost. A node upgrade can need a ledger upgrade, with downtime from a few minutes to several hours and temporary disk use of up to 3x the ledger size. That upgrade runs slower if the ledger is not on an SSD.

Technical update mailing list

Subscribe to the technical update mailing list, with email updates on the latest protocol and node releases and other technical details, including network upgrades.

Where to go next

The Nodes hub collects node guides as they are published. To understand what your node votes on, read how Nano works and open representative voting. To send a first payment from your node, follow how to send Nano. The primary text is the node overview, the setup guide and the security guide.