IRONMESH
v0.9.4.1 · Pre-1.0

Your agents. Your network.
Your rules.

Zero-config, end-to-end encrypted agent-to-agent communication that never leaves your local network. No cloud. No internet. No compromises.

View on GitHub Get Started
pip install ironmesh Click to copy
MIT licensed · zero telemetry · no signup · offline-capable
Where it fits

IronMesh is a layer, not a competitor.

It sits under the agent frameworks and protocols you already use — giving them a transport that survives a router reboot, a dead ISP, or no internet at all.

Your application
Agent frameworks — LangChain · CrewAI · AutoGen
adapters ship with IronMesh
Tool / context protocols — MCP · A2A
IronMesh — identity · encryption · routing · queue
this project
Transport — WebSocket over LAN · Reticulum / LoRa
Doesn't MCP already do this?
MCP connects agents to tools. IronMesh connects agents to each other. They compose.
What about LangGraph / CrewAI?
They orchestrate agent logic. IronMesh carries the messages between machines. They compose.
Isn't Tailscale / WireGuard enough?
Those give you an encrypted tunnel. IronMesh adds identity pinning, capability discovery, offline queueing, and an agent-aware routing table on top.
Why not use Reticulum directly?
Reticulum is a great low-level mesh; IronMesh uses it as one of its transports. We add per-agent identity, capability discovery, and an authenticated handshake on top.
Where to start

Three ways to run IronMesh.

Pick the one that matches what you're building. Each opens a fast-path into the docs.

Homelab operator

Private AI on your LAN

Run Ollama on a Pi, a coding agent on your desktop, a browsing agent on a spare laptop. They find each other, talk, and nothing leaves the house. mDNS + encrypted SQLite queue + dashboard at 127.0.0.1:8765.

→ Getting Started  › or try in Codespaces  ›
Offline / LoRa builder

Agents over radio, no internet

Reticulum transport rides on top of LoRa hardware (Heltec V3, RNode). Sub-kbps raw, but IronMesh handles fragmentation, retry, and routing. Useful for remote fieldwork, off-grid nodes, disaster comms.

→ LoRa + Reticulum guide  ›
Agent-framework integrator

Drop into LangChain / AutoGen

Python Agent(...) SDK + 25 MCP tools + TypeScript client. Stock LangChain / AutoGen adapters already shipped. Your agents gain TOFU-pinned peer-to-peer messaging without changing their prompt logic.

→ SDK reference  › docker pull wiztheagent/ironmesh:0.9.4.1
Release activity
Checking github.com…
The Problem

Every agent protocol assumes you're online.

We looked for a way to make AI agents talk to each other on a local network. There was nothing.

Google A2A

× Requires HTTPS and internet. Your agents go silent when the cloud goes down.

Anthropic MCP

× Solves agent-to-tool, not agent-to-agent. IronMesh fills that gap — the two stack together.

ACP

× Local IPC only. Can't cross machines on your LAN.

ANP

× Decentralized but complex DID setup, still assumes internet connectivity.

0
Cloud dependencies
1068
Passing tests
16
Releases · no breaking changes
—
GitHub stars
How IronMesh compares

If you need the internet to be optional.

Two axes matter for this decision: offline-first (can your agents keep running without the cloud?) and mesh-shape (can they reach each other without a broker?). Pick the axis that matches your deployment.

