Logo
New RPC users get 35% off their first monthView the offer
RPC Assistant

Solana RPC Providers for Mainnet, Devnet & Testnet

Summary

A practical Solana RPC setup covers more than one endpoint. Mainnet is the production cluster where real SOL and user traffic live. Devnet is the development cluster for testing programs and transactions with free test SOL from the official faucet at https://faucet.solana.com. Testnet is a separate cluster used for validator performance, network upgrades, and release exercises; it is not a general application testing environment. Public endpoints—https://api.mainnet-beta.solana.com for mainnet and https://api.devnet.solana.com for devnet—are available, but they are rate-limited and best for light tests. Managed RPC providers can offer authenticated endpoints, clearer limits, WebSocket support, and better observability across environments. Evaluate providers by whether they support the exact environments your team uses, match your RPC method mix, and provide a path from shared to dedicated capacity. OnFinality maintains Solana mainnet and Devnet resources; check the current plan for testnet coverage. Start with Devnet for iterating, use Mainnet for production, and keep environment configuration separate. Always verify current rate limits and endpoint availability in official or provider documentation, because they can change.

Key Takeaways

  • Mainnet is for production with real SOL; Devnet is for daily development with test SOL; Testnet is for validator and network upgrade testing.
  • Public endpoints are rate-limited and best for light tests; managed RPC adds API keys, observability, and clearer limits.
  • Keep cluster URLs in environment variables and never mix mainnet and devnet credentials or wallets.
  • Verify provider coverage for the exact RPC methods, clusters, and WebSocket support your application depends on.

Solana cluster coverage: mainnet, devnet, and testnet

Solana operates three primary clusters for application developers: mainnet-beta (production), devnet (development), and testnet (pre-release testing). Each cluster has its own RPC endpoints and expected usage patterns.

For most teams, daily RPC usage should target devnet first, with mainnet reserved for user-facing traffic. Testnet is not a general development environment; it is used by validators and core contributors to exercise network upgrades and validator behavior.

CriterionWhat to checkWhy it matters
MainnetProduction cluster with real SOLUser-facing app traffic and asset handling
DevnetDevelopment cluster with free test SOL; faucet https://faucet.solana.comDaily testing, program deployment, and QA
TestnetValidator and network upgrade testingRelease validation for protocol changes, not app testing

Environment-specific endpoint and authentication strategy

Each environment should map to a single, explicit endpoint URL. Public endpoints require no authentication but have aggressive rate limits and should be treated as convenience defaults, not production infrastructure.

Managed RPC providers typically issue an API key that can be used across clusters by changing the endpoint URL. Some providers use a single dashboard key, while others may use separate keys per network; verify the current model.

Development to staging to production workflow

A repeatable Solana workflow starts with devnet: deploy programs, run test transactions, and validate wallet flows using free test SOL. Move to staging only after devnet tests pass and your configuration is fixed.

Staging on mainnet should use small, controlled traffic or dedicated test accounts. Production requires a managed RPC endpoint with sufficient limits, WebSocket support if needed, and monitoring.

  • Local/CI: use devnet endpoint or a local validator for fast iteration.
  • Staging: use devnet for QA, then a mainnet beta canary if required.
  • Production: switch to mainnet managed endpoint with API key and observability.

Safe cluster switching and configuration separation

Never hardcode cluster URLs. Use environment variables such as SOLANA_RPC_URL, SOLANA_WS_URL, and a separate SOLANA_CLUSTER variable. This prevents accidental mainnet transactions during devnet testing and makes rollback simple.

Use separate wallet keypairs for devnet and mainnet. Test SOL and real SOL must never share the same file or mnemonic, and your code should refuse to submit transactions when the environment variable does not match the expected cluster.

  • Define a per-environment config: e.g., .env.development, .env.staging, .env.production.
  • Set cluster before creating a Solana Connection object, either via CLI config or SDK API.
  • Verify the cluster after connection by checking a known account or slot against the expected network.

Provider coverage checklist

Use this checklist before committing to a Solana RPC provider. It covers cluster availability, method parity, authentication, and operational fit.

