A container panel for people who prefer a desktop app

A preference, not a verdict

There is no objective winner between a web panel and a desktop app. People who live in a terminal and an editor often want their tools as windows they can switch to from the keyboard, with a place in the dock and their own shortcuts. Others are happiest with everything in tabs. Both are reasonable.

Most of the difference is taste. One part of it is not, and it is worth separating the two.

What a native window gives you

1. 01Secrets in the operating system’s own store — Keychain on macOS, DPAPI on Windows, the secret service on Linux — instead of in a browser profile or a server database.
2. 02Real file dialogs: pick an SSH key or a compose file from disk, and save logs where you want them.
3. 03No login session that expires while you are reading logs, and no admin login page anywhere on the internet.
4. 04A smaller audience. Browser extensions with broad permissions can read the pages you open, including environment values and logs shown in a web panel. A desktop window is outside their reach.

What the browser gives back

1. 01Any machine and any operating system, with nothing to install.
2. 02A phone, in an emergency.
3. 03Links you can send to a colleague that open the exact page you are looking at.
4. 04Shared access, with one login per person and the panel enforcing who may do what.

If two or more of these matter to you every week, a web panel is probably the better fit, whatever your taste.

Credentials: where taste stops

A web panel that manages your servers has to hold the credentials for them on the server where it runs, because that is where the work happens. A desktop client holds them on the computer you work from, for the same reason.

Neither is automatically safer. A server is professionally hosted and always on; a laptop gets lost. But they fail differently: one compromised panel exposes every server it manages, while one lost laptop exposes the keys on that laptop, which you can revoke one by one. That is an architectural difference rather than a preference, and the one worth deciding on deliberately.

Half-connected behaviour

Nobody demos this and everybody hits it: the connection drops in the middle of a deploy. A panel on the server carries on, because the work happens there; you reconnect and see the result.

A desktop client that drives the server over SSH depends on that connection. In MihraOps a deploy runs over the open SSH session, so a dropped connection can cut it short. Containers Docker has already started keep running, and you run the deploy again once you are back. The exceptions are the optional Agent’s webhook deploys and alerts, which run on the server by design.

On an unreliable connection that is a real point in the web panel’s favour, and worth weighing if you often deploy from one.

MihraOps, for the desktop group

MihraOps is a desktop client for Windows, macOS and Linux. It connects to your servers over SSH, keeps server credentials in your operating system’s encrypted storage, and shows containers, logs, Compose stacks and domains in a native window.

If you are weighing it against a specific web panel, the Portainer comparison answers the product-by-product question.