Feature IronMesh Google A2A Anthropic MCP ACP ANP
Works offline / no internetYesNoN/AYesNo
True peer-to-peerYesNoNoNoYes
Zero-config LAN discoveryYesNoNoNoNo
End-to-end encryptionNaClTLS onlyN/ANoYes
Forward secrecyYesDependsN/ANoNo
Multi-hop mesh routingYesNoNoNoNo
Capability discoveryYesNoNoNoNo
LoRa / radio transportYesNoNoNoNo
Self-hosted, no vendor lockYesNoNoNoPartial
Survives internet outageYesNoN/AYesNo
Feature IronMesh Reticulum libp2p NATS JetStream
Target use caseAgent-to-agent messagingRadio / off-grid commsp2p app networkingCloud-native pub-sub
Zero-config LAN discoveryYes (mDNS)Yes (announce)Manual / rendezvousRequires broker
Runs without a brokerYesYesYesNo (broker required)
Agent-level capability discoveryYes (cap-hash bound)NoNoNo
TOFU identity pinningYesIdentity hash onlyPeer ID, not pinnedNo
Built-in MCP / A2A surfaceYes (25 MCP tools)NoNoNo
LoRa / sub-kbps transportYes (via Reticulum)NativeNoNo
Encrypted offline message queueYes (SQLite + XSalsa20)LXMFPartial (streams)Yes (at-rest in broker)
Python-first SDKYesYesGo-first, Python bindings lagYes
Runs on Termux / AndroidYesYesNoNo
Under the hood

Security isn't a feature. It's the architecture.

NaCl / libsodium crypto — the same library as Signal and WireGuard. Not homebrew. Not "encrypt later." Not "TLS is enough."

🔒

Forward Secrecy

Ephemeral X25519 keys per session, destroyed after handshake. Compromising today's keys can't decrypt yesterday's traffic.

🔍

Zero-Config Discovery

mDNS auto-discovers agents on your LAN. No manual IP config. Identity keys only exchanged during authenticated handshake.

🛡

Mutual Authentication

HMAC-SHA256 passphrase proof. Both client and server prove identity. Ed25519 signatures on every single frame.

🌐

Multi-Hop Mesh

Distance-vector routing with split horizon and poisoned reverse. Messages traverse intermediate peers automatically.

📡

LoRa / Reticulum

Optional transport over LoRa radio at 915 MHz via Reticulum. No internet at all. Just RNode hardware and open spectrum.

⚡

Offline Queue

Messages queued in encrypted SQLite when peers are offline. Automatically delivered on reconnect. Priority ordering built in.

Sixty seconds, start to finish

Install, run, first encrypted message.

No account. No config file. Every line of output below is from a real run on a stock Python install — play / pause to watch it at your own pace.

bash — ironmesh quickstart
What it looks like

Three peers talking. Zero cloud.

The operator console — embedded in every node, reachable at http://127.0.0.1:8766 with a per-session bearer token. The same handshake diagram from the spec, lit live for the selected peer. Encrypted A2A dialogue turn-by-turn in the feed. CSP-locked to same-origin so the page renders with the router unplugged.

Live capture: laptop (Windows) ↔ Raspberry Pi 5 (Ollama) ↔ NAS (Ollama hermes3:3b). A2A dialogue: three turns, ended on goal-achieved.

New in v0.9.4.1

Pre-audit hardening + Ed25519/X25519 dual-use migration + signed capability advertisements.

v0.9.4.1 is a single-fix patch on v0.9.4 — closing a Windows + CPython 3.13-only race in migrate_keys_to_master_seed that the v0.9.4 CI matrix surfaced. Wire-byte-identical to v0.9.4, drop-in upgrade, no operator action required. The headline feature set below ships with both releases.

v0.9.4 itself is a combined release: the originally-planned v0.9.3 security point release (strict TLS, trust-store at-rest encryption, global rate cap, trust CLI) ships alongside a substantial pre-audit hardening pass. Phases 1 and 2 of the Ed25519/X25519 dual-use migration land together — the v3 master-seed keystore + the HELLO x25519_public_b64 advertisement with an Ed25519 binding signature. Signed CAPABILITY_ANNOUNCE closes the relay-impersonation gap. Frame-length ceiling, JSON depth guard, replay upper bound, CVE-2020-10735 mitigation, narrowed exception handling, fail-closed TOFU. Wire format unchanged at ironmesh/0.8 — every v0.8.x and v0.9.x peer remains interoperable; the new HELLO fields are additive. 1068 tests green on the v0.9.4.1 matrix. Full notes: v0.9.4.1 release notes · v0.9.4 release notes.

