Solsynth/MaidKit: a Flutter SSH server manager that installs nothing on the server

What MaidKit is for, and who ends up using it

The README describes MaidKit as "a collection of tools used by LittleSheep when acting as a 'maid' for servers (i.e., performing server maintenance)". That framing matters. This is not a hosting panel and not an orchestration system. It is a client that assumes you already have SSH access and want the routine work (restart a unit, edit a Caddy file, move a file, watch load) to happen in one window instead of five terminal tabs.

The stated goal is non-intrusive maintenance: "day-to-day management is 100% SSH-based, installing nothing on the server." For anyone who has inherited a fleet of machines they do not control, that constraint is the whole pitch. You do not need a package installed on the target, a port opened, or a change window to get a dashboard.

The audience is narrower than "developers" suggests. It is people who hold credentials to more than a handful of machines and who are comfortable with SSH as the transport. A single-server hobbyist gets less out of it, because the value shows up in the multi-server views: the grid of server cards, pinned runtimes and watched processes across hosts, and snippets executed against several connected servers at once.

How the SSH-first design actually works

MaidKit is a Flutter application, so the same codebase targets desktop and mobile. The repository layout matches that: android/, ios/, linux/, macos/, web/ and windows/ directories sit alongside lib/, with pubspec.yaml and pubspec.lock at the top level. The README says the desktop approach is inspired by the Island project (Solsynth/HyperNet.Surface).

Everything in the Servers feature table is expressed as an SSH operation. The dashboard reports latency as two separate numbers, network and SSH round-trip, which tells you the app measures the connection rather than a remote agent. Processes are listed and killed, systemd units are started and stopped, nginx and Caddy configuration is edited, crontab is edited, packages are managed through apt or dnf, and firewalls are managed through UFW, firewalld, nftables or iptables. Each of those is a command sent over the existing session.

The optional layer is MaidCafe Cloud, and it changes the model. According to the README, MaidKit probes the server over SSH, installs the MaidCafe daemon, and registers it in a workspace in one flow. After that "the daemon runs on its own. MaidKit does not need to stay open, and it only connects outbound, so no extra ports are opened to the internet." The daemon is what makes live metrics, scheduled jobs, container log tailing and alarm thresholds possible, because those need something running when your laptop is closed. Container, process, systemd and deployment views route through the daemon when it is installed, with SSH as the fallback.

That fallback is the design's strongest detail. Installing the daemon is an upgrade, not a prerequisite, and the app keeps working over plain SSH if you never install it.

Installing MaidKit and connecting a first server

The README does not contain build or install instructions. It points to a download page instead: the badge links to https://solsynth.dev/zh/products/maid-kit#download, and the homepage field for the project is https://solsynth.dev/products/maid-kit. Start there and pick the build for your platform.

If you want to build from source, the repository is a standard Flutter project, so the toolchain is the usual one. The commands below are the conventional Flutter entry points for a checkout, not something the README documents; treat them as the shape of the process and expect to resolve platform SDKs yourself.

git clone https://github.com/Solsynth/MaidKit.git
cd MaidKit
flutter pub get
flutter run

Once the app is open, the first real task is adding a host. The Servers section describes a grid of server cards with live status, latency, load, memory and uptime, which means a server has to be registered before any of that appears. Credentials go into the encrypted vault the README describes: AES-GCM 256-bit, with PBKDF2 key derivation at 310,000 iterations and optional biometric unlock. Expect to unlock the vault before the cards populate.

From there, the quickest way to confirm the connection is real is the Terminal view, which the README describes as a full SSH terminal with split panes, drag-and-drop tabs, a command palette, OSC 52 clipboard support and terminal color schemes. If the terminal opens and the dashboard numbers move, the SSH path is working. The MaidCafe daemon is a separate, later step, and the README says it is set up in one flow from inside the app.

The MaidCafe daemon, and the cost of opting in

MaidCafe is where MaidKit stops being purely non-intrusive, and the README is upfront about the trade. The daemon is installed onto the server, runs independently of the app, and talks outbound only. In exchange you get fleet metrics streamed over SSE, reusable action scripts with template variables and per-action timeouts, scheduled jobs on cron or @every intervals with failure notifications, container log tracking written to disk, and alarm thresholds evaluated locally by the daemon.

There is also an API surface worth noting if you plan to automate: the daemon watches its config and fragment files, answers systemctl reload (SIGHUP), and exposes GET and PATCH /api/v1/config, where the read is redacted and the patch is a safe subset. Config saves apply without a service restart. API credentials for CI/CD are scoped to daemons, hosts and actions, and a cloud webhook relay delivers invocations to daemons that poll the cloud.

