Termix: a self-hosted console for SSH, RDP and host metrics

The gap Termix fills between a terminal emulator and a control panel

Most engineers end up with three or four tools for the same job. A terminal emulator holds saved hosts and keys. A separate client handles RDP or VNC. A file transfer tool moves builds around. Something else watches CPU and disk and pings a chat channel when a box goes down. Termix is an attempt to collapse those into one self-hosted service, reachable from a browser, with desktop and mobile clients mentioned in the README. The stated audience is people managing their own servers: the README calls it a self-hosted alternative to Termius, and the framing is explicitly free and open source, with a donation link rather than a paid tier. The topics list on the repository (docker, ssh, ssh-tunnel, rdp, vnc, telnet, host-metrics, file-management) maps almost one to one onto the feature table, which suggests the scope has not drifted far from the original intent. What makes it more than a terminal in a browser tab is the host manager: credentials are stored once and reused across hosts, SSH keys can be deployed automatically, hosts can be grouped under a parent host, and access can be shared with other users or roles at four levels (connect, view, edit, manage). That is a team feature, not a solo one. A single developer with two VPS instances gets little from role-based sharing. A small operations group that currently passes around a spreadsheet of IP addresses and a shared key file gets quite a lot.

How the pieces fit together: sessions, stored hosts and the automations engine

The architecture visible in the README is a server-side application that holds host records and credentials, and mediates every session. When you open an SSH terminal, the connection is established through Termix rather than from your laptop directly, which is why the same host list appears on web, desktop and mobile. Each session gets a toolbar with live CPU, memory and disk readings plus shortcuts to that host's files, Docker, tunnels and metrics, so the metrics collector is wired to the same host record as the terminal. The tunnel support covers local, remote and dynamic SOCKS forwarding with auto reconnect and health checks. One detail worth noting: client-to-server tunnels created in the desktop app are stored on that machine, and presets can be saved to the server to move a setup to another client. That is a deliberate split between machine-local state and shared state, and it means a tunnel you built on your laptop will not silently appear for a colleague. The automations engine is the most structurally interesting part. Triggers include a metric crossing a threshold, a host going up or down, a health check changing state, a schedule, a container event, and an incoming webhook. Steps can run commands and snippets, control containers and tunnels, wake a host, call a URL, wait, branch on a condition, run another automation, and notify over ntfy, Discord or a webhook. That is a small workflow engine with branching and recursion, which is a real design commitment, not a checkbox. The README also mentions test runs so you can try an automation before it goes live, which is the right instinct given that a misconfigured branch could restart containers in a loop.

Getting an instance running and the config surface you actually touch

The README does not reproduce a docker run command or a compose file in the excerpt available here, so the exact image name and environment variables cannot be confirmed from this material. What can be confirmed is that Docker is a listed topic and the project ships releases tagged release-2.7.1-tag, release-2.7.0-tag and release-2.6.1-tag, with the most recent push in September 2026. The homepage at termix.site is the place to look for the current install instructions, and the repository's docs directory holds translated READMEs (docs/readme/README-CN.md, README-JA.md, README-KO.md and others) which is a hint that the project expects a non-English-speaking user base and has invested in documentation structure rather than a single long page. Configuration that is described in the README is mostly in-app rather than file-based: authentication can be local, OIDC, LDAP, GitHub or Google, with TOTP two-factor, WebAuthn passkeys and trusted devices. The AI assistant is off by default and admins can disable it for the whole instance or hide it during setup, which is the correct default for a tool that can read host and fleet data. If you are evaluating Termix, the practical sequence is to stand up the container, create the first admin account, add one throwaway host, and confirm the SSH terminal and the file manager both work against it before importing anything real. The credentials model matters here: because Termix stores credentials for reuse across hosts and can override credentials for a shared host, a mistake in the sharing configuration is a mistake in access control, not just a display bug.

Where Termix is the wrong tool