🗝

Master-seed keystore (Phase 1)

v3 keys.json envelope tagged format: "master-seed-v1" carries the existing Ed25519 seed byte-for-byte plus a 32-byte HKDF-derived x25519_seed and 16-byte hkdf_salt. Every existing TOFU pin remains valid because the Ed25519 public is unchanged. Load-time integrity check: the stored X25519 subkey MUST re-derive from HKDF(ed25519_secret, hkdf_salt, INFO_X25519) — tampering with the encrypted subkey is detected even when the operator's passphrase decrypts the envelope.

📡

HELLO X25519 advertisement (Phase 2)

HELLO optionally carries x25519_public_b64 + x25519_binding_signature_b64 — an Ed25519 signature over the X25519 public under SIG_CTX_X25519_BINDING. Receivers verify the binding against the peer's pinned Ed25519 identity and switch E2E SealedBox sealing to the advertised X25519. Both fields sit OUTSIDE the signed HELLO canonical body so pre-v0.9.4 receivers verify the HELLO signature identically. Mixed-mesh interop preserved via legacy ed25519_to_curve25519 fallback. Auto-migration runs on first start.

🦾

Signed CAPABILITY_ANNOUNCE

Announces whose origin differs from the delivering peer require an inner Ed25519 signature from origin under SIG_CTX_CAPABILITY_ANNOUNCE. Closes the prior relay-impersonation gap where a malicious relay could poison a third party's pinned cap-set baseline. 300 s freshness window (configurable via capability_announce_max_age) plus a per-(origin, announced_at) replay-dedup LRU. New audit event CAPABILITY_ANNOUNCE_BAD_SIG with reason field (missing-sig / unknown-origin / stale / bad-sig).

🔒

Trust store encrypted at rest

known_peers.json is now a SecretBox-encrypted v2 envelope. The on-disk file no longer contains plaintext fingerprints, pubkeys, or capability sets — a host-disk leak no longer exposes the peer graph. HMAC-SHA256 over the ciphertext keeps tamper evidence. Pre-existing v1 plaintext stores migrate forward on next save with zero operator action; ironmesh trust migrate forces it immediately.

🛡

--strict-tls + --max-msgs-per-sec

Opt-in --strict-tls + --pinned-ca require a CA-validated cert on outbound WSS for deployments where real certs are available. Default mode unchanged (TOFU at the application layer). Global daemon-wide --max-msgs-per-sec cap on top of the existing per-peer limiter — defense-in-depth for hostile-peer exposure.

📋

Trust + keys CLI surfaces

Four new ironmesh trust subcommands: verify, migrate, export, pin — covering the out-of-band trust workflow. Plus ironmesh keys fingerprint for read-aloud / side-channel paste-in, and ironmesh keys migrate to convert legacy keystores to the v3 master-seed format. ironmesh doctor 8th check surfaces the on-disk envelope version.

📊

Frame ceiling, JSON depth, replay bound

MAX_FRAME_BYTES = 1 MiB enforced before the buffer slice in Frame.deserialize_and_decrypt — defeats a 4 GiB attacker-declared length. MAX_JSON_DEPTH = 64 on inbound JSON parsed from the wire. ReplayGuard.MAX_SEQUENCE = 2^48 defeats the self-DoS edge case. sys.set_int_max_str_digits(4300) at bridge boot covers CVE-2020-10735 across Python 3.10 / 3.11 / 3.12 / 3.13.

🚧

Exception narrowing + fail-closed TOFU

Narrowed bare except Exception across the signing path, frame parsing, and 12 best-effort rate-limit / shutdown / cleanup blocks in bridge.py. Each call site documents its accepted failure-mode set; programmer errors propagate instead of being silently dropped. Fail-closed TOFU: a peer whose identity cannot be evaluated is refused with a WARNING log, replacing the prior silent-pass behaviour.