CriterionWhat to checkWhy it matters
Cluster availabilityDoes the provider expose mainnet, devnet, and (if needed) testnet endpoints?Development, staging, and production need consistent access.
Method parityAre the JSON-RPC methods your app uses (getProgramAccounts, getMultipleAccounts, etc.) supported across all required clusters?Missing methods force workarounds and risk test gaps.
Authentication modelAPI key per cluster or one key for all environments? Rate limit visibility?Simplifies configuration and incident response.
WebSocket supportAre real-time subscription endpoints available and stable?Event-driven applications cannot rely on polling alone.
Archive/historical accessDoes the provider offer archive data on mainnet? Is it needed for your queries?Backfilling and historical analysis may require archive nodes.
Scaling pathCan you move from shared to dedicated capacity without changing the codebase?Traffic spikes and indexing jobs can outgrow shared limits.

Public endpoints vs managed RPC

Public endpoints work for one-off testing and tutorials, but their rate limits can throttle CI pipelines and team usage. Managed RPC providers offer authenticated access, dashboards, and usually better support for WebSocket and burst traffic.

For devnet, public endpoints may be enough early on; for mainnet, use a managed provider. OnFinality lists Solana mainnet and devnet options on its network pages—check the current endpoint URLs and regions before use.

  • Public: free, no support, limits can change without notice.
  • Managed shared: API key, usage visibility, higher limits based on plan.
  • Dedicated: isolated capacity for high-throughput or latency-sensitive workloads.

Common pitfalls when mixing Solana environments

A common failure is pointing a production wallet or backend at the devnet URL. Another is assuming devnet and mainnet behavior are identical; devnet may reset, and testnet may run a different software version.

Faucet limits can interrupt test flows; request devnet SOL in advance and keep wallet files separate. Never reuse a production wallet address on devnet.

  • Hardcoded public endpoints in config files cause environment drift.
  • Forgetting to update WebSocket URLs when switching clusters breaks subscriptions.
  • Using devnet success as a production readiness signal without mainnet canary testing.
  • Ignoring provider status pages for planned maintenance or outages.

Next steps for your Solana RPC setup

Start by documenting every RPC method and environment your application needs. Test against public devnet to validate basic connectivity, then evaluate managed providers for mainnet and staging.

Review OnFinality’s Solana mainnet page at /networks/solana and the Solana Devnet guide at /rpc-assistant/solana-devnet-guide for current endpoint details. For a broader comparison of public, shared, and dedicated options, see /rpc-assistant/best-solana-rpc-provider.

  • Create a small test script that exercises required methods on each cluster.
  • Check WebSocket stability and reconnect behavior from your deployment region.
  • Confirm pricing and limit upgrade paths before moving sustained traffic.
  • Re-evaluate provider coverage after major feature changes or traffic growth.

Frequently Asked Questions

Which Solana RPC provider supports mainnet, devnet, and testnet?

Support varies by provider. Many managed providers offer mainnet and devnet, while testnet coverage is less common. Check each provider’s network pages and current plan details. OnFinality provides Solana mainnet and Devnet endpoints; verify testnet availability on /networks/solana.

Can I use the same API key for Solana devnet and mainnet?

It depends on the provider. Many managed RPC services issue a single API key that works across clusters by changing the endpoint URL, while others use separate keys. Verify the authentication model in the provider’s documentation. OnFinality lists separate network pages; check current key usage.

What is the public RPC endpoint for Solana devnet?

The public Solana devnet RPC endpoint is https://api.devnet.solana.com. Test SOL is available from the official faucet at https://faucet.solana.com. For more reliable devnet access, see /rpc-assistant/solana-devnet-guide.

Is Solana testnet suitable for application development?

No. Solana testnet is intended for validator performance testing and network upgrade validation. Use devnet for daily application development and staging, and mainnet for production.

How do I switch between Solana clusters safely?

Use environment variables to define different endpoint URLs for mainnet, devnet, and testnet. Keep wallet files separate, verify the connected cluster before submitting transactions, and never mix test SOL and real SOL. A good practice is to set SOLANA_CLUSTER and refuse to run if it does not match the expected environment.

RPC Knowledge Base

Related RPC details

Never Worry about Infrastructure Again

OnFinality takes away the heavy lifting of DevOps so you can build smarter and faster.

Get Started