The README is unusually candid about one boundary: the Docker and Podman integration is, in its own words, not meant to replace Portainer or Dockge, just to manage containers you already have. Take that seriously. If your workflow depends on stack deployment from compose files, registry browsing, or detailed container inspection, Termix will not carry it. The second boundary is the licence. The repository metadata reports NOASSERTION, which means no standard licence identifier was detected. The README says Termix is free and open source and asks for donations, but free to use and OSI-approved are not the same claim, and until the licence file is read directly you cannot know what redistribution or internal modification is permitted. For a tool that holds SSH credentials for your entire fleet, that is not a footnote. Third, the browser-based remote desktop path is the riskiest part of the feature set in any project, because RDP and VNC in a browser depend on gateway behaviour, clipboard handling and audio that vary by host configuration. The README mentions a native RDP client option on Windows desktop, which is a sensible escape hatch, but it also implies the browser path is not always the preferred one. Finally, the breadth of the feature table is itself a caution. Host metrics, service management, cron jobs, packages, users, firewall rules, WireGuard, Tailscale, SSL certificates, logs and health checks are all listed as manager card functions. Each of those is a place where a version difference in the target distribution can break the parsing behind the card, and the README does not describe how failures are surfaced.

Termix against Termius and against a plain SSH config

The README names Termius as the thing Termix replaces, and the difference in approach is mostly about where the data lives. Termius is a commercial client with a hosted sync service; your host list and credentials are stored in a vendor account, and the free tier has limits. Termix inverts that: you run the server, and the host records, credentials, audit log and session list sit on infrastructure you control. For anyone whose reason for looking at this category is that they do not want a third party holding their private keys, that inversion is the whole argument. The cost is that you now operate the thing that holds every key to every server, and the README's own security surface (OIDC group mapping, role sharing, audit log, session revocation across platforms) is what you are relying on to keep it safe. The other comparison worth making is against doing nothing: an ~/.ssh/config file, ssh-agent and a tmux session. That setup has no web UI, no RDP, no metrics history and no shared access model, but it also has no server to patch and no credential store to breach. Termix only earns its place when more than one person needs access to the same hosts, or when you specifically need remote desktop and file transfer in the same interface as the terminal. If neither of those is true, the SSH config wins on every axis except convenience.

Upgrade cadence, licence risk and what maintenance actually costs

The release history shows a steady cadence: 2.6.1 in early August 2026, 2.7.0 in mid August, 2.7.1 in late August, with the repository last pushed in September 2026. Minor-version bumps at roughly two-week intervals suggest active development and a willingness to ship, but also that the surface is still moving. For a self-hosted tool that stores credentials, that cadence cuts both ways. You get fixes quickly; you also get schema or behaviour changes that require you to read release notes before updating. The README does not describe a migration path or a database backup procedure in the material available here, so the safe assumption is that you should back up the Termix data volume before each version bump and treat upgrades as a deliberate step rather than an automatic pull. On licence: with NOASSERTION in the repository metadata, the practical move is to open the licence file in the repository root and read it before you deploy inside a company, because the obligations for internal use, modification and redistribution differ sharply between permissive and copyleft terms. Nothing here is legal advice, and the README's own description of the project as free and open source is a statement of intent, not a licence grant. The maintenance cost beyond upgrades is mostly the credential store itself: rotating keys, revoking sessions when someone leaves, and keeping the OIDC or LDAP mapping current. Termix gives you the audit log and session revocation to do that; it does not do it for you.

Editorial conclusion

Adopt Termix if you already run a small fleet of Linux hosts, want browser-based SSH and RDP without a per-seat subscription, and are comfortable reading a README rather than a manual. Do not adopt it if you need a signed support contract, a clearly stated OSI licence before deployment, or a container management UI with the depth of Portainer. Before rolling it out, verify three things on your own instance: what the repository licence file actually says, whether the browser RDP and VNC paths work against your specific hosts, and whether the automations you plan to rely on can be tested with the built-in test run.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Termix-SSH/Termix on GitHub