The Solana CLI

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.

Summary

• The Solana CLI packages cluster config, identity (keypairs), funding, inspection, transfers, program deploy, token ops, and logs into one operational surface over RPC.
• Insight: Almost every "wrong balance," "deploy to wrong network," or "who signed this?" incident is a config or keypair mistake, not a mystery bug in your program.
• Key Concepts: RPC URL / cluster, commitment, default keypair, solana-keygen, airdrop vs transfer, account and program show, program deploy / upgrade authority, spl-token, solana logs, CLI vs @solana/kit.
• When to Use: Bootstrap a machine, fund dev wallets, smoke-test RPC, inspect state after a failed tx, deploy or upgrade a program, mint test tokens, or stream logs while iterating locally.
• Limitations/Trade-offs: Great for interactive ops and CI glue; weak as a product wallet path, high-volume submitter, or type-safe app client compared to @solana/kit 7.0.0 and generated SDKs.
• Related Topics: Agave install pin, local validator, Anchor deploy wrappers, RPC commitment, program upgrade authorities.

Foundations

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.

Mechanics & Interactions

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 authority

1. Config: pick the cluster brain

Set 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.

2. Keypair: establish who pays and who controls

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.

3. Fund: make the identity usable

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.

4. Inspect: read before you write

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.

5. Send and deploy: mutate with the same identity

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.

6. Tokens and logs: same loop, wider tools

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.

Advanced Considerations & Applications

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.

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.

Common Misconceptions

• "The CLI is a different API than my app uses." Both speak JSON-RPC to a cluster; the CLI is a packaged client, not a second consensus path.
• "solana config is optional once I pass flags sometimes." Defaults still bite the commands you forget to override; treat config as the session's source of truth.
• "Airdrop works everywhere." Faucets are for dev/test clusters; mainnet funding is real SOL from outside the faucet commands.
• "One keypair file is enough forever." Dev, deploy, treasury, and upgrade authority are different risk roles; combine them only when you accept the blast radius.
• "anchor deploy means I can ignore Solana CLI." Anchor still depends on cluster URL, keys, and often the same install pin; CLI inspection and logs remain essential.
• "If balance is non-zero, deploys will always succeed." Deploys need enough SOL for fees, rent-exempt program accounts, and buffer flows; "some balance" is not a cost model.
• "spl-token is unrelated tooling." It shares config and identity patterns; token state is still accounts on the same cluster.
• "Logs replace tests." solana logs explains a live failure; it does not prove correctness across upgrades the way automated tests do.

FAQs

Related

• Solana CLI Basics - install, solana config, and choosing a cluster
• Keypairs with solana-keygen - generate, recover, and manage signing identities
• Airdrops & Balances - fund dev wallets and read SOL balances
• Inspecting Accounts & Programs - solana account and program metadata
• Sending SOL & Transactions - transfers and confirmation from the terminal
• Deploying Programs - solana program deploy, buffers, and upgrade authority
• spl-token CLI - mints, ATAs, and token transfers
• Logs & Debugging - solana logs and transaction inspection

Stack 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.