Client Choices
Choose Agave or Firedancer from operating requirements, not client branding.
Solana has multiple validator-client implementations: software that participates in the same protocol but has different configuration, host, observability, and upgrade models. The operational difference is meaningful: Agave configuration is commonly expressed as startup flags, while Firedancer uses a structured configuration file and has different host requirements.
Agave
Agave is the focus of this section. Its operational model centers on a validator command that explicitly names identity, vote account, ledger/accounts/snapshot paths, trusted peers, RPC behavior, dynamic port range, and recovery policy.
Choose Agave when the deployment, automation, and team experience are built around its current release and command-line configuration model.
Firedancer
Firedancer uses a file-based configuration that defines gossip entrypoints and key paths, and can expose a Prometheus listener. It also requires additional host preparation, including privileged setup for some components and hugepage-related configuration.
Do not translate Agave flags directly into Firedancer assumptions. Treat a client change as a new operational design: validate network configuration, snapshots, metrics, key paths, service behavior, hardware prerequisites, and upgrade/rollback procedures independently.
A decision checklist
| Question | Why it matters |
|---|---|
| Which client and version is accepted by the target network/program? | Version policy can determine eligibility and compatibility. |
| Does the team have a tested build and upgrade path? | Client installation and rollback are operational dependencies. |
| Can the host meet the client’s CPU, memory, network, and privilege requirements? | A supported client still fails on an unsuitable host. |
| Does monitoring cover the client-specific metrics and logs? | A healthy process is not necessarily a healthy validator. |
| Has the recovery path been tested for this client? | Snapshot and ledger behavior may differ. |
Keep the boundary visible
The public docs should state the client used by each runbook and avoid presenting one client’s configuration as universal Solana guidance. That makes review and incident response much easier when client behavior diverges.