The Solana CLI
The Solana CLI is how most developers first talk to a cluster without writing a client.
//
Search across all documentation pages
The Solana CLI is how most developers first talk to a cluster without writing a client.
It is not a separate runtime and not a secret admin channel.
It is a local, signed RPC client: config chooses the cluster, a keypair proves who pays and upgrades, and each subcommand turns intent into JSON-RPC calls and transactions.
Solana CLI Basics walks install and solana config; Keypairs with solana-keygen, Airdrops & Balances, Inspecting Accounts & Programs, Sending SOL & Transactions, Deploying Programs, spl-token CLI, and Logs & Debugging each own one job.
This page sits underneath those recipes: how the CLI fits a full developer loop, and when to leave the terminal for programmatic clients.
Think of the CLI as three layers stacked in one binary family.
First is config: which RPC endpoint, which keypair path, and which commitment level every subsequent command inherits unless you override flags.
Second is identity: Ed25519 keypairs on disk (or recovered from seed phrases) that sign fee payments, transfers, deploys, and upgrade-authority changes.
Third is verbs: balance, airdrop, transfer, account, program deploy, logs, and the companion spl-token tool that reuses the same config model for Token Program work.
Nothing in that stack bypasses the ledger rules you already know.
A transfer still needs a funded fee payer, a recent lifetime under the hood, and signatures.
A deploy still creates program accounts under the loader, costs rent and fees, and records an upgrade authority.
A solana account print is still the same account record: lamports, data, owner, executable flag.
The CLI only removes the need to hand-assemble messages for common jobs.
Solana CLI 3.0.10 in this stack ships with the Agave 4.1.1 toolchain install path.
That pin keeps RPC shapes, program deploy behavior, and solana --version aligned with the validators and Anchor 0.32.1 workflows used elsewhere in these docs.
Mismatched versions produce subtle failures that look like network bugs but are client/server skew.
Config is the most underestimated foundation.
solana config get answers three questions every command depends on: where (RPC URL for mainnet-beta, devnet, testnet, or local http://127.0.0.1:8899), who (keypair path), and how confirmed (commitment, often confirmed for day-to-day dev).
Point at localnet while your keys and muscle memory assume devnet, and airdrops, balances, and program IDs all look "wrong" for the wrong reason.
solana-keygen is the identity companion, not an optional extra.
Until a default keypair exists and is set in config, the CLI cannot pay fees or act as upgrade authority.
Treat deployer, upgrade-authority, and day-to-day dev keys as separate roles even if early tutorials share one file.
The productive CLI loop is ordered, not a grab bag of subcommands.
config keypair fund inspect
-------- -------- ---- -------
RPC URL ──► default id ──► airdrop/SOL ──► account /
keypair path (solana-keygen) balance program show
commitment │ │ │
│ │ │
▼ ▼ ▼
send / deploy ─────────────────► logs / confirm
transfer program deploy debug loop
spl-token mint upgrade authoritySet the RPC URL (and usually the keypair) before anything that mutates state.
Every balance check, airdrop, transfer, and deploy is a client call to that URL; the binary does not maintain a second hidden ledger.
Local validator work uses a loopback RPC; public devnet uses faucet-friendly endpoints; mainnet-beta uses real SOL and production consequences.
Commitment tells the CLI how settled a result must look before it treats a read or confirmation as good enough for your workflow.
Generate or recover a keypair with solana-keygen, then point config at that file.
The public key is your on-chain address; the private material signs messages the CLI builds for you.
Without SOL at that address on the configured cluster, fee-paying commands fail even if the rest of the setup is perfect.
On devnet and localnet, airdrop is the usual faucet path to load SOL for fees and rent.
On mainnet-beta there is no free faucet story; you fund from an external source and treat every deploy and transfer as real spend.
solana balance (for the default key or an explicit pubkey) is the cheap sanity check after config or airdrop changes.
solana account and solana program show (and related dump/show helpers) let you verify owners, lamports, executable metadata, and program upgrade authority without writing a TypeScript probe.
Inspection is how you confirm a deploy landed, a buffer still exists, or an account is still system-owned empty data versus program-owned state.
Transfers move SOL under System Program rules using the configured signer as fee payer (and usually as source).
Program deploy uploads compiled sBPF (.so) bytes through loader flows: buffers, program accounts, and an upgrade authority that later controls whether that program can change.
Anchor projects often wrap deploy in anchor deploy, but the underlying cluster identity and RPC are still the same CLI config story.
spl-token is a sibling CLI for mint creation, ATAs, minting, and transfers against the SPL Token program.
It reuses cluster and keypair conventions so you do not maintain a second mental model for "token world."
solana logs, solana confirm, and transaction inspection close the debug loop when a send or deploy fails: stream program logs, pin a signature, and see whether the problem was simulation, insufficient funds, or on-chain program error.
A minimal orienting check after install looks like this (not a full recipe dump):
solana --version # expect solana-cli 3.0.10 with Agave 4.1.1
solana config get # RPC URL, keypair path, commitment
solana balance # identity funded on this cluster?Deep command recipes live in the sibling pages; the mechanic to keep is config → identity → funds → inspect → mutate → logs.
The hard skill is not memorizing flags.
It is knowing when the CLI is the right tool versus when you should move the same ideas into scripts, CI, or @solana/kit 7.0.0 clients.
| Job | Prefer CLI | Prefer programmatic (kit / scripts / Anchor clients) | Why |
|---|---|---|---|
| First-time machine setup | Yes | No | Interactive config, keygen, and version pin are terminal-native |
| One-off airdrop / balance / account peek | Yes | Optional | Fast feedback; no app scaffolding |
| Program deploy & upgrade authority ops | Often | CI wrappers still call CLI or Anchor | Ops-shaped; needs careful key handling |
| Product wallet UX and dapp submits | No | Yes (@solana/kit, wallet adapter) | UX, retries, simulation, typed instructions |
| High-volume or concurrent tx landing | No | Yes | Fee markets, blockhash refresh, custom senders |
| SPL mint smoke tests | spl-token CLI | Kit/scripts for production mints | CLI for rehearsal; product needs policy and automation |
| Regression tests in CI | Thin CLI checks | Anchor tests, LiteSVM, Surfpool, kit scripts | Determinism and assertions beat ad-hoc shell |
| Incident "what is this account?" | Yes | Plus indexers if scale demands | CLI is the quick ground truth against RPC |
Version pinning is an advanced hygiene habit, not a beginner nicety.
Teams standardize on Agave install / CLI 3.0.10 so deploy artifacts and RPC behavior match reviewers' machines.
Key separation is the other advanced habit: a laptop default key for devnet is fine; the same file as mainnet upgrade authority is not.
Use explicit --keypair and hardware or offline ceremonies when authority matters.
Anchor 0.32.1 and Rust 1.91.1 sit beside the CLI rather than inside it: you build with cargo/Anchor, then deploy and inspect with Solana CLI (or Anchor's thin wrapper over the same concepts).
@solana/kit 7.0.0 implements the same RPC and transaction model in TypeScript for application code; the CLI remains the operator's console for the same chain.
When debugging "works in CLI, fails in app," compare RPC URL, commitment, fee payer, and whether the app refreshes blockhashes and simulates.
solana logs explains a live failure; it does not prove correctness across upgrades the way automated tests do.A local toolchain that configures RPC and keypairs, then builds and signs common Solana operations (balances, transfers, deploys, inspection, logs) against a cluster.
This docs stack pins Solana CLI 3.0.10 with the Agave 4.1.1 install line so client behavior matches current validator tooling; install and version-check with the Agave installer workflow used in Solana CLI Basics.
Primarily the default RPC URL (cluster), default keypair path, and commitment level that other commands inherit unless overridden.
Install gives you the client; keygen creates or recovers the signing identity the client uses to pay fees and authorize deploys.
Airdrop requests faucet funds on supported non-mainnet clusters; transfer moves existing SOL from a funded account you control to another address.
Localnet for fast offline iteration with solana-test-validator; devnet for shared public testing and faucets; mainnet-beta only when you intend real value and production program IDs.
Both require correct config and a funded signer; deploy additionally uploads program bytes under the loader and sets upgrade authority metadata you can inspect with program show.
It is a companion CLI for Token Program operations that reuses the same cluster and keypair mindset; use it for mint/ATA rehearsal before encoding the same flows in app clients.
Confirm config and balance first, re-run with inspection commands, then use solana confirm / transaction views and solana logs as covered in Logs & Debugging.
No. Use wallet-connected clients and libraries such as @solana/kit 7.0.0 for product paths; reserve the CLI for operators, CI, and bootstrap.
No. Anchor accelerates program workflow, but config, keys, airdrops, inspection, raw deploy semantics, and logs still surface through Solana CLI concepts even when wrapped.
confirmed is a common CLI default for interactive work; tighten or loosen deliberately when you care about seeing not-yet-finalized state versus waiting for stronger finality.
Balances are per cluster; the same keypair address on devnet and mainnet-beta are different ledgers with independent lamport balances.
It can be, if keys are protected, commands are explicit, and you avoid casual default keypairs; many teams still prefer scripted ceremonies, hardware, or multisig governance rather than an unlocked JSON file on a laptop.
Install and config in Solana CLI Basics, then keygen, funding, inspection, send/deploy, tokens, and logs in the Related list below.
solana config, and choosing a clustersolana account and program metadatasolana program deploy, buffers, and upgrade authoritysolana logs and transaction inspectionStack versions: This page was written for Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1, and @solana/kit 7.0.0.
Reviewed by Chris St. John·Last updated Jul 19, 2026