Previously, in v0.9.2

1.0 prep mega-release. Conformance, OTel, capability-aware routing, handshake skip on identified Links.

v0.9.2 was the largest pre-1.0 ship: a wire-stable feature-flag system, a server-driven Stage-1 skip path on identified Reticulum Links (three round-trips saved on LoRa), shared-secret group broadcast for cross-host fan-out, capability-aware routing (Agent.send_to_capability(...)), OpenTelemetry spans on every public Agent surface, a formal threat model and conformance test suite, and the v1.0 stability promise. Wire format moved to ironmesh/0.8 with additive-only fields — every v0.8.x peer continues to interoperate. Full write-up: v0.9.2 release notes.

🏴

Wire-stable feature flags

Announce app_data gained an f field carrying a known vocabulary (mesh, resource, lxmf, hskip, group). New flags may be added; existing ones are permanent. The receiver's flag check is a 2-byte SetIntersection — cheap, deterministic, and stable across language ports.

⚡

Stage-1 skip on identified RNS Links

When both peers advertise hskip on an established RNS.Link, the server emits SKIP_OFFER in place of the passphrase challenge and both sides substitute a fixed channel-binding sentinel. Three round-trips and ~750 ms of LoRa airtime saved per fresh handshake. Server-driven negotiation prevents the asymmetric-decision race that bites unilateral schemes. Three Prometheus counters surface offer / activate / reject rates per side.

📢

Shared-secret group broadcast

When peers opt in (group flag + same passphrase), each derives the same symmetric group key via HKDF and listens on a deterministic group destination. A single broadcast packet reaches every member — no N-way send loop. Receiver-side dedup via msg_id keeps fan-out idempotent.

🚦

Capability-aware routing

Agent.send_to_capability("llm:llama3", payload) picks the best-known peer advertising the cap and dispatches via the unified transport selector. Counters surface attempts vs. successes vs. no-match, so operators see whether the cap topology is converging. Survives cold restart via the persisted capability registry.

🔎

OpenTelemetry spans on every public surface

Optional install via pip install ironmesh[otel]. Spans on handshake, message dispatch, MCP tool surface, and the v0.9.x agent-interop surfaces. Configure via standard OTEL_EXPORTER_OTLP_* env vars. With the extra absent, every emit is a no-op — zero overhead.

📜

Formal threat model + conformance suite

STRIDE-organized threat model in docs/THREAT_MODEL.md: 14 assets, per-asset mitigations, residual risks called out. Conformance test skeleton in tests/conformance/ with the first golden vectors — the basis of v1.0 cross-language compliance. Plus the v1.0 stability promise itself (STABILITY_PROMISE.md): what we commit to keeping stable from v1.0 forward, and the deprecation procedure.

🎯

892 tests · v0.9.2 baseline

v0.9.2 shipped at 892 tests collected on Ubuntu + Windows + macOS across Python 3.10 – 3.13. Live cross-host validation on every new wire surface (skip-handshake, group-broadcast, capability-aware routing). The conformance suite picks up most of the new tests; release-qc enforces the doc-sync contract.

💾

Wire format ironmesh/0.8

Additive fields only; existing field semantics frozen. Pre-v0.9.2 peers continue to handshake and exchange messages identically — the new fields are silently ignored on the receive side. Documented in PROTOCOL_SPEC.md with full negotiation semantics.

Under the Hood

The handshake.

Mutual passphrase auth, signed ephemeral ECDH, channel binding. Three stages. Zero trust assumptions. The same diagram renders live inside the operator console — click any peer row and watch the stages go green in real time.

