Solana Devnet vs Mainnet vs Testnet: Which Cluster for What

There are three public clusters in Solana: Mainnet Beta, Devnet, and Testnet. Mainnet Beta is a production network with live SOLs, Devnet provides a way to test applications for free with freely airdropped SOL, but without any financial risk, while Testnet is supposed to be used by core developers and validators to test the next release of the network itself, and it is intentionally unstable and is not intended for application testing. Develop on Devnet, deploy to Mainnet and avoid deploying to Testnet except for validator software testing. This article is devoted to a thorough description of each cluster, how to direct your wallet and code to a cluster, practical differences between them and common mistakes made because of confusion with their usage.

The three clusters

"Beta" in the name of Mainnet is historical, as it supports real value for years and works as a production network.

Devnet: a development platform

Devnet uses the same validator software as Mainnet (sometimes even a newer version), runs identical programs and exposes the same RPC API, which means that the code can easily be switched from Devnet to Mainnet by changing an URL. You can get SOL from the faucet (there are some limitations on rate; do not request too much), deploy programs and verify end-to-end flows with zero financial risks.

There are two caveats with Devnet: firstly, it can be reset, destroying all deployed programs and accounts; keep scripts of deployments to be able to redeploy programs. Secondly, it is quiet: there is no congestion, no competition for the block space and no saturation of transaction forwarding. It verifies the correctness of the logic but does not give any information about landing rate, priority fees and latency under load.

OrbitFlare provides Devnet and Mainnet URLs per account; every OrbitFlare plan, even free, includes Devnet.

Mainnet Beta: the home of the value

Devoted to real SOL, real users and real competition for block space. All validations on Devnet, although helpful, are not enough here: network congestion appears during important events, leaders prioritize staked connections and priority fees are real market. The low-latency infrastructure guide covers specifics of this environment.

Testing on Mainnet before launching should be done in small scales: just replicate the same transaction flow, spend real fees and measure landing rate in peak periods.

Testnet: generally not suitable for applications

Testnet is used for validators to be able to run release candidates and for core teams to test network changes under load. It is updated frequently, may fork or be reset and tooling is oriented towards node operators. Application developers testing their programs on Testnet face instability without any benefits. In case if some tutorial tells you to use Testnet for your dApp, this tutorial is probably outdated; use Devnet instead.

In case if you are going to operate a validator on Mainnet, you can run one on Testnet as a proving ground.

Pointing wallets and code to a cluster

Wallets: most wallets have a network switcher (Mainnet, Devnet, Testnet) in settings and a separate RPC field per network. Switch to Devnet to verify the application running on a Devnet deployment; return to Mainnet before handling real funds.

Code: cluster is defined by an RPC URL. Keep one URL per environment in configuration (for example, SOLANA_RPC_URL for production environment with a connection to Mainnet and a separate variable for development environment with a connection to Devnet), do not derive one from another at runtime. Local test validator (solana-test-validator) is the fourth way to test your code: a private cluster on a local computer, instant and free, without any network involvement.

Program addresses are different in different clusters for your own programs (each program is deployed separately per cluster), but core programs (token program, system program, associated token program) have the same addresses. Well-known third-party programs are usually deployed both on Devnet and Mainnet at identical addresses, but still better to verify.

Practical differences

The main difference is that Devnet verifies the correctness of the logic and Mainnet verifies the performance and economics. Bots, in particular, may work perfectly on Devnet and become unprofitable or unable to land on Mainnet, which explains the emphasis on Mainnet testing in the sniper bot guide with small transaction volumes.

Common mistakes

• Incorrect URL in production. A release targeted to Devnet looks working but actually performs no real operations. Separate configurations and startup check of genesis hash will help to overcome this problem.
• Testing landing on Devnet. Transactions always land on Devnet, so measure on Mainnet.
• Expecting that a certain program exists on Devnet. Some Mainnet programs are not deployed on Devnet or are deployed at different addresses; better to verify this.
• Relying on Devnet state. Resets destroy it; keep scripts of redeployments and seed data.
• Using Testnet for dApps. Its instability does not provide any benefits.

Conclusion

Devnet is for development, Mainnet is for production and Testnet is for network-level testing. Keep separate cluster URLs per environment, verify the genesis hash at startup, verify your logic on Devnet and performance on Mainnet with small-scale tests and understand that landing, fees or latency characteristics cannot be verified on a quiet cluster.

OrbitFlare provides Devnet and Mainnet URLs through a free account; RPC plans cover the Mainnet path in case of deployment under load.