Best Practices
This section covers how to prepare and maintain a well-performing Algorand node through different best practices and specific guidelines, including hardware selection, reliable OS, and robust networking. It also provides guidance on keeping participation keys secure, managing nodes in different scenarios like maintenance, and avoiding performance degradation. Additionally, various “don’ts” are outlined. Adhering to these best practices helps ensure consistent node performance, protects the node’s online accounts, and supports overall network stability.
Preparing Your Machine
To get ready to set up an Algorand participation node, there are a few prerequisites to get sorted. This section covers preparing your machine with the foundation on which the node will be run. Running archival and relay nodes requires additional configuration and considerations that are not covered in this guide.
Hardware
Computer or Server
The first thing that is required to run a node is a computer with sufficient performance capabilities.
It is strongly recommended to use a machine that is dedicated to running a node and has no other significant processes running on it that would compete for CPU, memory, or disk access performance.
A collection of cloud VPS recommendations has been compiled by a community member here.
Power Backup System
Power interruptions can knock a node offline and degrade your consensus performance. It is recommended to have the node, as well as any networking equipment on which its internet connection relies, to have an uninterruptible power supply (UPS) to handle transient power cuts. Longer power outages may require backup power sources.
Operating System
A node can be installed on a number of different operating systems, including multiple Linux distributions, MacOS, and even Windows, although it may be necessary to use third-party solutions in some cases. For Linux operating systems, Debian, Ubuntu, Linux Mint, Red Hat (Fedora, CentOS), and others can be a base for installing a node. MacOS can also be used to run a node For Windows, Algorand Technologies does not provide compiled binaries so it is necessary to utilize a third-party solution to install a node on such a system
Connectivity
Reliable internet connection: A node is run like a server in that it should be operational nearly all the time, so it is crucial to have a reliable broadband connection to the internet. Backup connectivity: A rented server or virtual private server situated in a commercial-grade data center may already have redundant internet connections, but home-based node runners may want to explore backup internet service. Some internet service providers offer packages that include 4G/5G wireless service as a backup if the primary wired connection goes down. It is also possible to build such a system DIY with prosumer/commercial-grade internet gateways.
Guidelines for a Healthy Network
Ensure that Online Accounts are Participating
If an account registers itself online, it is important that its participation key is online. A participation key is online if there is a single fully-synchronized node on the Algorand network that has that key in its ledger directory. You should always mark an account offline if it is not actually available to participate, since the network uses the online/offline status of an account to calculate block vote thresholds. If you are marked online but you are not participating, you would be considered a dishonest user and will negatively impact the voting threshold. Furthermore, if your node experiences issues you are not able to solve promptly, it is recommended that you register the account offline as soon as possible.
Renew Participation Keys Before They Expire
Participation keys are valid for a specific round range. Make sure to renew participation keys or mark the account offline before the current participation key expires. Your account will not automatically be marked offline.
Visit the Renew Participation Keys section for detailed instructions.
Ensure that Participation Nodes are Working Properly
Monitor your participation node to ensure high performance and consistent access to your registered participation key. The following should be monitored:
- Last committed block (goal node status or API) matches a third-party API service
- CPU / RAM / disk use are within thresholds
- Clock is accurate (blocks are timestamped using the clock time from the block proposer’s node, so keep your node clock accurate and on time)
- The participation node is sending votes and proposing blocks at the expected frequency.
Securely Store Participation Keys
Registered participation keys that are in operation are regularly updated through the protocol so that they cannot be used to vote on earlier rounds. Essentially, the set of keys corresponding to earlier rounds are deleted after the round passes to ensure that the compromise of a participation key by a bad actor does not give the bad actor the potential to rewrite history. Because of this, it is important that there only exists a single instance of the participation key (files ending in *.partkey) at any time in the system.
Ongoing Maintenance
Running a node that performs well over time requires periodic maintenance around participation keys and the node software.
Going Offline Gracefully
Register participation keys offline, then wait 320 rounds before interrupting the node. There will be times when you may need to perform maintenance on the node or know you will unable to intervene should issues arise. It is fine to register your participation keys as offline, and this will maintain your incentives eligibility status and avoid harming the network if your keys are set to online but the node isn’t voting or proposing blocks. If you go offline gracefully this way, you can register the keys online again without having to pay the elevated fee again for incentives eligibility.
Re-Enrolling In Staking Rewards
Have an Algo buffer on hand for key registration fees. If your account is eligible for staking rewards, it will be challenged by the protocol from time to time to ensure it is participating as often as expected. If your node fails a heartbeat challenge, it will lose eligibility for staking rewards and once again need to issue a key registration transaction with an elevated 2A fee to re-enroll in rewards. If you have made any account balance commitments to programs like Governance, make sure that you commit somewhat less than your total balance so that paying such a fee does not invalidate your commitment. It is good practice to keep 10A on hand to cover keyReg fees that may be needed periodically.
Optional Tooling
Telemetry
The node software has the capability to publish telemetry about performance and usage, and node runners are encouraged to configure this to help provide insights into how the network is performing. Refer to the following guide for how to enable telemetry on your node:
A complete reference for telemetry configuration options can be found here:
Monitoring
It is recommended to monitor your node’s performance and health to ensure it is running optimally.
There are a number of tools available to help you do this by leveraging the node’s built-in metrics
endpoint to which a Prometheus server can be connected to retrieve metrics. The endpoint can be
configured in config.json by setting the NodeExporterListenAddress.
Things Not To Do
In addition to following the instructions for installing and maintaining and Algorand node, there are a number of things you should not do when managing a node.
Node Running Don’ts
Dont run multiple instances on the same machine
Running more than one instance of algod for the same network on the same machine provides no
advantage. For development purposes, you may want to have algod running for multiple different
networks. For participating in consensus on MainNet, however, there is no advantage to running
multiple algod processes and it will likely cause setup and configuration conflicts. Unlike some
cryptocurrencies that can be mined and which may benefit from additional computing power, Algorand’s
proof-of-stake consensus algorithm does not benefit from running additional node processes unless
you have a large number of accounts participating in consensus.
Dont add many accounts to a single participation node
Adding more than a few accounts’ worth of participation keys on the same physical node could cause your node to fall behind in participating. For each round, the node needs to work through all online accounts for which it has participation keys to cast votes and produce blocks. Having too many accounts on one node will increase the risk of your node not completing its block proposal in time and missing the round cutoff, rendering the block proposal wasted. This will cause the accounts to miss opportunities to earn rewards and generally hamper the network’s ability to reach block consensus.
Don’t run an under-provisioned node
Running a participation node on a machine with less than 16GB of RAM without configuring GOMEMLIMIT
to explicitly cap memory usage could cause crashes. Without this limit in place, a node running on
only 4GB or 8GB of RAM may encounter an out-of-memory error under high chain throughput. This
behavior was observed during multiple high-TPS load tests in 2024. If you must run a node on a
machine with less than 16GB of RAM, set GOMEMLIMIT to a value that is somewhat less than the total
amount of RAM on the machine. This will prevent algod from using all available memory and crashing
the node.
Don’t run a node without dedicated resources
It is unwise to a node on a machine that is not dedicated to the task, such as a computer that is handling other processes or end-user applications. With sufficient hardware, appropriate performance monitoring, and alerting, this may be safe to do, but your node needs be able to handle unexpected load spikes without competing for resources with other processes.
Don’t shut down your node immediately after going offline
If you need to take your node offline for any reason, don’t turn off your node until 320 rounds have elapsed after registering participating accounts as offline. Changes to consensus participation take effect in the protocol on a 320-round delayed basis. If a node needs to be shut down for maintenance, plan accordingly for this waiting period.
Don’t enable unfamiliar experimental settings
It is risky to enable experimental settings on a participating node without understanding the mechanisms involved and being prepared to carefully monitor the node. Experimental features could cause performance problems for your node, causing it to miss opportunities to earn block rewards, and harm the network.
Don’t expose an insecure node to the internet
A self-managed node should not be exposed to the open internet without implementing appropriate security measures on the machine and network. Nodes should be protected from potential attacks, such as traditional denial-of-service attacks and other attack vectors. For those running nodes with their own hardware, ensure that modern cyber security precautions are in place. Those running nodes on cloud-based machines should familiarize themselves with their virtual private server vendor’s protocols, which may include surprising actions in the event of a cyber attack.
Consensus Participation Don’ts
Don’t participate on two nodes simultaneously
It is self-defeating to run two nodes with participation keys for the same account at the same time. If the protocol detects that same account is participating more than once in the consensus process, it will throw out proposals and votes and penalize that account. Running redundant nodes for the same account is not an effective way to increase the operational resilience of consensus participation.
Don’t send heartbeat transactions
Heartbeat transactions are intended to be sent by a node, itself, to signal that it is operating properly. Sending a heartbeat through other methods on behalf of a node is effectively lying to the protocol that a node is online. Sending heartbeats to avoid an account being suspended for absenteeism in consensus and keeping that stake marked as online harms the consensus protocol’s ability to reach agreement on blocks.
Don’t provide incentives to lie about being online
When designing applications, such as DeFi protocols, you should never provide economic incentives for accounts to lie about being online in consensus. The only behavior that should be incentivized is actually producing blocks, not sending heartbeat transactions or keeping an account marked as online. Offering rewards for accounts that are marked as online but not actually participating in consensus would be harmful to the network and an exploit vector for your rewards mechanism.
Don’t overpay fees on key registration transactions
When registering an account online in consensus, it is necessary to pay a higher-than-normal 2 Algo fee to have the account marked as eligible for staking rewards. However, once the account is marked eligible for rewards, it is possible to go offline and back online again without needing to pay the elevated fee again. Going offline properly does not reset an account’s reward eligibility, so going back online or renewing participating keys does not require the elevated fee to be paid again.