ServerBox: a Flutter client that turns your phone into a server console

What ServerBox actually replaces

Most people who rent a VPS end up with two things: an SSH client and a browser tab open on some status page. ServerBox collapses both into one Flutter application. The README describes it as "a Flutter project which provides charts to display Linux, Unix and Windows server status and tools to manage servers", and the screenshot set confirms the shape of that: a server list, a per-server details view, a terminal, a file browser, a container list, a process list, a services view, snippets, an agent screen, a benchmark screen and a globe view.

The intended user is not a platform team. It is the person who owns a handful of boxes, wants to know whether the disk is filling up, and occasionally needs to restart a container or edit a config file without opening a laptop. The repository topics (android, ios, ssh, status, vps) point the same way. If you administer fifty hosts with an on-call rotation, this is the wrong layer: it is a per-operator console, not a fleet system.

The SSH-first architecture and the Rust workspace behind it

ServerBox does not require an agent on the target host. The app connects over SSH and reads status from the machine, which is why the README credits dartssh2 and xterm.dart: those two Dart packages provide the transport and the terminal emulation. Status parsing is shared rather than duplicated. The Cargo workspace at the repository root lists crates/sbm_parser as the "shared status parser (used by both monitor and the app via FFI)", with crates/sbm_ffi as the flutter_rust_bridge binding layer plus cargokit plugin shell, and crates/sbm_native for "native (syscall/procfs) status sampling for monitor's local collection path only, never used by the SSH-based app".

That split matters when you evaluate the project. The app you install and the monitor service you can self-host share a parser but not a collection path, so a parser bug affects both, while a native sampling bug affects only the monitor. The workspace also carries a patch block for IronRDP, pinning sspi and related crates to a specific git revision, because IronRDP 0.17's dependency combination cannot coexist with russh's stable ed25519-dalek in one workspace. That is a maintenance liability the maintainers have chosen to absorb rather than a design feature, and it means building from source pulls a third_party directory into the picture.

Installing ServerBox on iOS, macOS, Android and desktop

The README gives a download table rather than a build guide, and that is the fastest route for most readers. iOS and macOS both point at App Store id1586449703, with the macOS listing marked Apple silicon only. Android is distributed through GitHub releases, a CDN, F-Droid as tech.lolli.toolbox and OpenAPK. Linux and Windows come from GitHub releases or the CDN. macOS also has a Homebrew cask:

brew install --cask server-box

After the cask installs, ServerBox appears in your Applications folder as a normal Mac app; the README notes architecture-specific .dmg files on GitHub releases if you prefer a manual download. For iOS without the App Store, the release assets include an unsigned _NoSign.ipa, and the README is explicit that you sign it yourself.

If you want to build from source instead, the Makefile is the entry point and it documents its own targets through make help. Dependency installation and a run on the default device look like this:

make deps
make run

make deps installs the Dart and Flutter dependencies, and make run launches the app on whatever device Flutter picks. To target a specific device, the Makefile documents make run-device DEVICE=<id>. Code generation is a separate step: make gen runs build_runner and gen-l10n, and make gen-proto regenerates the tombstone protobuf reader, which needs protoc installed. Platform builds go through make build PLATFORM=<android|ios|macos|linux|windows>.

Adding a host and reading the first chart

Once the app is open, the first screen is the server list. You add an entry with the SSH coordinates for the machine: host, port, and the credentials you would use from a terminal. ServerBox then connects over SSH and renders the status charts for CPU, sensors and GPU that the README lists under features. No daemon is installed on the target, which is the reason the setup is short and also the reason the app can only show what the SSH session can read.

Because the app talks SSH, whatever your sshd already enforces applies unchanged: key-based auth, non-standard ports, jump hosts. That is the practical advantage of the approach. It also means the app inherits SSH's failure modes. If the host is unreachable, if the key is passphrase-protected in a way the app cannot prompt for, or if the server is behind a bastion you have not configured, the status view is simply empty. There is no fallback polling channel.

The repository separates the app from the optional server-side component. The monitor workspace member is described as "server-side monitoring (service + web frontend)", and its release track is distinct: monitor-v0.1.3 was published on 2026-09-12, the same day as app release v1.0.1617. Treat them as two artifacts with two upgrade cadences.

Where ServerBox stops being the right tool

The honest limitation is that a client-side, SSH-driven monitor only sees what it is asked to see, when it is asked. There is no alerting path described in the README: no threshold notification, no paging integration, no retention of historical samples beyond what the app keeps. If a disk fills at 03:00 and nobody opens the app, ServerBox does not tell anyone. That is a different job from what Prometheus and Alertmanager do, and no amount of chart polish closes the gap.

The second limitation is platform coverage. The README claims Linux, Unix and Windows status, but the shared parser lives in crates/sbm_parser and the README does not enumerate which metrics each family exposes. Sensor and GPU readings in particular are the kind of data that varies wildly between a bare-metal host with lm-sensors and a container with almost no /sys access. Verify on your own hosts before assuming parity.

The third is build complexity. A Flutter app plus a Rust workspace plus a cargokit plugin plus a patched third_party tree for IronRDP is a lot of moving parts for contributors. The Makefile exposes gen-build-clean to clear the build cache before running build_runner, which suggests the maintainers expect stale-generation problems often enough to give them a target.

ServerBox compared with a terminal-only workflow

The obvious alternative is the SSH client you already use, plus htop and df over the wire. The difference is not capability, it is latency and shape. A terminal gives you exact output and full command coverage; ServerBox gives you a rendered chart the moment you open the app, and a file browser and container list that do not require remembering docker ps flags. If your work is mostly running commands, the terminal wins. If your work is mostly looking, ServerBox saves the round trip.

The other comparison worth making is against a self-hosted dashboard such as the monitor component in this same repository. That runs as a service with a web frontend and collects status locally through crates/sbm_native, so it can keep sampling when no client is connected. ServerBox on your phone cannot. The two are complementary, and the shared sbm_parser crate is what keeps their readings consistent.

Licence, upgrades and what the release cadence implies

ServerBox is AGPL-3.0. The practical consequence for most readers is that running the app against your own servers is unaffected, but if you fork it, modify it and let others interact with it over a network, the AGPL's network clause is the part to read. This is a description of the licence, not legal advice; if you plan to redistribute a modified build, have someone qualified look at it.

The upgrade story is app-store shaped. iOS and macOS users get updates through the App Store, Android users through whichever channel they installed from (GitHub releases, CDN, F-Droid or OpenAPK), and desktop users through GitHub releases, the CDN or the Homebrew cask. Mixing channels is how you end up on an old build without noticing. The release history shows a fast cadence: v1.0.1574 on 2026-09-06, then v1.0.1617 and monitor-v0.1.3 both on 2026-09-12. The last push to the repository was on 2026-09-21. Nothing about that cadence is a quality guarantee, but it does mean pinning a version and reading the release notes before upgrading is cheaper than debugging a regression on a phone.

Editorial conclusion

Adopt ServerBox if you already reach your hosts over SSH and want charts, a terminal and file management in one app on iOS, Android, macOS, Linux or Windows. Skip it if you need agent-based alerting, long-term metric retention or a browser dashboard for a whole team: the app is a client, and the monitor component is a separate Rust service with its own release track (monitor-v0.1.3). Before rolling it out, confirm which hosts your status parser covers and check the AGPL-3.0 obligations if you plan to redistribute a modified build.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. lollipopkit/flutter_server_box on GitHub
3. Project website
4. README
5. Releases