Skip to content
MangoDock

  • 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

    • Advanced

    Deadlines and limits

    A stack that removes itself at a set time, and ceilings on what a stack may consume.

    Deploy for a while

    A stack can be given an expiry — a timestamp, after which it is taken down. A review app for a branch, a demo for an afternoon, a test rig for the length of a run.

    It is not a scheduled job. The scheduler is entirely cron-based, and expressing “three hours from now” as cron means writing a literal minute and hour and then deleting the schedule after it fires — a one-shot pretending to be a recurrence, which leaves behind a row that looks like a broken schedule if the delete is ever missed. An expiry is its own small thing: a timestamp and a reaper, running on the scheduler's existing twenty-second tick.

    Resource limits per stack

    A stack can be capped on CPU and memory. The cap survives redeployment, which is the part that takes some doing.

    Changing limits on a running container is easy and useless on its own: the next compose up recreates the container from the file and the limits are gone. Making them stick means the limits have to be in what compose reads.

    Your compose file is never edited

    The alternative was to write deploy.resources.limits into the file you wrote. A round-trip through a YAML library reformats the file and drops every comment, which is not an acceptable thing to do to a file you keep in git. Instead MangoDock writes a compose override file and passes it as a second -f, and compose does the merge itself with its own documented semantics. The override is regenerated rather than read back, so it is never a second source of truth.

    Two things the engine imposes

    • Lifting a limit is not something the running-container update path can do, so a change that removes a ceiling takes effect on redeploy rather than instantly.
    • CPU is expressed one way or the other depending on the engine, never both — the two forms are mutually exclusive, and MangoDock picks the one the daemon in front of it accepts.

    Air-gapped

    • Both are local bookkeeping against a local daemon. Neither needs a network.
    ← GitOpsPodman →