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

    • Install the server

    One small VM, and the first admin.

    Setting one up for the first time? Follow Install & first run instead — it walks a fresh VM through every step in order, with the exact commands, and is the page this one summarises.

    You need one machine every device can reach; a small cloud VM is plenty. It does not carry your traffic — devices talk to each other directly — it tells them how to find each other and who may reach whom.

    The shape of it

    1. A machine with a public address, and a domain name pointing at it.
    2. Docker with the Compose plugin, and root.
    3. One command, which asks for the domain and does the rest.
    curl -fsSL https://downloads.mangossh.com/mangofly/install.sh | sudo sh

    It writes the deployment rather than cloning one — a compose file, a Caddyfile and an .env under /opt/mangofly — pulls the server, the relay and Caddy by tag, waits for the server to report healthy, and finishes by printing an admin password and a setup key. Nothing is compiled on the box, so a small VM is enough — 512 MB, most of it for Docker.

    Re-running it is how you upgrade: the relay secret and the admin account are kept, the configuration is rewritten, and the images are pulled again at whatever the tag now points at.

    Ports

    80 and 443 for the server, UDP 8788 for the NAT reflector that helps devices find each other, and 8443/8444 if you will publish Services.

    The NAT reflector needs its own firewall rule, at your cloud provider as well as on the box. The usual HTTP/HTTPS checkboxes do not cover UDP 8788, and without it devices fall back to the relay far more often than they should.

    First run

    The installer creates the first admin and a setup key for you, and prints both — the password once, to your terminal and nowhere else. Enrol your own machine first, so you have something to test with. If you ever need another key, or a second admin, the same commands are there.

    cd /opt/mangofly
sudo docker compose exec mangofly mangofly-server --create-setup-key --max-uses 10

    For the whole procedure — the DNS check before certificates can issue, the firewall rules, what MANGOFLY_DOMAIN is and what the script does with it — see Install & first run.

    ← When it doesn't workLetting devices in →