Skip to content
  • MangoFly

    A self-hosted WireGuard mesh. Devices connect straight to each other; the coordination server is one binary and a SQLite file, and never sees their traffic.

    encrypted WireGuard · peer to peerLaptopbehind home NATServerin a datacentrePhoneon mobile datacoordination serverone binary · one SQLite filecontrol plane only (TLS)keys · tunnel addresses · peer lists · sealed ICE candidatesholds no private keys · carries no traffic · cannot decryptdatacontrol
  • MangoDock

    Docker management with nothing on the hosts. Reaches each daemon over an ordinary SSH session — no agent to install, no port to open.

    The MangoDock dashboard showing three host cards with container state counts, CPU and memory gauges, a usage history and recent events
  • MangoWiFi

    A Wi-Fi 6/7/8 test bench. One binary runs as Console or Agent either side of the access point under test, measuring latency under real load.

    AP under testWi-Fi 6 / 6E / 7Agentstation side · real radioLAN receiveriperf3 -sConsoleUI · orchestrates · probes
  • Blog
  • Nothing phones home

    No telemetry, no analytics, no crash reporter, no account login. Check it with a packet capture on your own network.

    Download MangoSSH
  • Project
  • Download
  • MangoFly

    MangoFly documentation

    A self-hosted WireGuard mesh. These pages cover how the mesh is shaped, what the server needs, how to stand one up, how access is controlled, and what to do when it misbehaves.

    • Peers talk directly. The coordination server holds no private keys and carries no traffic.
    • The server is one binary and a SQLite file, using a few megabytes — a 512 MB VM is enough, most of that for Docker.
    • It runs fully disconnected, with operator-supplied TLS and no public STUN.
    • The project publishes its own limitations; the status page here repeats them rather than summarising them away.