
Solfleet
io.github.sanjeevkkansalPublished by GitHub account sanjeevkkansalv0.1.1Updated Oct 24, 2026
Agent-safe fleet management for independent Solana validators and RPC nodes
Overview
Solfleet is a local MCP server for managing Solana validator and RPC node fleets: Solana-aware health status, gated in-place upgrades, restarts and DNS failover
- What you can do
- Read fleet health: status, node detail, version drift, vote status, leader schedule, validation and audit log entries, with slot-lag and delinquency checks rather than plain HTTP health. Plan and run node changes: bootstrap a build host, provision nodes, restart and upgrade in place, dry-run by default and executed only with confirm=true. Manage DNS failover pools: check pool status, eject failing members and restore recovered ones, never emptying a pool. Review the SQLite audit log of every dry-run and executed operation.
- When to use it
- For operators of independent Solana validators or RPC nodes across devnet, testnet and mainnet who want an assistant to inspect fleet health, plan upgrades and restarts, and drive DNS failover under a policy gate.
- Requirements
- Runs locally over stdio as a Python package (installed with pipx or uvx). Needs a fleet config file describing nodes, optional policy file, SSH/scp access to nodes and a build host, JSON-RPC reachability to nodes and a reference RPC, and DNS provider credentials for Cloudflare or Route53 failover.
Installation
In SourceWeft
- Open Solfleet in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
solfleet
Agent-safe fleet management for independent Solana validators and RPC nodes. One config file describes your fleet across devnet, testnet, and mainnet. An MCP server (and a CLI) exposes Solana-aware status, safe in-place upgrades, and health-driven DNS failover to Claude or any MCP client. Every operation that changes a node is dry-run by default, policy-gated, and audited. solfleet never reads or moves your keypairs.
See PLAN.md for the roadmap and design notes.
Architecture
solfleet runs on the operator's machine (or a small VM). It talks to the fleet over JSON-RPC (read) and SSH/scp (act), builds artifacts on a separate build host, computes slot lag against each cluster's reference RPC, and manages failover records at the DNS provider. Every mutation flows through one gate and is written to a SQLite audit log.
How an in-place upgrade runs
How failover runs
Why
- Solana-aware health. A generic health check sees HTTP 200; a Solana node can be 500 slots behind and still return 200. solfleet checks slot lag against the cluster, delinquency, and version drift.
- Build-and-distribute. Agave v3.0 dropped prebuilt validator
binaries, so every operator now has to build from source. solfleet
builds once on a dedicated builder node (with the ABI-matched
Yellowstone geyser
.so), caches it, and distributes the artifact set to the fleet. - Leader-aware restarts. Restarting a voting validator during its own leader slots skips blocks. solfleet restarts validators via a leader-aware safe-exit; RPC nodes cycle via systemctl.
- Safe failover. The watch loop pulls lagging/unhealthy nodes out of DNS and restores them on recovery, and refuses to ever empty a pool.
Status
v1. Built and unit-tested (91 tests, CI on Python 3.11-3.13). Most paths are also proven live against a disposable devnet node and a real Cloudflare zone.
Proven live:
- read path:
status,validate,vote-status,inspect restart(RPC via systemctl; validator via leader-aware safe-exit)- in-place
upgradeend to end (build agave from source on a builder, distribute, sha256-verify on the target, atomic swap, catch-up) for both RPC and voting-validator nodes bootstrap-builder(toolchain + deps on a bare builder)provisiona voting validator from bare disks (format NVMe, install, render the voting unit, start, catch up, vote)- DNS driver plus
dns status/eject/restoreand last-member protection, against a live Cloudflare zone
Unit-tested but not yet run live:
- the autonomous
watchloop (probe -> decide -> act); its decision logic is unit-tested and it reuses the now-proven Cloudflare driver - the Route53 driver (no AWS zone to point at yet)
Not built yet: HTTP transport (MCP is stdio-only today). See PLAN.md (M6).
Install
Quick start
MCP (Claude Code):
Example session
Pointed at a small devnet fleet. With no flags, commands are read-only or dry-run.
Fleet health is Solana-aware, not just an HTTP 200:
An upgrade is dry-run by default. It returns the ordered plan and the gate
decision and changes nothing until you pass --confirm:
Over MCP, the same operations are tools (fleet_status, plan_node_upgrade,
upgrade, ...). Claude gets that same plan back and has to pass confirm=true
to execute, so an agent cannot mutate a node by accident.
Tools
Read-only: fleet_status, node_detail, version_drift, vote_status,
leader_schedule, validate, plan_node_upgrade, dns_pool_status,
audit_log.
Gated (dry-run by default; confirm=true to execute):
bootstrap_builder_host, provision, restart, upgrade,
dns_pool_eject, dns_pool_restore.
Every mutation is dry-run by default, checked against policy.yaml
(allowed versions, disk floor, leader-window minimum), and written to a
SQLite audit log. The watch loop is the one autonomous mutator; it is
bounded by the same audit log and the never-empty-a-pool rule.
Safety model
- Dry-run by default. Mutations return their ordered plan and
preflight unless called with
confirm=true. - Policy gate. Per-cluster
policy.yaml: allowed version globs, disk floor, andrequire_leader_window_minutesfor validators. - Checksum-verified distribution. Upgrade artifacts are sha256-checked on the target against the builder before any swap.
- No keys, ever. solfleet does not read, move, or generate identity/vote keypairs. Voting-validator identity failover is out of scope by design (double-signing risk).
- Audit log. Every dry-run and execute is recorded in SQLite.
Development
MCP registry
Published to the MCP Registry.
mcp-name: io.github.sanjeevkkansal/solfleet
Source: README.md at commit 4fb5c9e
Tools
0Version history
1- v0.1.1LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts