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.
| Criterion | What to check | Why it matters |
|---|---|---|
| Mainnet | Production cluster with real SOL | User-facing app traffic and asset handling |
| Devnet | Development cluster with free test SOL; faucet https://faucet.solana.com | Daily testing, program deployment, and QA |
| Testnet | Validator and network upgrade testing | Release 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.
- Use https://api.mainnet-beta.solana.com for public mainnet access only when no API key is available.
- Use https://api.devnet.solana.com for public devnet access, and get test SOL from https://faucet.solana.com.
- For managed access, review OnFinality’s Solana mainnet page at /networks/solana and the Devnet guide at /rpc-assistant/solana-devnet-guide.
- Keep authentication tokens out of source control; use environment variables or secret managers.
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.
| Criterion | What to check | Why it matters |
|---|---|---|
| Cluster availability | Does the provider expose mainnet, devnet, and (if needed) testnet endpoints? | Development, staging, and production need consistent access. |
| Method parity | Are the JSON-RPC methods your app uses (getProgramAccounts, getMultipleAccounts, etc.) supported across all required clusters? | Missing methods force workarounds and risk test gaps. |
| Authentication model | API key per cluster or one key for all environments? Rate limit visibility? | Simplifies configuration and incident response. |
| WebSocket support | Are real-time subscription endpoints available and stable? | Event-driven applications cannot rely on polling alone. |
| Archive/historical access | Does the provider offer archive data on mainnet? Is it needed for your queries? | Backfilling and historical analysis may require archive nodes. |
| Scaling path | Can 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.