Termix: a self-hosted SSH and remote desktop console you run yourself

The problem Termix solves, and who it is for

Managing a handful of servers usually means stacking separate tools. A terminal client for SSH, a browser plugin or a native viewer for RDP and VNC, an SFTP client for file work, a tunnel manager, and something else again for container state. Each one stores its own credentials. Nothing shares a host list.

Termix collapses that stack into one self-hosted application. The README describes it as "a free, open source, self-hosted platform for managing your servers" and explicitly positions it as "a self-hosted alternative to Termius that stays free forever". The target user is an engineer or small team that already runs a VPS or home server and would rather keep host credentials and session data on infrastructure they control than in a vendor account.

The scope is wider than a terminal. The feature list covers SSH, RDP, VNC and Telnet sessions, SFTP file management, local, remote and dynamic SOCKS tunnels, Docker and Podman container controls, host metrics with history graphs, bulk command execution across host groups, and an automation engine with triggers and multi-step actions. It ships as web, desktop and mobile clients according to the README.

How Termix is put together: a TypeScript backend with a dialect-aware database layer

The repository is a TypeScript monorepo. The frontend is built with Vite, and the backend compiles separately under tsconfig.node.json into dist/backend. The Electron entry point is electron/main.cjs, so the desktop build wraps the same application rather than forking it.

The database layer is the most informative part of the layout. There are three Drizzle configs at the root: drizzle.config.mysql.ts, drizzle.config.pg.ts and drizzle.config.sqlite.ts. A script named generate-dialect-schema.cjs runs as part of lint, and a separate verify:dialect script exists. That tells you the project treats MySQL, PostgreSQL and SQLite as supported targets and generates dialect-specific schema rather than assuming one engine.

Remote desktop is not implemented from scratch. The postinstall step runs patch-guacamole-lite.cjs and patch-guacamole-common-js.cjs, which points to Apache Guacamole as the underlying protocol gateway for RDP, VNC and Telnet. The patches also mean the project carries local forks of those packages, so dependency upgrades are not drop-in. The same postinstall chain patches better-sqlite3, nan, app-builder-lib and xterm-android-ime, which is a maintenance signal worth weighing before you deploy.

Deployment artifacts are conventional: a docker/ directory with a Dockerfile, charts/ for Helm, deploy/ and packaging/ directories, and a Casks/ directory suggesting a Homebrew cask for macOS.

Installing Termix with Docker and opening a first SSH session

The package.json dev:docker script is the clearest published signal of how the container is meant to run. It builds from docker/Dockerfile, names the image termix:dev, and publishes ports 3000, 8080 and the range 30001-30006, mounting a host directory at /app/data. The README does not include a copy-paste docker run block, so treat the following as the shape of that script rather than an official snippet:

docker build -f docker/Dockerfile -t termix:dev .
docker run -d --name termix-dev \
  -p 3000:3000 -p 8080:8080 -p 30001-30006:30001-30006 \
  -v ./db/data:/app/data termix:dev

Port 3000 is the application itself. Port 8080 and the 30001-30006 range are what the Guacamole-based remote desktop path needs; if you only want SSH and SFTP, publishing them widens your attack surface for no benefit. The volume at /app/data holds the database, so back it up before you upgrade anything.

Once the container is up, open http://localhost:3000. The README says local accounts exist alongside OIDC, LDAP, GitHub and Google sign-in, with TOTP two-factor and WebAuthn passkeys available, so create the first local admin account and then add a host.

Hosts are added through the Host Manager, which the README describes as supporting tags, nested folders, reused credentials and automatic SSH key deployment. For a one-off connection there is Quick Connect, which the README says is for connections "you do not want to save". After saving a host, opening it gives a terminal with browser-like tabs and split screen, up to six panels, and a toolbar above the session showing live CPU, memory and disk for that host.

Where Termix gets in the way

