
How do I get started building on Solana (devnet → testnet → mainnet) with a simple checklist?
Quick Answer: Start on a local validator or devnet, ship a thin vertical slice of your app, then harden your RPC, testing, and deployment process before you ever touch mainnet. Use a simple checklist for each environment—devnet for feature iteration, testnet for performance and failure testing, and mainnet for real users and funds.
Why This Matters
Solana is built for internet-scale capital markets and payments: funds secured in ~400ms, sub-cent fees, and throughput that doesn’t collapse when your app goes viral. But you only get those properties in production if your development path is disciplined. A clear devnet → testnet → mainnet checklist keeps you from skipping operational steps—RPC strategy, transaction sizing, monitoring—that decide whether your launch feels like a modern payment rail or a flaky demo.
Key Benefits:
- Predictable launch path: You always know what’s “good enough” to ship at each stage instead of guessing when to move from devnet to mainnet.
- Fewer production incidents: You catch issues (rate limits, compute errors, account layout bugs) on testnet instead of with real user funds.
- Faster iteration: A repeatable workflow (CLI, local cluster, deployment steps) means new features move through the same pipeline without re-inventing your process.
Core Concepts & Key Points
| Concept | Definition | Why it's important |
|---|---|---|
| Devnet | Public Solana cluster for testing with free, faucet-funded tokens. | Safest place to iterate on features, contracts, and UX without risking real value or impacting production. |
| Testnet | Public Solana cluster focused on stress-testing network upgrades and validator performance. | Where you test under load, validate RPC patterns, and catch failure modes before mainnet. |
| Mainnet | Live production environment where applications settle real value. | The environment that must deliver ~400ms confirmations, sub-cent fees, and reliable settlement for real users. |
On a high level:
- Mainnet: Live production environment for deployed applications.
- Devnet: Testing with public accessibility for developers experimenting with their applications.
- Testnet: Stress-testing for network upgrades and validator performance.
How It Works (Step-by-Step)
Below is a simple, production-minded checklist to go from “hello, Solana” to a mainnet deployment.
Phase 0: Local Environment & Local Cluster
You’ll move faster if your first iteration never leaves your laptop.
Checklist – Local Setup
-
Install Solana CLI tools
- Follow the official install instructions for your OS.
- Verify:
solana --version
-
Run a local cluster
- Use the built-in test validator:
solana-test-validator - This gives you a fast, flexible cluster to iterate without rate limits or external dependencies.
- Use the built-in test validator:
-
Create a local wallet
- In a separate terminal:
solana-keygen new solana config set --url localhost solana airdrop 2 solana balance
- In a separate terminal:
-
Build a thin vertical slice
- Pick one narrow use case: e.g., “send a stablecoin-like token from A to B with a memo.”
- Implement:
- A simple program (or start purely client-side if using existing SPL programs).
- A minimal UI or script that creates, signs, and sends transactions.
- Confirm you can:
- Create accounts.
- Send tokens.
- Read state back.
Exit criteria to move on: You can run your app end-to-end on solana-test-validator with a single command (npm run dev, cargo run, etc.) and recover quickly from any code change.
Phase 1: Devnet – Public but Safe
Devnet is your first “outside world” test: real cluster behavior, public RPCs, but no real money.
Checklist – Devnet Basics
-
Point CLI to devnet
solana config set --url devnet -
Create / use a devnet wallet and fund it
solana-keygen new # if you don’t already have a keypair solana airdrop 2 # devnet SOL (not real) solana balance -
Deploy your program (if you’re building on-chain logic)
For Anchor-based workflows (from the official pattern):# In your Anchor project root solana config set --url devnet # Build and deploy the program anchor keys sync # Updates program ID in source anchor build # Compile program anchor deploy # Deploy to devnetThen regenerate the client and restart (as defined in many starter templates):
npm run setup # Rebuilds program and regenerates client npm run dev -
Wire your app to devnet RPC
- For early dev, you can use public devnet RPC endpoints.
- Make sure your config/env variables clearly distinguish
localhostvsdevnet.
-
Test user flows on devnet
- Run through your critical flows:
- Onboarding (create account, fund wallet).
- Primary transaction (swap, transfer, mint, etc.).
- Error handling (insufficient funds, invalid inputs).
- Verify:
- Transactions confirm quickly.
- Fees are sub-cent.
- On-chain state matches your expectations.
- Run through your critical flows:
-
Add basic observability
- Decide on one or more explorers for debugging:
- https://explorer.solana.com/ (switch to Devnet)
- https://solscan.io/
- https://solana.fm/
- https://orb.helius.dev/
- Ensure you can:
- Paste a transaction signature and see status, logs, and inner instructions.
- Paste a program ID and see its transactions.
- Decide on one or more explorers for debugging:
Exit criteria to move on:
- All core user journeys work reliably on devnet.
- You can debug a failing transaction via logs and explorers.
- You have at least one automated test hitting devnet (e.g., CI job that runs a smoke test).
Phase 2: Testnet – Performance & Failure Testing
Testnet is where you simulate “the real thing” under more stressful conditions.
Checklist – Testnet Readiness
-
Switch CLI to testnet
solana config set --url testnet -
Fund a testnet wallet
- Use the appropriate faucet or funding mechanism for testnet SOL.
- Verify:
solana balance
-
Deploy your program to testnet
- Repeat the same steps you used on devnet, but treat testnet as a dry run for mainnet:
- Use the same deployment scripts.
- Capture program IDs and config in version control.
- For Anchor:
solana config set --url testnet anchor build anchor deploy npm run setup
- Repeat the same steps you used on devnet, but treat testnet as a dry run for mainnet:
-
Harden your RPC strategy
- Public endpoints are not intended for production-like workloads.
- For realistic tests:
- Use a dedicated RPC provider / endpoint for testnet.
- Respect rate limits; implement retry with backoff and idempotency.
- Treat poor RPC performance as equivalent to cluster issues—monitor and log it.
-
Stress-test your app
- Simulate:
- Burst traffic (many transactions in a short window).
- Edge conditions (large account lists, multiple CPI calls, heavy compute).
- Validate:
- You stay within transaction size and compute limits.
- Your app handles “Slow down” / 429s and transient RPC errors gracefully.
- Simulate:
-
Operational runbook
- Write down:
- How you deploy (commands, config changes).
- How you roll back.
- How you rotate keys and secrets.
- Practice:
- A redeploy.
- A configuration change (e.g., switching RPC endpoints).
- Handling an incident (e.g., simulated RPC outage).
- Write down:
Exit criteria to move on:
- You can handle load tests on testnet without unexplained failures.
- You have a documented, repeatable deployment process.
- You know how your app behaves under RPC errors and cluster congestion.
Phase 3: Mainnet – Production Launch
Mainnet is for real money and real users. Treat it like a modern payments or capital markets platform, not a hackathon demo.
Checklist – Mainnet Launch
-
Switch CLI to mainnet
solana config set --url mainnet-beta -
Production wallets and key management
- Define:
- Funding wallets (treasury, fee accounts).
- Program upgrade authorities (if applicable).
- Store keys securely (HSMs, secure vaults, or hardened key management setups).
- Make sure dev/test keys are never reused in production.
- Define:
-
Production RPC setup
- Use private, production-grade RPC infrastructure, not public endpoints.
- Configure:
- Multiple RPC providers or endpoints for redundancy.
- Health checks and failover logic.
- Monitor:
- Latency to send/confirm transactions.
- Error rates (HTTP 429, 5xx).
- Balance of key payer accounts.
-
Deploy to mainnet
- Use the same scripts and commands used on testnet.
- Keep program IDs, config values, and deployment artifacts under version control.
- After deploy:
- Verify program/account state via explorer.
- Run smoke tests against mainnet with small value.
-
Integrate observability and reconciliation
- Connect:
- Logs and metrics to your monitoring stack.
- Alerts for transaction failure rates, RPC timeouts, and unusual balance movements.
- Use memos and structured references in transactions to simplify reconciliation.
- Connect:
-
Security & limits
- Validate:
- Upgrade authority settings (or choose to make the program immutable when appropriate).
- Account ownership and permissions.
- Review:
- Compute budgets and account layouts for any potential exploits related to CPI or state.
- Validate:
Post-launch checklist:
- Track real TPS for your app, not just cluster-wide.
- Periodically test your rollback and migration procedures on devnet/testnet.
- Keep your Solana CLI, SDKs, and dependencies updated in a controlled manner.
Common Mistakes to Avoid
-
Skipping testnet and going straight from devnet to mainnet:
Avoid it by treating testnet as non-negotiable for load, failure, and deployment rehearsal. If you can’t deploy cleanly to testnet, you’re not ready for mainnet. -
Relying on public RPC for anything production-like:
Avoid it by using public RPC only for early experimentation. For real traffic—even before mainnet—set up private or dedicated RPC, implement caching, and respect rate limits. -
Ignoring transaction and account limits until late:
Avoid it by designing with Solana constraints early: transaction size, account count, compute units, and CPI depth. Use versioned transactions and Address Lookup Tables when you start to hit account list limits. -
Treating local, devnet, and testnet as different apps:
Avoid it by scripting and parameterizing your deployment so the same code and process runs on all three, with only environment variables changing.
Real-World Example
Imagine you’re building a USDC payout rail on Solana for global contractors. You want funds secured in ~400ms and fees around $0.001 so cross-border payouts feel like sending an email.
- Local: You first connect to
solana-test-validator, integrate with the SPL Token program, and build a UI that can create wallets, mint test tokens, and send transfers with memos for invoice IDs. - Devnet: You switch your config to devnet, airdrop SOL, and test the full flow end-to-end using devnet USDC-style tokens. You validate that your reconciliation jobs can read transaction memos from an explorer like Solana Explorer or Solscan.
- Testnet: You bring in a dedicated RPC endpoint, simulate your month-end payout batch (thousands of transfers), and watch for rate limits, compute errors, and latency spikes. You refine your batching and retry logic.
- Mainnet: With a proven process, you deploy your production program and run a small pilot: a few real payouts with internal staff. After observing stable behavior, you ramp volume and integrate monitoring into your ops dashboard.
At each stage, you use the same deployment scripts and app configuration—only the cluster and RPC endpoints change. The final result: a payout rail that feels like real-time settlement rather than a best-effort blockchain experiment.
Pro Tip: Treat RPC like a core dependency, not a black box. In every environment—devnet, testnet, mainnet—log which endpoint you hit, how long requests took, and why they failed. When your app “feels slow,” your first debugging step should be to check RPC behavior and your own call patterns.
Summary
Moving from devnet to testnet to mainnet on Solana is less about heroic coding and more about discipline: same tools, same scripts, progressively higher stakes. Start on a local cluster, stabilize on devnet, rehearse operations on testnet, then bring real value to mainnet only after your deployment, RPC, and monitoring workflows are boring and repeatable. If you treat constraints—transaction size, account limits, RPC rate limits—as design inputs instead of afterthoughts, your Solana app can deliver payment-grade reliability from day one.