Client Server STAGE 1 · MUTUAL PASSPHRASE AUTH PASSPHRASE_CHALLENGE · 32-byte server nonce HMAC-SHA256(pass, nonce) STAGE 2 · SIGNED EPHEMERAL ECDH (X25519) + CHANNEL BINDING HELLO {eph_pub_A, id_pub_A, server_nonce} Ed25519-signed(canonical payload) HELLO {eph_pub_B, id_pub_B, server_nonce} STAGE 3 · SHARED SECRET + AUTHENTICATED SECRETBOX FRAMES ECDH(eph_priv_A, eph_pub_B) ECDH(eph_priv_B, eph_pub_A) = shared_secret (eph_priv_A wiped) (eph_priv_B wiped) SecretBox(XSalsa20-Poly1305) + Ed25519 on every frame
Click any stage to see the exact wire payload and libsodium primitives.
Deployment shape

What three machines actually look like.

Zoomed out from the handshake. This is a typical IronMesh deployment — one laptop, one Raspberry Pi, one off-grid LoRa node. Each machine runs the same daemon; the transports between them differ. mDNS on the LAN, Reticulum over radio to the off-grid node.

NODE · LAPTOP wiz • ironmesh run • Claude Code + MCP • dashboard :8766 • identity: a4d1f397… Windows 11 · Python 3.13 NODE · RASPBERRY PI kingpi • ironmesh run • Ollama · llama3:8b • LangChain adapter • identity: 60a9cca1… Raspbian · LAN only NODE · OFF-GRID fieldpi • ironmesh run • Reticulum + RNode • Heltec V3 · 915 MHz • identity: 7f1a2c88… Pi Zero 2 W · solar WebSocket mDNS · LAN SecretBox + Ed25519 Reticulum over LoRa radio 915 MHz · SF8/BW125 WHAT EVERY NODE RUNS • Ed25519 identity keypair (first run) • mDNS / Reticulum announce loop • Encrypted SQLite queue for offline peers • HMAC-chained audit log • Distance-vector mesh router • X25519 ECDH + forward-secrecy rekey • TOFU pin + capability-set binding • Dashboard on localhost (session token)
WebSocket over LAN Reticulum / LoRa over radio
What it costs

Real numbers from the v0.9.4.1 release gate.

Every number below comes from the release-hardening test suite. No projections, no “up to” claims. Runs fine on a Raspberry Pi Zero 2 W with 512 MB RAM.

Idle RSS ~50 MB Steady state with three peers connected + dashboard running. Grew just 3.1 MB over a 44-minute soak with zero operator activity.
Handshake latency < 50 ms Client-to-server mutual-passphrase + signed-ephemeral-ECDH + channel binding, LAN, end-to-end.
Concurrent operator stress 2000 thr 2000 concurrent cap-promote calls across 20 peers completed in 2.7 seconds. Exactly one winner per peer. Zero MAC corruption.
Protocol fuzz 5 000 Random and corrupted binary frames fed through the deserializer. Zero unhandled exceptions — only the documented ValueError / CryptoError paths fire.
Audit log write ~1 ms Single-entry append under cross-process flock + fsync. HMAC-chain verification of 7000-entry log completes under 200 ms.
Test coverage 1068 Unit tests green across Ubuntu + Windows + macOS on Python 3.10 / 3.11 / 3.12 / 3.13. Excludes live-mesh integration tests.
LoRa payload headroom 128 B Default payload limit on Reticulum / LoRa transport. Above that, automatic fragmentation + reassembly via the offline queue.
Wheel size 267 kB Pure-Python wheel with 24 public modules. Sdist is 371 kB. No C extensions — crypto comes from the PyNaCl wheel.
Reproducibility: all benchmark scripts live in tests/ and scripts/ on the public repo. The 2000-thread stress is the last block of tests/test_trust_binding.py::TestConcurrentCapPromoteRace; the 5000-input fuzz is reproduced by scripts/release-smoke.sh.
Common questions

Objections, answered directly.

Before you install, the eight questions evaluators actually ask.

