Termix keeps hosts and credentials in its core and turns the SSH terminal into a removable plugin

The core stores hosts, credentials and sharing; the terminal is a plugin

Termix describes itself as a self-hosted, plugin-based server management platform, and the split is literal. The core keeps hosts, credentials, users, sharing and sessions. The SSH terminal, remote desktop, file manager, Docker and metrics are plugins that an admin can turn on, off or remove from the Plugins tab.

What every install has regardless of plugins: hosts saved in nested folders with tags and parent hosts, bulk edit, import and export, and Quick Connect for one-off connections; credentials (passwords and keys) reused across hosts, with defaults set at the level of the server, a user or a folder; local accounts with visible and revocable sessions, trusted devices, API keys and an audit log. The interface layer is also core: tabs and split screen, a command palette opened by double tapping left shift, rebindable shortcuts, themes, branding and around 30 languages.

The consequence is that "Termix" is not one feature list. Two installs on the same version can behave very differently depending on which plugins an admin removed. If you are evaluating it, the core is the stable contract and everything you open a tab for is a separate component.

Every official plugin lives in its own repository

The official plugins ship with Termix, but each one has its own repo under the Termix-SSH organization: Plugin-Docker, Plugin-File-Manager, Plugin-Kubernetes, Plugin-LDAP, Plugin-Vault, Plugin-ACME-SSL, Plugin-Cloud-Providers and more. Admins can install, update or remove them from the Plugins tab.

The list goes well past terminals. ACME Certificates obtains the Termix HTTPS certificate from Let's Encrypt or any ACME provider and renews it. Cloud Providers adds hosts from AWS, Azure, Google Cloud, DigitalOcean, Hetzner and other clouds and keeps them in sync. HashiCorp Vault connects to hosts with short-lived SSH certificates signed by Vault. LDAP lets people sign in with LDAP or Active Directory credentials. Alerts collects alerts into one inbox and delivers them to webhooks, ntfy, Discord and email. Audit Tools sends the audit log to a SIEM and exports it as CSV or NDJSON.

The cost of this layout is tracking. A bug in the file manager is a bug in Plugin-File-Manager, not in the main repo, so issue searches and changelogs have to be read per plugin. When something breaks after an update, you need to know whether the core or a plugin changed.

Sharing works at four levels: connect, view, edit and manage

Hosts, credentials and folders can be shared with individual users or with roles, and each grant sits at one of four levels: connect, view, edit and manage. The connect level is the interesting one. It separates being allowed to open a session to a host from being allowed to see or change how that host is configured, which is what a team needs when a contractor should reach a box without reading the saved key behind it.

Secrets are handled per user: passwords, keys and other secrets are encrypted per user, and the database can be encrypted on disk. Note the wording on the second part. Per-user secret encryption is stated as how secrets are stored; disk encryption of the whole database is stated as something that can be done. Treat it as a setting to confirm on your own deployment rather than an assumption.

Account controls sit next to this: sessions you can see and revoke, trusted devices, API keys and an audit log. Login policy such as idle sign-out and session length limits comes from the Login Security plugin, so a deployment without that plugin does not get those controls.

SQLite by default, with separate Drizzle configs for PostgreSQL and MySQL

Termix uses SQLite by default and supports PostgreSQL and MySQL too. The repository root shows how that is kept honest: there are three Drizzle configs, drizzle.config.sqlite.ts, drizzle.config.pg.ts and drizzle.config.mysql.ts, alongside a drizzle/ directory. The lint script begins with a dialect schema check, and there is a dedicated verification script:

tsx scripts/verify-dialects.mjs

This matters when choosing a backend. SQLite keeps a single-server install simple, because the database is a file next to the application. PostgreSQL or MySQL makes sense if you already run one and want Termix data inside your existing backup and replication setup. Because three dialects are maintained in parallel, a schema change has to land correctly in all three, which is the reason the dialect checks exist in lint. If you run one of the non-default backends, read release notes for migration notes before upgrading, since your path is the one fewer installs exercise by default.

Host Status checks a port, and file-defined hosts are read only

Two plugins behave in ways that are easy to misread. Host Status shows whether each host is online with a dot in the host list, and it decides that by connecting to the host's port. A green dot therefore means the port accepted a connection. It does not tell you that your credentials still work, that the login shell starts, or that the service you care about on that machine is healthy. If you need those answers, the Alerts and Automations plugins are where to look, not the status dot.

Hosts Config lets you keep hosts, folders and sharing in a YAML or JSON file. Termix loads them as read only hosts and reloads when the file changes. The upside is that host definitions can live in version control. The downside is that anyone used to editing a host in the UI cannot do so for those entries: the file is the only place to change them. Mixing file-defined and UI-defined hosts in one install means two sources of truth, and people on your team need to know which hosts come from which.

Docker and Kubernetes management runs through your hosts over SSH

The Docker plugin manages Docker and Podman containers on your hosts over SSH, with logs, stats and a console. The Kubernetes plugin manages clusters from your hosts over SSH, with logs, metrics, YAML and a shell. The Databases plugin browses and edits MySQL, MariaDB, PostgreSQL and SQLite databases on your hosts from one tab.

The common thread is that Termix reaches these systems through a host it can already SSH into. That keeps the model simple, and it also sets a hard boundary. A cluster that is not reachable from any host saved in Termix cannot be managed from Termix, and a container runtime on a machine Termix has no SSH access to is invisible to it. Access control follows the same path, so whoever can connect to the host through Termix sharing is the person who gets to the containers on it.

Fleets extends this to many machines at once: group hosts into fleets and run commands, package actions and file transfers across all of them.

The desktop app can run alone or sync an offline copy from a server

Termix runs on web, desktop and mobile. The desktop app is an Electron build: package.json sets main to electron/main.cjs, and the repository has electron/, electron-builder.json, packaging/ and a Casks/ directory. The desktop app runs on its own and can also link to a Termix server to keep an offline copy of your account.

That gives two ways to use it. A single person can install only the desktop app and never run a server. A team can run the server, and each member's desktop app keeps a local copy for when the server is unreachable. What the offline copy allows you to change, and how conflicts are resolved when you reconnect, is something to test before relying on it during an outage.

For a quick look without installing anything, there is a public demo at demo.termix.site where any username and password works. That is useful for seeing the interface and plugin list, but it is a shared demo and not a place to enter real host credentials.

Building from source needs Node 22.12 and patches six native dependencies

package.json pins engines to node >=22.12.0 and npm >=11, and the repo is an npm workspace over packages/*. The postinstall step runs six patch scripts in sequence before anything else works, covering app-builder-lib, better-sqlite3, nan, node-pty, ssh2-agent and ssh2-sk. Older Node or npm versions, or an install that skips lifecycle scripts, will leave those native modules unpatched.

Development entry points are all routed through one script with a mode argument:

node scripts/dev.mjs docker

The same script runs plain and with electron, and dev:frontend starts Vite on its own. Releases move quickly: v26.10.6 on 2026-10-29, v26.11.0 on 2026-11-01 and v26.11.1-beta.1 on 2026-11-03, with the last push to main on 2026-10-30. For a production install, pin a stable tag and skip the beta builds, because a new tag can appear within days of the last one.

Editorial conclusion

Termix fits a person or team that wants one self-hosted place for hosts, shared credentials and role-based access, and is comfortable treating the terminal, file manager and Docker views as plugins with their own repos and update paths. It is a poor fit for anyone who wants a single fixed feature set that never changes shape between releases. Before adopting it, check which plugins your install has enabled, whether database encryption on disk is turned on, which database backend you will run, and pin a release rather than following the beta tags.

Frequently asked questions

Official sources

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