The licence is the first thing to check. The repository reports a NOASSERTION licence identifier, meaning GitHub could not classify the LICENSE file automatically. The README calls the project "free and open source" and links a donation page, but nothing stated by the project identifies which licence terms apply. If you deploy software for an employer, read the LICENSE file yourself before you build on it.

Upgrade and rollback are undocumented. The README and release notes shown here describe features, not migration steps. There is no described procedure for moving between database dialects, no rollback instructions, and no stated compatibility guarantee between a release and an existing /app/data volume. With three Drizzle dialects in the tree, a deployment that starts on SQLite and later wants PostgreSQL is an open question the project does not answer.

The postinstall patch chain is a real maintenance cost. Six separate patch scripts run on every install, covering Guacamole, better-sqlite3, nan, app-builder-lib and an xterm Android IME fix. Each is a local divergence from an upstream package. Upstream releases can conflict with those patches, and the failure will surface at install time rather than at runtime.

Finally, the README is candid about one boundary: the Docker and Podman controls are "not meant to replace Portainer or Dockge, just to manage containers you already have". If container orchestration is your primary job, Termix is the wrong tool. It is a session and host console that happens to show containers.

Termix compared with a plain SSH config and a terminal multiplexer

The obvious alternative for a single engineer is no tool at all: an ~/.ssh/config file, a terminal emulator, and ssh or tmux. That approach has no web surface, no database, no container and nothing to patch. Credentials live in files you already back up. The difference in approach is centralisation versus distribution. Termix centralises hosts, credentials, tunnels, files and metrics behind one authenticated web UI, which is what makes it useful for a team and also what makes it a single point of failure. A misconfigured reverse proxy in front of Termix exposes every saved host at once; a misconfigured ~/.ssh/config exposes one laptop.

For remote desktop specifically, Apache Guacamole is the upstream project Termix builds on. Running Guacamole directly gives you the protocol gateway without the SSH workspace, metrics or automation layers, and without the local patches. The trade-off is that you assemble the surrounding pieces yourself.

Against a hosted service such as Termius, which the README names directly, the difference is where the data lives and who pays. Termix keeps host data on your server and the README states it stays free, funded by donations. A hosted service removes the operational burden of running and upgrading the console. That is the real decision: not feature count, but whether you want to be the operator of your own access layer.

Maintenance cost and what the licence question means in practice

The last push to the default branch was on 2026-09-10, and the most recent release in the list is release-2.7.1 from 2026-08-23. Releases at 2.6.1, 2.7.0 and 2.7.1 landed within about two weeks of each other, so the project is moving quickly. Fast release cadence cuts both ways: fixes arrive sooner, and so do breaking changes in a self-hosted tool that stores your credentials.

Running Termix means owning five things. A Docker host with the application container. The /app/data volume, which holds the database and needs its own backup routine. A reverse proxy with TLS if the console is reachable from outside your network. The port exposure decision, since 8080 and 30001-30006 only need to be reachable if you use browser-based remote desktop. And the upgrade path, which the project does not document, so pinning an image tag and testing a restore of /app/data before each bump is the only safe pattern the repository supports.

On licensing, the honest position is that the project does not state its terms. NOASSERTION is not a licence; it is the absence of a detected one. A permissive licence, a copyleft licence and a source-available licence with commercial restrictions all produce that identifier. Nothing here is legal advice, and the LICENSE file at the repository root is the only authoritative source.

Editorial conclusion

Adopt Termix if you already run Docker on a small always-on host and want SSH, RDP, VNC and SFTP behind one login you control. Skip it if you need a hardened, fully documented product with a clear licence: the LICENSE file carries a NOASSERTION identifier, and the README does not document rollback or an upgrade path. Verify three things first: that the published image tag matches release 2.7.1, that the ports you expose are limited to what you actually use, and that your own backups cover the mounted data directory, because the README describes no export or restore procedure.

Frequently asked questions

Official sources

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