Is this a toy, or is it real?
Real. Shipped on PyPI + Docker Hub + GitHub since April 2026, ten releases on a patch-level-backwards-compatible v0.8.x line, 1068 tests green across three operating systems and four Python versions. Runs on a live three-node production mesh (laptop + Pi + NAS) used daily. Source is MIT-licensed on GitHub; read the code before trusting it.
Does it phone home? What does it send out of my network?
Zero cloud dependencies. The daemon only speaks to (1) peers it discovers via mDNS on the same LAN, (2) peers you explicitly configured, or (3) peers reachable via the Reticulum / LoRa transport you opted into. No telemetry, no analytics, no license server. ironmesh upgrade optionally checks PyPI for new releases; that's the only public-internet call in the whole codebase and it's off by default.
Can I run it behind CGNAT / a restrictive firewall?
On a LAN, yes — everything happens inside your subnet. For cross-site or WAN deployments, IronMesh currently assumes reachable peers (Tailscale, WireGuard, or a VPN underneath). A NAT-traversal design doc exists in the repo; shipping that work is queued for a later release but isn't in v0.8.x.
What does it cost me on a Pi Zero / low-end hardware?
~50 MB RSS at idle with three peers. +3.1 MB RSS drift over a 44-minute soak. Handshake under 50 ms on LAN. SQLite offline queue is encrypted at rest but the schema is lean — a few thousand queued messages is a couple hundred kB. You'll run into Ollama's memory floor long before IronMesh's.
How is this different from MCP?
MCP connects agents to tools (filesystem, database, API). IronMesh connects agents to each other. They compose: IronMesh ships a 25-tool MCP server so Claude Desktop / Claude Code can control a running mesh (list peers, promote pending trust, send messages, inspect audit log). Using MCP doesn't replace IronMesh and vice versa.
Why not just use Tailscale or WireGuard?
Those give you an encrypted tunnel between hosts. IronMesh gives you per-agent identity, TOFU key pinning, capability discovery, a pending-trust message gate, an HMAC-chained audit log, and an offline message queue — built on top of whatever tunnel you want, or none at all. They compose too: run IronMesh inside a Tailnet and you get both layers.
What's actually encrypted, and with what?
Every post-handshake frame is NaCl SecretBox (XSalsa20-Poly1305) under a session key derived from fresh X25519 ECDH, signed with an Ed25519 detached signature. Identity keys live in keys.json, Argon2id-wrapped at rest, optionally held in the OS keychain. Full threat model at /security.html.
How do I contribute? Where do I report a bug?
Bugs and feature requests go to GitHub Issues. Security reports go to info@ironmesh.org — please don't open a public issue for the initial report. PRs welcome; CONTRIBUTING.md on the repo covers the style + test + leak-scan requirements.
Release history

Three months. Fifteen releases. No breaking changes.

Patch-level discipline: every v0.8.x peer stays interoperable, and the v0.9.x line keeps the same wire protocol (ironmesh/0.8 since v0.9.2, additive-only thereafter). Scroll through what each drop brought.

