Solana Mainnet Deployment Checklist — What to Verify Before Going Live

Complete checklist for deploying a Solana application to mainnet. Code, infrastructure, monitoring, and the things that catch teams off-guard.

BoltTx Team··6 min read
solanamainnetdeploymentproductionchecklist

Going from devnet to mainnet on Solana is a step that catches more teams off-guard than it should. Devnet is forgiving; mainnet isn't. The transition surfaces all the issues you didn't notice during development — production load, real money, edge cases that didn't appear in test traffic.

This piece is a checklist for mainnet deployment of a Solana application. Code, infrastructure, monitoring, security, and the operational pieces that distinguish production-ready from "it works on devnet."

Before You Deploy

A pre-deployment checklist:

Code review by someone other than the author. Especially for any program code. Bugs catch users' money on mainnet.

Audit (for serious programs). Third-party audit. Worth the cost for anything handling user funds.

End-to-end testing on devnet. Real flows from start to finish. Not just unit tests.

Devnet load testing. Stress test the read patterns and submission patterns. Devnet behaviour is forgiving but you can still find issues.

Security review. Specifically: authority management, signing security, key storage.

Documentation. What does your code do? How does someone debug it? Future-you will appreciate this.

Rollback plan. If you deploy and something is wrong, what do you do?

Infrastructure Checklist

Production-grade RPC. Public mainnet RPC is not enough. Pick a provider with documented SLA and capacity.

Read RPC and write RPC. Often different providers; different optimisation.

Failover RPC. What happens if your primary fails?

Connection pooling configured. Keep-alive on; pool sized for peak concurrency.

Environment variable configuration. No hardcoded URLs or keys.

Secrets management. Production keys in a vault, not in your repo. Hardware wallets or KMS for high-value signing.

Logging infrastructure. Where do logs go? Searchable? Retained how long?

Metrics infrastructure. P95 latency, error rates, business metrics. Dashboard ready before deployment.

Alerting. What conditions wake someone up?

Per-signature telemetry. For every transaction submitted, track the outcome.

Code-Level Checklist

For client code:

skipPreflight: true in production sends. Manage simulation explicitly.

maxRetries: 0. Manage retries yourself with fresh blockhashes.

Explicit compute budget. Both limit and price.

Profile-aware tip strategy. Vary based on expected value.

Confirmation after sending. Don't trust signature returned to mean landed.

Per-signature telemetry on every send. Including for simulate failures.

Error handling for every RPC call. Network errors, rate limits, timeouts.

Idempotency at the application layer. Don't double-execute on retries.

Daily kill switches. Loss limits, exposure limits, manual stop.

Graceful shutdown. Drain in-flight requests; don't crash.

For Anchor Programs

If you're deploying a program:

Multi-sig program upgrade authority. Don't deploy production programs from a single key. Use Squads or similar.

Audit before deployment. Third-party. Especially for programs handling funds.

Realistic test coverage. Not just happy paths.

Authority management documented. Who can do what, with what keys?

Upgrade path documented. When you need to upgrade, what happens?

Realistic IDL distribution. Clients need the IDL; how do they get the right version?

Account migration plan. If account layout changes, what about existing accounts?

Operational Readiness

Runbook. What do you do when X breaks? Common scenarios documented.

On-call rotation. Someone is paged when prod issues happen.

Incident response process. Severity levels, escalation, communication.

Status page or equivalent. Users know when there's an issue.

Customer support channel. How do users reach you?

Backup of critical data. Off-chain data (analytics, user metadata) backed up.

Disaster recovery plan. Tested, not just documented.

Trading-Specific Checklist

If your application does any trading:

Sandwich exposure measurement built-in. Compare AMM-math expected vs actual fills. Continuous monitoring.

Anti-MEV RPC routing. Non-negotiable for any directional trading.

Position size limits. Per-trade and per-day.

Loss limits. Daily and per-position.

Pause functionality. Can you stop trading without redeploying?

P&L attribution. For each trade, know what was profit, what was fees, what was sandwich tax, what was slippage.

Backtesting infrastructure. Strategy changes get backtested before deployment.

Paper trading mode. Test new strategies in production conditions without real money.

Security Checklist

Hot wallet vs cold wallet separation. Hot wallet has minimal funds. Cold wallet for treasury.

Hardware wallet for production keys. Or KMS-backed signing.

Key rotation procedure. When and how do you rotate keys?

No keys in environment variables in shared environments. Use proper secret management.

HTTPS only. No HTTP in production.

Rate limiting on your own services. Don't get DDoS'd.

Input validation everywhere. Don't trust user input.

Audit logging for sensitive operations. Who did what when?

Monitoring Checklist

Latency monitoring. P50/P95/P99 confirmation latency for sends. Read query latency. Trend over time.

Error rate monitoring. Failed sends, failed reads, transaction failures. Alert on anomalies.

Cost monitoring. Total fees, tips, unsuccessful-send costs. Trend lines.

Business metrics. P&L, volume, user activity (for dApps). What does success look like?

Sandwich exposure monitoring (for trading). Continuous, not one-off.

Resource monitoring. CPU, memory, network on your servers.

Solana network monitoring. Slot height, network health, validator status.

Day of Deployment

Deploy during low-traffic hours. Easier to recover if things go wrong.

Have rollback ready. Tested rollback path.

Monitoring dashboards open. Watch the deployment.

Quiet on-call. Don't deploy on Friday afternoons.

Communication plan. Who do you tell when something happens?

Gradual rollout if possible. Canary releases beat big-bang deployments.

After Deployment

Watch for 24-48 hours. Issues sometimes show up only after meaningful traffic.

Compare metrics to baseline. Is performance what you expected?

Customer feedback. What are users saying?

Stress test gradually. Don't push to peak immediately.

Learn from issues. Whatever surprises you, document for next time.

What to Do This Week

If you're preparing for mainnet:

  1. Run through this checklist. Honestly. Where are the gaps?
  2. Test failover paths. What happens when your RPC fails? When your secondary fails?
  3. Document your runbook. Future-you will thank you.
  4. Set up monitoring before deployment, not after. You need baselines.
  5. Test the deployment process itself. On staging, with realistic conditions.
  6. Have a rollback plan ready. Tested.

Try BoltTx for Production Workloads

BoltTx is built for production deployment:

import { Connection } from "@solana/web3.js";

const connection = new Connection(
  "https://bolttx.io/?api-key=YOUR_API_KEY",
  "processed"
);

Free tier signup. Test against the free tier with production-like load before committing.

FAQ

Should I deploy to mainnet on a Friday? No. Tuesday or Wednesday morning gives you time to fix things during business hours.

What's the minimum SLA I should accept from an RPC provider? For production, look for documented uptime (99.9%+ is reasonable), documented latency commitments, and clear incident response.

Should I run my own validator? For most teams, no. Use a managed RPC. Self-hosting is operationally expensive without proportional benefit.

How do I know my Anti-MEV protection is working? Compare AMM-math expected outputs against actual fills. The systematic gap (or absence) tells you.

What's the most common production issue? Tail latency under congestion. Things that work in test fall over at peak load.

Further Reading

Back to all posts