Hedera Release Cycle Overview
Hedera Team
By Ed Marquez
Introduction
The Hedera technology stack consists of multiple open-source components, including the underlying hashgraph consensus algorithm, consensus node, mirror node, various SDKs, and more. All these are now developed under the Hiero project within a Linux Foundation governance structure. For the Hedera network, the Hedera Council remains the primary network operator, deploying monthly releases to previewnet, testnet, and mainnet, so developers can anticipate updates and test upcoming features in a predictable, transparent way.
Keeping up with the updates happening in the Hedera network is crucial for developers building on the platform. New features and improvements in the Hiero Consensus Node codebase follow a structured release cycle. Understanding this cycle and the three network environments (previewnet, testnet, and mainnet) will help you follow when and where new features become available. This article explains how the consensus node codebase evolves over time, the purpose of each environment, and what Hedera’s move to open-source development (via Project Hiero) means for this process.
Previewnet, Testnet, and Mainnet
Hedera has three public network environments, with each serving a different role in the release process and developer ecosystem.
Mainnet is the production Hedera network where real-value transactions occur. Mainnet runs the stable, fully tested code and is governed by the Hedera Council (global organizations that run the mainnet nodes). This is where end-users and applications interact with Hedera in production. As a developer, you deploy to mainnet when you are confident in your application. Mainnet uses real HBAR and is optimized for security and stability.
Testnet is a stable pre-production environment for developers. The Hedera testnet runs with free test HBAR and no real value at risk. It’s designed for you to test your applications against an upcoming mainnet release in a safe setting. Importantly, testnet is updated before mainnet (usually at least two weeks in advance) so that developers can verify that their apps still work with the new changes prior to those changes going live on mainnet. So, if a new version of the consensus node software is about to hit mainnet, it will land on testnet first, giving the developer community a chance to catch any issues or adjust usage.
Previewnet is an early-access preview network running a development version of the consensus node codebase. Previewnet gives the Hedera developer community a first look at upcoming features before they are finalized for release. It often runs the latest (unstable) code that the contributing teams are working on. Because of this, previewnet may not always be stable and it can experience more frequent resets.
All three networks are open for anyone to use. You can create accounts on testnet or previewnet for free (via the Hedera Developer Portal) and start building or testing with little to no risk. Each environment has a public mirror node, network explorer, and JSON RPC Relay–with each of these components having its own release cycle.
Although all environments use similar transaction throttles and configurations as mainnet to ensure a realistic testing experience, the number of nodes is different for the test networks. At the time of this writing, the Hedera mainnet nodes (available in the address book) include the 31 consensus nodes operated by the council. Testnet and previewnet each have 6 consensus nodes.
Together, these network environments and components enable a phased rollout of new Hedera features.
The Release Cycle for Consensus Node
The council approves the versions of the Hiero Consensus Node codebase that are deployed on the Hedera network. This codebase is the software that provides functionalities like the Consensus Service, Token Service, Smart Contracts, etc. Versions are numbered (for example, v0.45, v0.46, and beyond) and a new version is released every month. Each version upgrade progresses through the Hedera environments in order:
Development & Previewnet: Contributors develop new features and improvements in the codebase. When a set of changes is ready and passes testing, a new version is cut as a preview release. This is first deployed to previewnet, which always runs the latest development build of the code). For example, if version 0.60 is in development, previewnet will be updated to 0.60.0 as soon as those changes are available. This gives the community early exposure, where they can try new APIs or features even before they are considered “stable.”
Testnet Release: At this stage, the version is considered a stable release candidate. Hedera will schedule an upgrade of the public testnet to that version. Following our example, once v0.60 has been on previewnet, the Hedera testnet will be upgraded from the previous version (say v0.59) to v0.60.x. This step is announced publicly (via the Hedera Status page and forums like X and Discord) ahead of time so developers know an update is coming. Developers can also use the Hedera Status API to programmatically retrieve information about scheduled maintenance and even create logic to manage their applications during maintenance windows. When testnet is upgraded, it runs the same code that is intended for mainnet soon after. The pre-release period on testnet reinforces the commitment of contributors to quality assurance and community testing.
Mainnet Upgrade (Production): Once a version has run on testnet for some time (typically two weeks) and no show-stopping issues remain, it is ready for mainnet deployment. Hedera coordinates with the council members (who operate the mainnet nodes globally) to schedule a mainnet network upgrade at a specified date and time; this upgrade is performed by way of an on-chain transaction signed by a majority of council members (e.g. transaction for v0.59.5 upgrade on March 26, 2025). At that time, all mainnet nodes update to the new version in a process focused on maintaining network security and stability while minimizing the duration of the maintenance window. This is the culmination of the release cycle and by the time a version reaches mainnet, it has effectively been running on previewnet and testnet for at least one month.
- Emergency Fixes: An emergency process is followed for critical issues found through mechanisms like security audits, the Hedera bug bounty program, or testing that would have detrimental impacts on network users. In these cases, the Hedera mainnet is updated first before testnet and previewnet to resolve the critical issues as soon as possible. Following the emergency fix on mainnet, the version is then updated to previewnet and testnet. In circumstances involving critical security updates, advanced notice cannot be made public before the issues are fixed for obvious security reasons. This is a common and best practice in the blockchain space.
This previewnet to testnet to mainnet sequence repeats for each release version. In practice, there’s a pipeline of releases. While one version is in testnet/mainnet deployment, the next version might already be on previewnet. The release process Hedera follows is a continuous cycle, with monthly cadence, that delivers new functionality in a safe, phased manner. Throughout this release process, Hedera maintains transparency about upcoming upgrades. You can subscribe to these updates via email on the status page and follow official Hedera channels to get notified. This way, you’ll know ahead of time which version is coming to mainnet and when, allowing you to prepare your applications accordingly.
Open-Source Development and Project Hiero
In late 2024, Hedera took a major step to reinforce its commitment to transparency and open development by contributing its entire codebase, including consensus node code, SDKs, and many other parts of the technology stack to the Linux Foundation under a new project called Hiero. This means that the consensus node codebase (and even the Hashgraph consensus algorithm itself) is developed in the open, in a vendor-neutral environment. Anyone can view the code on GitHub (under the hiero-ledger organization), propose changes, contribute code via pull requests, and join Hiero community calls. Hedera became the first Layer 1 DLT to donate its code to an independent foundation, fully embracing a vendor-neutral governance model.
The Hiero project has a Technical Steering Committee (TSC) that oversees the technical direction and quality of the codebase, composed of Hedera core contributors and community members. The TSC operates openly (meetings are public and recorded) and ensures that contributions from various parties are reviewed and integrated according to merit. Importantly, the Hiero Improvement Proposal (HIP) process continues to function in the open source era. This structure allows for transparent feature development in the Hedera ecosystem where previewnet releases show what’s coming, and testnet provides a stable, final check before mainnet.
The Hedera monthly release cadence, environment configurations, and operational choices are with the Hedera Council, while the codebase and contributions are managed collaboratively under Hiero. The Hedera network itself remains uniquely governed by the council, which decides what, how, and when to deploy the open-source code to mainnet (including parameters such as fees). This means that, in the future, it’s possible to see Hiero features that are never enabled on Hedera mainnet. The Hedera release notes will indicate which features are included in a new release for the public network.
Following Releases and Staying Involved
To stay up-to-date with the release cycle, developers should regularly check the Hedera Status page and release notes. Community involvement is encouraged: track or propose HIPs in the Hiero GitHub, or join the Hedera Discord for ongoing discussions. Because the network code is open source and publicly visible, you can watch pull requests, review architecture docs, and even contribute bug fixes or new features.
Closing Thoughts
The Hedera release cycle is designed to deliver innovation steadily and safely. By flowing changes through previewnet and testnet before mainnet, Hedera ensures high quality and gives developers and users confidence in each upgrade. The clear separation of environments means you always have somewhere to try new things (previewnet), a place to double-check your app in a stable setting (testnet), and a mainnet that remains robust and reliable. Coupled with the transition to open-source development via Hiero, the entire process is becoming even more transparent and community-centric.
As a developer, you can align your development cycle with that of Hedera: keep an eye on upcoming releases, test early and verify on testnet, and confidently deploy to mainnet. Be sure to follow the release notes and network announcements to stay up-to-date with the latest upgrades.
New features and improvements are constantly in the works, and now you know exactly where to find them first, and when they’ll arrive on mainnet. Stay tuned, stay involved, and happy building on Hedera.
Links
GitHub Repositories
Hedera Resources
Network Monitoring & Status
Community & Social
Linux Foundation / Hiero Participation
Subscribe to my newsletter
Read articles from Hedera Team directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by