CURRENT
v0.9.4.1
May 2026
Windows py3.13 concurrent-migration race fix
Single-fix patch on v0.9.4. migrate_keys_to_master_seed now surfaces the documented "already in master-seed format" ValueError on the loser of a Windows + CPython 3.13 race instead of leaking a PermissionError from os.replace. Wire-byte-identical to v0.9.4, drop-in upgrade.
v0.9.4
May 2026
Pre-audit hardening + dual-use migration + signed CAPABILITY_ANNOUNCE
Combined release: originally-planned v0.9.3 security hardening (trust-store at-rest encryption, --strict-tls, --max-msgs-per-sec, trust CLI) shipped alongside Ed25519/X25519 dual-use migration phases 1 + 2, signed CAPABILITY_ANNOUNCE, frame-length ceiling, JSON depth guard, replay upper bound, CVE-2020-10735 mitigation, narrowed exceptions, fail-closed TOFU. Wire format additive only.
v0.9.2
Apr 2026
1.0 prep mega-release
Wire-stable feature flags, Stage-1 skip on identified RNS Links, shared-secret group broadcast, capability-aware routing, OpenTelemetry spans, formal threat model + conformance suite + v1.0 stability promise. Wire format moved to ironmesh/0.8 (additive only).
v0.9.1
Apr 2026
Reticulum integration sweep
RNS announce-driven auto-discovery, per-packet ratchets, RNS Resource auto-routing for multi-MB payloads, unified Agent.send_to(name), LXMF listener + telemetry, public RPC paths (/im/info, /im/cap/*, /im/admin/*).
v0.9.0
Apr 2026
OpenClaw, ACP, A2A interop
OpenClaw channel plugin (@wiztheagent/openclaw-ironmesh@0.2.0), ironmesh-acp stdio adapter (acp-core-v1@0.3.0), ironmesh-a2a HTTP gateway (AgentCard + JSON-RPC + envelope inbox). Capability-persistence fix, multi-peer routing, MCP --peer manual bootstrap.
v0.8.5.8
Apr 2026
Counter correctness + observability polish
Counter continuity across daemon restart (reconciled from audit-log tail), structured _emit_audit_with_reservation helper, audit-chain verify on startup, two new Grafana panels, OPERATOR_RUNBOOK trust-store recovery section, [lxmf] install extra.
v0.8.5.7
Apr 2026
Cap-binding, end-to-end
Dashboard PENDING CAP CHANGE panel, nine new Prometheus counters + OpenTelemetry spans, five new operator CLI subcommands, two new MCP tools (cap_diff + cap_reject_peer).
v0.8.5.6
Apr 2026
Trust-binding + cross-transport replay
Capability-set hash binds the pending-trust state across reconnects; cross-transport replay surfaces as a dedicated audit event. 19 bugs found + fixed during release hardening.
v0.8.5.5
Apr 2026
QoL patch + Windows service
OS keychain backend, CLI named profiles, ironmesh upgrade, Windows service wrapper, OpenTelemetry tracing, TS client 0.2.0 with TOFU pin enforcement.
v0.8.5.4
Apr 2026
Repo hygiene + onboarding
Layered leak-scan, first-run ironmesh setup wizard, full contributor docs, CodeQL, Reticulum smoke tests.
v0.8.5.3
Apr 2026
Quickstart hardening + examples
Insecure-flag startup warnings, pending-trust deprecation path, conv_multiturn + persona_debate examples, release checklist enforcing doc-sync.
v0.8.5.2
Apr 2026
Operator polish + 10 security fixes
Audit-log + doctor + set-state CLI landed. Atomic trust-store writes, tamper-evident audit, full 13-job CI matrix.
v0.8.5
Apr 2026
Pending-trust gate + 21 MCP tools
Opt-in pending-trust message gate (default-on in v0.9), 21-tool MCP server, OpenClaw channel 0.1.0.
v0.8.3
Apr 2026
First production ship
PyPI + Docker Hub (wiztheagent/ironmesh:0.8.3) + GitHub release. Full multi-hop mesh, dashboard console, e2e tests.
Who It's For

Built for people who don't trust the cloud.

Home AI Mesh

Raspberry Pi running Ollama talks to your desktop coding agent. No cloud. No API keys. No third parties.

Off-Grid Comms

Agents on a network with no internet coordinate tasks, share data, and run workflows over LoRa radio.

Prepper Infrastructure

Self-contained AI network that works when the internet doesn't. Solar-powered Pi cluster. Local models.

Air-Gapped Labs

Agents in isolated environments that can never touch the internet. Full encryption at rest and in transit.

Privacy-First AI

All agent communication stays on your LAN. Nothing leaves your network. Nothing gets logged by anyone.

Multi-Device Workflows

Phone, desktop, and server agents all talk directly to each other. mDNS discovery. Zero config.

Pull the plug on your router.
IronMesh keeps working.

Local-first. Offline-capable. Mesh-ready. Zero-config. No cloud required. Ever.

Star on GitHub Read the Docs
pip install ironmesh Click to copy