The honest caveat is in the README itself: cloud log upload is opt-in "because logs may contain sensitive data." That is the right default, and it also tells you the daemon sees your application logs. If your servers hold data you cannot route through a third-party cloud, the daemon features that depend on the cloud relay are the ones to leave off; the SSH path still covers the Servers table.

Where MaidKit is the wrong tool

The clearest limitation is the delivery model. MaidKit is a Flutter app you install on your own machine, and the README lists android, ios, linux, macos, web and windows directories, but it does not state which of those are published as installable builds. If your team needs a shared, browser-based view that several people open without installing anything, this is not that product.

Second, the non-intrusive promise has a ceiling. Anything that needs history rather than a snapshot depends on the daemon. The README says the Activity charts are "backed by MaidCafe history when the daemon is installed," and that pinned process usage history is "realtime via the MaidCafe daemon." Without it, you get current state over SSH, not a time series. Plan accordingly if you are choosing MaidKit for capacity review rather than for operations.

Third, the platform-specific management features are only as good as the commands underneath. Services means systemd, Web Servers means nginx and Caddy, Firewall means UFW, firewalld, nftables or iptables, Packages means apt and dnf "and more." A host running something else in any of those slots is a host where that tab has nothing to show. The README does not claim otherwise, but the feature table reads more universal than the implementations are.

Finally, the Agent feature is explicitly gated: proposed actions require approval in review mode before they run, and conversation history is stored on-device outside the vault. That is a sensible split, but it means the agent is a suggestion engine you supervise, not an unattended operator.

How it compares with running Ansible and plain SSH

The closest alternative for this audience is not another GUI. It is Ansible plus a terminal. The difference in approach is fundamental: Ansible is declarative and idempotent, you write playbooks, and the same playbook produces the same end state on every host. MaidKit is imperative and interactive. You click restart, you edit the Caddy file in a dual-pane SFTP browser, you run a snippet against several connected servers. There is no desired-state model and no drift detection.

That makes MaidKit better for the work Ansible is bad at: investigating a machine that is behaving oddly, reading logs, killing a runaway process, checking whether a unit is enabled. It makes MaidKit worse for the work Ansible exists for: reproducing a configuration across fifty hosts and knowing it converged. The Snippets feature runs reusable shell scripts on one or more connected servers with streaming output, which is the nearest thing here to a playbook, but a snippet is a script you run, not a state you enforce.

The second alternative is the plain SSH client you already have. MaidKit's advantage over it is the aggregation: one credential vault, one server list, jump hosts and per-server HTTP CONNECT or SOCKS5 proxies, and the multi-server views. If you connect to two machines, that advantage is small.

Licence, maintenance and what an upgrade costs you

MaidKit is licensed AGPL-3.0, and the licence file is LICENSE.txt at the repository root. For most users this changes nothing, because you are running the app, not distributing it. It matters if you fork MaidKit into something you ship, or if you host a modified version for others, since the AGPL's network clause reaches software offered over a network. That is a question for your own legal review, not something to settle from a README.

The project is not archived, and the last push was on 2026-09-06. Recent releases are 2.1.0+37 on 2026-08-29, 2.0.0+35 (MaidCafe) on 2026-08-21, and 2.0.0+30 on 2026-08-16. The 2.0.0 line is where the MaidCafe layer appears, which means anyone upgrading from an earlier build should expect the cloud and daemon concepts to be new rather than a refinement.

Upgrade cost is concentrated in two places. The credential vault and encrypted .mkb backup archives are format-bound, so verify that a backup made on one version restores on the next before you rely on it; the README does not document rollback. And the daemon is a separate component with its own config and fragment files, so a client upgrade and a daemon upgrade are two operations, not one. The hot-reload path (SIGHUP, or PATCH /api/v1/config) exists to avoid a service restart for config changes, but it does not remove the need to keep the daemon version in step with the app.

Editorial conclusion

MaidKit fits engineers who already work over SSH and want a client that covers terminal, SFTP, systemd, firewall and database maintenance without deploying an agent. It is a poor fit if you need a browser-based, multi-user control panel, or if you are not willing to run a Flutter desktop or mobile app. Before adopting it, check the AGPL-3.0 terms against how you distribute internal tooling, and confirm on solsynth.dev that a build exists for your platform, since the README does not list which of the android, ios, linux, macos, web and windows directories ship as installable artifacts.

Frequently asked questions

Official sources

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