Skip to content
MangoFly

  • 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.

    ExploreDocsPricing
    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.

    ExploreDocsPricing
    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.

    ExploreDocsPricing
    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

    • When it doesn't work

    Start with the symptom.

    Everything is offline and the app can't reach the server

    The coordination server is down or unreachable. Existing connections keep working; nothing new can be set up. If it persists, tell whoever runs it.

    One peer shows "No direct path"

    You are reaching it through the relay: it works, but every packet takes a detour. Usually one of the two networks blocks direct connections, and carrier-grade NAT on mobile networks is the common cause. Worth trying: either device on a different network, or a wired connection rather than a phone hotspot.

    One peer shows "Unreachable"

    1. Is it actually on? Its owner sees the same Peers list you do.
    2. Are you allowed to reach it? Access is by group. Seeing a device does not always mean being allowed to reach it.
    3. Ping it from the Peers page. A reply means the path works and the problem is the service you are trying to use, not the mesh.

    Large transfers stall, small ones work

    A shell connects and freezes on long output. A page loads its text and hangs on an image. This is almost always MTU: some link in the path cannot carry packets as large as the tunnel is sending, and drops them without saying so. Settings › Network › Tunnel MTU, try 1280. It takes effect on the next connect, and PPPoE lines and some mobile networks need it.

    It worked yesterday

    Something moved — a router rebooted, an address changed, a laptop went to a different network. Disconnect and reconnect on either side is enough in most cases.

    I can reach the machine but not the thing behind it

    You have access to the device but not to its Resources, or Enable Client Routes is off on your side. Check that setting first, then ask what your group is allowed to reach.

    Collecting information for somebody else: Settings › Troubleshoot has Copy Diagnostic Info and the log file path. The log is plain text, and the lines that matter usually start ice: (finding a path to a peer) or relay: (giving up on a direct one).

    ← Settings that matterInstall the server →