Solana validator setup in 2026 requires more precision than any comparable PoS chain. The process is not complicated, but the order of operations matters, the system tuning is mandatory rather than optional, and skipping steps creates problems that surface hours or days after launch: missed votes, delinquency events, and SFDP disqualification that could have been avoided.
This guide covers the complete solana validator setup from a clean Ubuntu 24.04 server through a live, monitored mainnet validator: system preparation, disk layout, keypair generation and security, vote account creation, Agave installation and startup configuration, system tuning, post-launch verification, watchtower monitoring setup, and the SFDP metric reporting configuration required from day one.
If you have not reviewed the hardware and delegation requirements before starting, read our Solana validator requirements guide first: starting a solana validator setup on underspecced hardware or on an over-concentrated ASN wastes significant time and money.
Before You Start: Solana Validator Setup Prerequisites
Before beginning the solana validator setup process, confirm you have:
- A bare metal server running Ubuntu 22.04 or 24.04 (not Docker, not VM for production).
- Three separate NVMe disks: one for ledger, one for accounts, one for OS.
- A dedicated public IP address, not behind NAT.
- SOL in a local wallet for vote account creation and initial vote fees (minimum 0.5 SOL, 2-5 SOL recommended for buffer).
- A trusted local machine separate from the server for keypair generation.
Docker is explicitly not recommended for production solana validator setup. The performance overhead from containerization affects vote timing and skip rate at Solana’s transaction throughput levels.
Step 1: Keypair Generation on Your Trusted Local Machine
The most critical security decision in the entire solana validator setup is where and how you generate your keypairs. All three keypairs must be generated on your local trusted machine, never on the validator server itself.
A Solana validator uses three keypairs with distinct roles:
Identity keypair: your validator’s public identity on the network. Used for gossip and to sign transactions. Stored on the validator server at runtime.
Vote account keypair: the address of your on-chain vote account. Never needs to be on the server after vote account creation.
Authorized withdrawer keypair: has authority to withdraw from the vote account and change all vote account parameters including commission and identity. This is the most sensitive keypair in the entire setup. It must never be stored on the validator server.
# On your LOCAL trusted machine — not the server
# Install Solana CLI locally
sh -c "$(curl -sSfL https://release.anza.xyz/v3.1.13/install)"
export PATH="$HOME/.local/share/solana/install/active_release/bin:$PATH"
# Verify installation
solana --version
agave-validator --version
# Configure for mainnet
solana config set --url https://api.mainnet-beta.solana.com
# Generate the three keypairs
solana-keygen new -o ~/validator-keypair.json
solana-keygen new -o ~/vote-account-keypair.json
solana-keygen new -o ~/authorized-withdrawer-keypair.jsonWrite down the seed phrases for all three keypairs and store them offline. If you lose the authorized withdrawer keypair, you permanently lose control of your vote account and cannot withdraw tokens from it.
Immediately after creating the authorized withdrawer keypair:
# Back it up to offline storage, then delete from local machine
cp ~/authorized-withdrawer-keypair.json /path/to/offline/backup/
# Only delete after confirming the backup is readable and secure
rm ~/authorized-withdrawer-keypair.jsonThe authorized withdrawer keypair should never be on any internet-connected machine during normal operations. Hardware wallet or air-gapped machine storage is the production standard.
Step 2: Create the Vote Account
Create the vote account before setting up the server. This is done from your local machine.
# Fund your identity keypair (mainnet — you must transfer SOL manually)
# Check your balance first
solana balance ~/validator-keypair.json
# Set the identity keypair as default
solana config set --keypair ~/validator-keypair.json
# Create the vote account
solana create-vote-account \
--fee-payer ~/validator-keypair.json \
~/vote-account-keypair.json \
~/validator-keypair.json \
~/authorized-withdrawer-keypair.json
# Verify vote account was created
solana vote-account ~/vote-account-keypair.jsonNote your vote account address; you will need it in the validator startup script. The vote account address is fixed for the lifetime of the account and cannot be changed.
Set your commission immediately after creation:
# Set commission to 5% (maximum allowed for SFDP)
solana vote-update-commission \
~/vote-account-keypair.json \
5 \
~/authorized-withdrawer-keypair.jsonStep 3: Server Preparation
SSH into your validator server and set up the base system.
# Create a dedicated non-root user for the validator
sudo adduser sol
sudo usermod -aG sudo sol
# Switch to the sol user for remaining setup
sudo su - sol
# Update system packages
sudo apt update && sudo apt upgrade -y
# Install required dependencies
sudo apt install -y \
libssl-dev \
libudev-dev \
pkg-config \
zlib1g-dev \
llvm \
clang \
cmake \
make \
libprotobuf-dev \
protobuf-compilerStep 4: Disk Layout and Mount Configuration
Correct disk layout is one of the most operationally important steps in the solana validator setup. The ledger and accounts databases have fundamentally different I/O patterns; mixing them on one disk degrades both.
Identify your disks:
lsblk
# Example output:
# nvme0n1 - OS disk (already mounted as /)
# nvme1n1 - Ledger disk
# nvme2n1 - Accounts diskFormat and mount the ledger disk:
# Format ledger disk
sudo mkfs.ext4 -F /dev/nvme1n1
# Create mount point
sudo mkdir -p /mnt/ledger
# Mount
sudo mount /dev/nvme1n1 /mnt/ledger
# Set ownership
sudo chown -R sol:sol /mnt/ledger
# Add to fstab for persistence
echo "/dev/nvme1n1 /mnt/ledger ext4 defaults,noatime 0 0" | sudo tee -a /etc/fstabFormat and mount the accounts disk:
# Format accounts disk
sudo mkfs.ext4 -F /dev/nvme2n1
# Create mount point
sudo mkdir -p /mnt/accounts
# Mount
sudo mount /dev/nvme2n1 /mnt/accounts
# Set ownership
sudo chown -R sol:sol /mnt/accounts
# Add to fstab
echo "/dev/nvme2n1 /mnt/accounts ext4 defaults,noatime 0 0" | sudo tee -a /etc/fstabThe noatime mount option prevents the filesystem from updating access timestamps on every read, a significant I/O reduction on read-heavy blockchain workloads.
Verify mounts:
df -h /mnt/ledger /mnt/accounts
# Should show both disks mounted with available spaceStep 5: System Tuning
System tuning is mandatory for a stable solana validator setup. Without these settings, the validator may fail to start or perform poorly.
# Create the Solana system tuning config
sudo bash -c "cat > /etc/sysctl.d/21-agave-validator.conf << EOF
# Increase UDP buffer sizes for Solana's high-throughput networking
net.core.rmem_default = 134217728
net.core.rmem_max = 134217728
net.core.wmem_default = 134217728
net.core.wmem_max = 134217728
# Increase memory mapped files limit
vm.max_map_count = 1000000
# Increase number of allowed open file descriptors
fs.nr_open = 1000000
EOF"
# Apply immediately
sudo sysctl -p /etc/sysctl.d/21-agave-validator.conf
# Increase open file descriptor limits
sudo bash -c "cat >> /etc/security/limits.conf << EOF
sol soft nofile 1000000
sol hard nofile 1000000
EOF"Disable swap:
Solana validators must not use swap. Swap causes latency spikes that directly cause missed votes.
# Disable swap immediately
sudo swapoff -a
# Disable permanently (comment out swap entries in fstab)
sudo sed -i '/swap/s/^/#/' /etc/fstab
# Verify swap is off
free -h
# Swap line should show 0Set NVMe I/O scheduler:
# Set I/O scheduler to none for NVMe drives (best for high IOPS workloads)
echo none | sudo tee /sys/block/nvme1n1/queue/scheduler
echo none | sudo tee /sys/block/nvme2n1/queue/scheduler
# Make persistent via udev rule
sudo bash -c "cat > /etc/udev/rules.d/60-nvme-scheduler.rules << EOF
ACTION==\"add|change\", KERNEL==\"nvme*\", ATTR{queue/scheduler}=\"none\"
EOF"Configure hugepages (required for Firedancer; recommended for Agave):
# Set hugepages (adjust count based on your RAM — 1000 is conservative for 256GB)
echo 1000 | sudo tee /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
# Make persistent
echo "vm.nr_hugepages = 1000" | sudo tee -a /etc/sysctl.d/21-agave-validator.confStep 6: Install Agave
# Install Agave (as sol user)
sh -c "$(curl -sSfL https://release.anza.xyz/v3.1.13/install)"
# Add to PATH
echo 'export PATH="$HOME/.local/share/solana/install/active_release/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
# Verify installation
agave-validator --version
solana --versionVerify binary checksum before use in production:
# Get the expected checksum from the official release page
# https://github.com/anza-xyz/agave/releases
sha256sum ~/.local/share/solana/install/active_release/bin/agave-validatorAlways verify checksums match the published release hashes before running on mainnet with real stake.
Step 7: Copy Keypairs to Server
Transfer only the keypairs the validator needs at runtime. The authorized withdrawer keypair stays offline.
# From your LOCAL machine - copy identity and vote account keypairs only
scp ~/validator-keypair.json sol@YOUR_SERVER_IP:/home/sol/
scp ~/vote-account-keypair.json sol@YOUR_SERVER_IP:/home/sol/
# On the server - set correct permissions
chmod 600 /home/sol/validator-keypair.json
chmod 600 /home/sol/vote-account-keypair.json
# Create an unstaked identity keypair for safe restarts
solana-keygen new -o /home/sol/unstaked-identity.jsonThe unstaked identity keypair is used during node failover and safe restarts. It prevents double-voting during the transition between stopping one instance and starting another.
Step 8: Create the Startup Script
The startup script is the core configuration of your solana validator setup. Every flag matters.
mkdir -p /home/sol/bin
cat > /home/sol/bin/validator.sh << 'EOF'
#!/bin/bash
# Solana Agave Validator Startup Script
# Updated for mainnet May 2026 SFDP requirements
exec agave-validator \
--identity /home/sol/validator-keypair.json \
--vote-account /path/to/your/vote-account-keypair.json \
--ledger /mnt/ledger \
--accounts /mnt/accounts \
--log /home/sol/agave-validator.log \
--rpc-port 8899 \
--rpc-bind-address 127.0.0.1 \
--dynamic-port-range 8000-8020 \
--entrypoint entrypoint.mainnet-beta.solana.com:8001 \
--entrypoint entrypoint2.mainnet-beta.solana.com:8001 \
--entrypoint entrypoint3.mainnet-beta.solana.com:8001 \
--entrypoint entrypoint4.mainnet-beta.solana.com:8001 \
--entrypoint entrypoint5.mainnet-beta.solana.com:8001 \
--known-validator 7Np41oeYqPefeNQEHSv1UDhYrehxin3NStELsSKCT4K2 \
--known-validator GdnSyH3YtwcxFvQrVVJMm1JhTS4QVX7MFsX56uJLUfiZ \
--known-validator DE1bawNcRJB9rVm3buyMVfr8mBEoyendZYBPge9mMxNB \
--known-validator CakcnaRDHka2gXyfbEd2d3xsvkJkqsLw2akB3zsN1D2S \
--only-known-rpc \
--expected-genesis-hash 5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d \
--wal-recovery-mode skip_any_corrupted_record \
--limit-ledger-size 50000000 \
--no-voting \
--full-rpc-api
EOF
chmod +x /home/sol/bin/validator.shCritical flags explained:
--rpc-bind-address 127.0.0.1 : binds the RPC port to localhost only. Never expose 8899 to the public internet on a staked validator.
--only-known-rpc : downloads genesis and snapshots only from the --known-validator list. Prevents malicious snapshot injection on first boot.
--expected-genesis-hash : verifies you are connecting to the correct chain. The hash shown is the mainnet genesis hash.
--limit-ledger-size 50000000 : caps ledger storage at approximately 500GB. Without this, the ledger will grow until the disk is full.
--no-voting : start without voting first. This is the safe initial launch mode for verifying sync before enabling consensus participation.
Once you have confirmed the node is fully synced, remove --no-voting and --full-rpc-api and restart to begin participating in consensus.
Step 9: Configure Systemd Service
sudo bash -c "cat > /etc/systemd/system/sol.service << EOF
[Unit]
Description=Solana Agave Validator
After=network.target
Wants=systuning.service
[Service]
Type=simple
User=sol
Group=sol
ExecStart=/home/sol/bin/validator.sh
Restart=on-failure
RestartSec=10
LimitNOFILE=1000000
[Install]
WantedBy=multi-user.target
EOF"
sudo systemctl daemon-reload
sudo systemctl enable solStep 10: Firewall Configuration
# Configure UFW
sudo ufw default deny incoming
sudo ufw default allow outgoing
# SSH - change 22 to your actual SSH port
sudo ufw allow 22/tcp
# Solana P2P ports
sudo ufw allow 8000:8020/udp
sudo ufw allow 8000:8020/tcp
# Enable firewall
sudo ufw enable
sudo ufw statusDo not open port 8899 (RPC) to the internet on a staked validator. The RPC port is bound to localhost by the startup script, this firewall configuration adds a second layer of protection.
Step 11: Configure Metrics Reporting
Metric reporting is a mandatory SFDP requirement: validators must report in 8 of the last 10 epochs on both mainnet and testnet. Configure this before launching.
# Set the SOLANA_METRICS_CONFIG environment variable
# Add to sol user's environment
echo 'export SOLANA_METRICS_CONFIG="host=https://metrics.solana.com:8086,db=mainnet-beta,u=mainnet-beta_write,p=password"' >> /home/sol/.bashrc
# Add to the systemd service environment
sudo bash -c "cat >> /etc/systemd/system/sol.service << EOF
[Service]
Environment=SOLANA_METRICS_CONFIG=host=https://metrics.solana.com:8086,db=mainnet-beta,u=mainnet-beta_write,p=password
EOF"
sudo systemctl daemon-reloadThis reports to the public Solana metrics dashboard at metrics.solana.com. Participation in this reporting is what satisfies the SFDP metric reporting requirement.
Step 12: First Launch and Sync Verification
# Start the validator
sudo systemctl start sol
# Monitor the logs in real time
tail -f /home/sol/agave-validator.log
# In a second terminal - check catchup progress
solana catchup YOUR_VALIDATOR_IDENTITY_PUBKEY
# Check gossip - your validator should appear
solana gossip | grep YOUR_VALIDATOR_IDENTITY_PUBKEYWhat to look for in the logs on first launch:
# Good signs:
[timestamp] solana_validator] Starting validator...
[timestamp] new_snapshot_hash
[timestamp] Downloading snapshot...
[timestamp] snapshot download complete
[timestamp] Replaying slots...
# Bad signs:
[timestamp] Error: genesis hash mismatch <- wrong --expected-genesis-hash
[timestamp] Error: unable to connect <- network/firewall issue
OOMKilled <- RAM insufficientThe initial sync can take several hours depending on snapshot download speed and how far behind the network your snapshot is. Monitor with:
# Check how far behind you are
solana catchup YOUR_PUBKEY --follow
# Check validator status
agave-validator --ledger /mnt/ledger monitorStep 13: Enable Voting
Once solana catchup confirms your validator is within a few hundred slots of the cluster, enable voting by removing --no-voting from the startup script and restarting:
# Edit the startup script to remove --no-voting and --full-rpc-api
nano /home/sol/bin/validator.sh
# Restart the validator
sudo systemctl restart sol
# Verify it appears in the active validator set
solana validators | grep YOUR_PUBKEY
# Check your vote account is receiving credits
solana vote-account YOUR_VOTE_ACCOUNT_PUBKEYsolana vote-account YOUR_VOTE_ACCOUNT_PUBKEYYour validator is now participating in consensus. Monitor your first few epochs carefully, this is when configuration issues surface.
Step 14: Watchtower Monitoring Setup
Agave Watchtower is the essential operational tool for any solana validator setup. It monitors your validator for delinquency and sends alerts before the situation becomes a slashing risk.
# Run watchtower as a separate systemd service
sudo bash -c "cat > /etc/systemd/system/agave-watchtower.service << EOF
[Unit]
Description=Agave Watchtower
After=sol.service
[Service]
Type=simple
User=sol
Environment=SLACK_WEBHOOK=https://hooks.slack.com/services/YOUR/WEBHOOK/URL
ExecStart=agave-watchtower \
--monitor-active-stake \
--validator-identity YOUR_VALIDATOR_PUBKEY \
--rpc-url http://127.0.0.1:8899
Restart=on-failure
RestartSec=30
[Install]
WantedBy=multi-user.target
EOF"
sudo systemctl daemon-reload
sudo systemctl enable agave-watchtower
sudo systemctl start agave-watchtowerWatchtower will notify you via Slack (or Discord, Telegram, or Twilio) when your validator becomes delinquent, typically within 60 seconds of the event. This is the minimum monitoring baseline for any production solana validator setup.
For the full Prometheus and Grafana monitoring stack that tracks vote credits, skip rate trends, peer count, and disk I/O, see our blockchain node monitoring guide.
Step 15: Vote Account Maintenance
After launch, the vote account requires active management.
Monitor and top up vote account balance:
# Check vote account balance
solana balance YOUR_VOTE_ACCOUNT_PUBKEY
# Transfer from identity account to vote account when needed
solana transfer YOUR_VOTE_ACCOUNT_PUBKEY 1.0 \
--from /home/sol/validator-keypair.jsonThe vote account needs to maintain sufficient balance to pay for vote transactions. If it runs dry, your validator stops voting and immediately starts losing credits. Automate balance checks with a cron job or monitoring alert.
Monitor vote credits:
# Check your vote credit performance vs cluster average
solana vote-account YOUR_VOTE_ACCOUNT_PUBKEY
# Check recent epoch performance
solana epoch-infoFor SFDP eligibility, your vote credits must stay at or above 97% of the cluster average every epoch. A single epoch below this threshold does not disqualify you, but a pattern will.
Step 16: SFDP Application
Once your validator has been running and meeting performance criteria on both mainnet and testnet for a consistent period, you can apply to the Solana Foundation Delegation Program.
The SFDP application process:
- Ensure your testnet node has been running and meeting baseline criteria for at least 5 of the last 10 testnet epochs
- Verify your ASN concentration is below 25% at validators.app.
- Verify your data center concentration is below 15% at validators.app.
- Confirm your commission is at 5% or below.
- Confirm metric reporting is active and showing in 8 of last 10 epochs.
- Apply via the official SFDP application at solana.org/delegation-program.
The Foundation reviews applications and notifies validators of approval. Once approved, delegation is applied within 1-2 epochs (approximately 2-4 days) of meeting all criteria.
Common Problems in Solana Validator Setup
Validator not appearing in gossip:
solana gossip | grep YOUR_PUBKEY
# If no result after 10+ minutes:
# Check ports 8000-8020 are open both inbound and outbound
# Check your server has a public IP (not behind NAT)
# Verify --entrypoint flags in startup scriptHigh skip rate:
# Check your skip rate
solana validators | grep YOUR_PUBKEY
# Skip rate shown in last column
# If > cluster average + 5%:
# - Check disk I/O is not saturated: iostat -x 1
# - Check CPU frequency is not throttling: watch cat /proc/cpuinfo | grep MHz
# - Check network latency to entrypointsDelinquent validator:
# Check if delinquent
solana validators --delinquent | grep YOUR_PUBKEY
# If delinquent - check if falling behind
solana catchup YOUR_PUBKEY
# If far behind - need fresh snapshot
# Stop validator, delete ledger, restart without --no-snapshot-fetch
sudo systemctl stop sol
rm -rf /mnt/ledger/*
sudo systemctl start solVote account balance depleted:
# Immediate fix - transfer SOL to vote account
solana transfer YOUR_VOTE_ACCOUNT_PUBKEY 2.0 \
--from /home/sol/validator-keypair.json
# Set up automated monitoring to prevent recurrenceConclusion
A complete solana validator setup involves more moving parts than most PoS chains: three keypairs with distinct security requirements, mandatory system tuning that determines whether the node starts at all, split disk configuration for performance, and SFDP compliance requirements that must be configured from day one rather than retrofitted.
The sequence in this guide, generate keys offline, create vote account before server setup, tune the system before installing the client, launch without voting to verify sync first, reflects the failure modes we have seen most commonly when these steps are reordered or skipped.
At The Good Shell we deploy and operate Solana validator infrastructure for Web3 protocols and institutional operators who need to meet 2026 production standards without building the stack from scratch. See our Web3 infrastructure services or our case studies to see what a production Solana operation looks like end to end.
For the authoritative Agave validator documentation, the Anza Agave docs are the primary reference, they are updated with each release.