Summary
Solana Devnet is a public test cluster for building and testing Solana programs with free test SOL—no real value. The primary public RPC endpoint is https://api.devnet.solana.com, with WebSocket support at wss://api.devnet.solana.com. This endpoint is free but shared, and Solana enforces rate limits that can change; for heavy development, QA, or CI pipelines, a managed RPC provider is often more reliable.
To get started, request test SOL from the official faucet at https://faucet.solana.com or use the Solana CLI airdrop. Configure the Solana CLI with solana config set --url devnet, or in JavaScript/TypeScript create a Connection using the Devnet URL via @solana/web3.js. For production-like testing or repeated runs, evaluate a managed Devnet RPC endpoint such as OnFinality’s Solana Devnet offering—check the network page for current endpoint options and WebSocket access. Remember: Devnet is for development and testing only; never deploy production workloads there. Choose a setup that matches your request volume, observation needs, and path to mainnet.
Key Takeaways
- Use
https://api.devnet.solana.comfor quick tests, but expect rate limits that can change; verify limits in official docs. - Get free test SOL from
https://faucet.solana.comor viasolana airdropfor Devnet transactions. - For reliable Devnet access in QA or CI, compare managed RPC providers (like OnFinality) with WebSocket support and higher limits.
- Keep Devnet and Mainnet configuration separate; Devnet is for testing only and may reset.
Solana Devnet RPC URL
Solana Devnet is a public test cluster for development. The default public RPC endpoint is https://api.devnet.solana.com, with WebSocket support at wss://api.devnet.solana.com. This endpoint is free to use but is shared and rate-limited; Solana enforces limits that can change without notice, so check the official cluster documentation for current behaviour.
For projects that need more consistent access during testing, OnFinality provides a managed Solana Devnet RPC endpoint. The current endpoint URL, WebSocket access, and available regions (including N. Virginia and Hong Kong) are listed on the Solana Devnet network page. Use the managed endpoint when your development workflow outgrows the public endpoint. Learn more about Solana public RPC to understand the difference.
- Public HTTP:
https://api.devnet.solana.com - Public WebSocket:
wss://api.devnet.solana.com - Managed endpoint: see Solana Devnet RPC for current URL and access options
- Devnet uses test SOL, not real SOL, and may be reset
| Criterion | What to check | Why it matters |
|---|---|---|
| Network name | Solana Devnet | Development and testing cluster |
| RPC URL | https://api.devnet.solana.com (public) | Default HTTP endpoint |
| WebSocket URL | wss://api.devnet.solana.com (public) | For real-time subscriptions |
| Faucet | https://faucet.solana.com | Source of free test SOL |
| Native token | Devnet SOL (test token) | No real value |
| Reset policy | May be reset periodically | Do not store permanent data |
Getting Test SOL from the Faucet
To pay for transaction fees and rent on Devnet, you need Devnet SOL. The official Solana Devnet faucet is the primary source. Enter your Devnet wallet address and request an airdrop. The faucet enforces request limits; connecting a GitHub account may raise the limit. The exact limits are not fixed and can change, so check the faucet page for current rules.
You can also request SOL via the Solana CLI when your CLI is configured for Devnet. This is convenient for scripts and CI, but it relies on the same faucet infrastructure and may be rate-limited.
- Official faucet:
https://faucet.solana.com - CLI airdrop:
solana airdrop <amount> <recipient_address> --url devnet - Check balance:
solana balance --url devnet - Use a test wallet; never use a mainnet wallet for Devnet testing.
Connect with the Solana CLI
The Solana CLI is the quickest way to switch your environment to Devnet. Install the CLI from the official Solana docs if you haven’t already.
Set the default cluster to Devnet with a single command. You can also point the CLI at a custom RPC URL if you prefer a managed endpoint.
- Set Devnet as the default cluster:
solana config set --url devnet - Or use the full public URL:
solana config set --url https://api.devnet.solana.com - For a managed endpoint, replace the URL:
solana config set --url <your-provider-endpoint> - Verify your configuration:
solana config get - Create a keypair:
solana-keygen new --outfile ~/.config/solana/id.json - Request test SOL:
solana airdrop 1(uses your default keypair)
Connect with JavaScript or an SDK
For dApp development, the JavaScript/TypeScript SDK @solana/web3.js is the standard. Create a Connection object pointing to the Devnet RPC URL. You can use the public endpoint or a managed one.
The same pattern applies to other Solana SDKs (Rust, Python, etc.). Ensure your client handles errors gracefully, especially when rate limits trigger HTTP 429 responses.
- Install the SDK:
npm install @solana/web3.js - Create a connection with the public URL:
const connection = new Connection('https://api.devnet.solana.com', 'confirmed'); - Use the convenience helper:
const connection = new Connection(clusterApiUrl('devnet'), 'confirmed'); - For a managed endpoint, pass its URL:
const connection = new Connection('<your-provider-url>', 'confirmed'); - Use
connection.getBalance()or other methods to test connectivity.
Public Devnet RPC vs Managed Devnet RPC
The public Devnet endpoint is free and fine for light exploration, but it is shared by all developers and subject to rate limits that can throttle automated tests, CI, or heavy development. Managed RPC providers (such as OnFinality) offer authenticated endpoints, higher request limits (varies by plan), more predictable WebSocket connections, and often include analytics and dedicated node options.
When evaluating a managed Devnet RPC provider, focus on workload fit, operational visibility, and scaling path. Check whether the provider supports the exact Solana methods your app uses, whether you can see request volume and errors, and whether you can upgrade to a dedicated node if needed.
- Start with the public endpoint for quick experiments; switch to managed when you hit rate limits or need stability.
- Verify WebSocket support for real-time subscriptions (e.g.,
onAccountChange). - Review pricing and upgrade options before committing to sustained traffic.
- OnFinality’s Solana Devnet RPC includes HTTP/WebSocket access, and regions in N. Virginia and Hong Kong (verify current options on the page).
- For heavy workloads, consider a dedicated Solana node.
- For broader provider evaluation, see our best Solana RPC provider guide.
| Criterion | What to check | Why it matters |
|---|---|---|
| Rate limits | Public: enforced, can change; low per-IP limits. Managed: higher limits based on plan; documented | Avoid throttling during development and CI |
| Reliability | Public: shared, best-effort. Managed: better consistency, support | Prevents intermittent failures |
| WebSocket | Public: wss://api.devnet.solana.com. Managed: often more stable | Real-time subscriptions |
| historical query options | Public: limited. Managed: available on relevant plans | Historical state for debugging |
| Cost | Public: free. Managed: subscription or usage-based | Budget planning |
Mainnet vs Devnet
Solana Devnet is for development and testing, while Mainnet Beta is the production network with real SOL. Devnet mimics Mainnet behaviour but runs on test tokens, may be reset, and may have different feature activation schedules. Always test thoroughly on Devnet before deploying to Solana Mainnet.
The public Mainnet RPC is https://api.mainnet-beta.solana.com, but production applications should use a managed provider like OnFinality for Solana Mainnet with higher limits and better support.
| Criterion | What to check | Why it matters |
|---|---|---|
| Purpose | Devnet: development/testing. Mainnet: live production | Choose correct environment for work |
| Native token | Both use SOL, but Devnet SOL is test token | No real value on Devnet |
| Reset policy | Devnet may reset; Mainnet immutable | Data persistence |
| Rate limits | Both have limits, but mainnet production requires higher capacity | Managed providers often necessary for mainnet |
| Use cases | Devnet for testing; Mainnet for user-facing apps | Release planning |
Solana Devnet Setup Checklist
Use this checklist to ensure your Solana Devnet environment is correctly configured and ready for development. Complete these steps in order, and verify each item before moving to the next.
- Install Solana CLI and confirm it is in your PATH.
- Set the CLI to Devnet (
solana config set --url devnet) or to your managed endpoint. - Generate a keypair and note the public key.
- Airdrop test SOL from the official faucet or via
solana airdrop. - Check your balance with
solana balance. - If using JavaScript, create a
Connectionto the Devnet URL and test a simple read (e.g.,getSlot). - Verify WebSocket connectivity if your app uses subscriptions.
- Set environment variables to separate Devnet and Mainnet configurations.
- If you expect heavy usage, evaluate a managed RPC provider with higher limits and dedicated options.
Frequently Asked Questions
What is the Solana Devnet RPC URL?
The public Devnet RPC URL is https://api.devnet.solana.com, with WebSocket at wss://api.devnet.solana.com. For managed access, check the Solana Devnet network page for OnFinality’s current endpoint.
How do I get test SOL on Devnet?
Use the official faucet at https://faucet.solana.com or run solana airdrop <amount> <address> --url devnet from the CLI. Limits apply and can change, so check the faucet page for current rules.
Can I use Solana Devnet for production?
No. Devnet is strictly for development and testing. Use Solana Mainnet for production deployments.
What is the difference between Solana Devnet and Mainnet?
Devnet runs the same software as Mainnet but uses free test SOL, may be reset periodically, and is intended for testing. Mainnet uses real SOL and hosts live applications.
Does Solana Devnet reset?
Yes, Devnet may be reset periodically to clear state or introduce new features. Always back up program IDs, keys, and deployment scripts.