Self-Host Termix: SSH, RDP and SFTP in One Browser Tab

An open source Termius alternative that puts SSH, RDP, SFTP and tunnels in one browser tab. Here is the compose file that actually works, plus the sidecar everyone forgets.

Self-Host Termix: SSH, RDP and SFTP in One Browser Tab

I have eleven terminal tabs open right now. Four are SSH sessions to boxes I will have forgotten about by Friday, two are tailing logs I stopped reading an hour ago, and one is a jump host I keep alive purely because reconnecting through it is tedious. If you run more than a handful of servers, this is your life too, and every few months you go looking for something better.

Termix is the something better I have been using lately. It is a self-hosted server management platform that puts SSH terminals, RDP and VNC sessions, SFTP transfers, tunnels, container control and host metrics in one browser tab. If you have been looking for an open source Termius alternative, this is the closest thing I have found, and the features that Termius puts behind a subscription are simply there. It is Apache 2.0, sits at just over 15,000 GitHub stars, and shipped release 2.8.0 on September 20, 2026.

You need a Linux host with Docker and Docker Compose, and at least one server you want to manage. Upstream says one core and 1 GB of RAM is plenty for the server itself. Here is how to run it properly, including the part I got wrong the first time.

The sidecar nobody mentions

Termix does not speak every protocol itself. SSH and SFTP are native. RDP, VNC and Telnet are handed off to guacd, the same daemon that powers Apache Guacamole.

Protocol Handled by Works without guacd?
SSH, SFTP Termix itself Yes
RDP, VNC, Telnet guacd sidecar container No
Serial Web Serial API in the browser Yes

This matters because a Termix container on its own starts up perfectly happily. SSH works, the file manager works, metrics work. Then a week later you try to open a Windows box, the tab hangs, and you go hunting through logs. Run the sidecar from day one even if you think you will never touch RDP.

Getting it running

Here is the compose file I actually use. It is the upstream one with the recording and drive paths wired up, which is the configuration you want if you ever plan to turn on session recording.

services:
  termix:
    image: ghcr.io/lukegus/termix:latest
    container_name: termix
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - termix-data:/app/data
    environment:
      PORT: "8080"
      GUACD_HOST: "guacd"
      GUACD_TUNNEL_HOST: "termix"
      GUACD_RECORDING_PATH: "/termix-data/session_recordings/guacamole"
      GUACD_DRIVE_PATH: "/termix-data/rdp-drive"
    depends_on:
      - guacd
    networks:
      - termix-net

  guacd:
    image: guacamole/guacd:1.6.0
    container_name: guacd
    restart: unless-stopped
    volumes:
      - termix-data:/termix-data
    networks:
      - termix-net

volumes:
  termix-data:
    driver: local

networks:
  termix-net:
    driver: bridge
docker compose up -d

Open port 8080 and create your account. The database is SQLite by default, which is fine for one person. If a team is going to use this, set DATABASE_DIALECT to postgres or mysql and point DATABASE_URL at a real database before you have data worth migrating.

That termix-data volume holds your encryption keys, SSL certificates and session recordings. Back it up like it is a password manager, because functionally it is one.

If you would rather not babysit the sidecar, the reverse proxy and the certificate renewals, Termix is available as a managed service on Elestio from $16/month on a dedicated VM with 2 vCPU and 4 GB of RAM, with backups, SSL and updates handled for you. The software carries no licence fee, so that figure is the infrastructure, which is the only thing you are ever paying for here.

The features that earn the tab

Hosts and credentials. You save a credential once and reuse it across hosts, rather than pasting the same key into fifteen entries. Termix can push your public key to a new host for you, and folders with tags keep a homelab from turning into an unsorted list.

Tunnels. This is the part that made me keep it. Local, remote and dynamic SOCKS forwarding, defined once in the UI, with auto reconnect and health checks. Every ssh -L 5432:localhost:5432 incantation I keep re-typing and re-breaking becomes a saved entry that comes back on its own after a network blip.

Fleets. Group hosts by tag rules so new machines join automatically, then run one command across all of them or collect an OS and kernel inventory.

File manager. SFTP browsing and editing with sudo support, plus a transfer tab that copies straight from one server to another instead of pulling everything through your laptop.

Lock it down before you expose it

Termix is a box with credentials for every server you own. Treat it accordingly.

Authentication supports OIDC, LDAP, GitHub and Google alongside local accounts, with TOTP, passkeys and trusted devices. Wire it to your identity provider and turn on 2FA before you give anyone else a login.

For secrets, set TERMIX_REQUIRE_EXTERNAL_SECRETS: "true" and supply keys through JWT_SECRET_FILE, DATABASE_KEY_FILE, ENCRYPTION_KEY_FILE and INTERNAL_AUTH_TOKEN_FILE as Docker secrets, so nothing sensitive lives in your compose file.

Two switches deserve a second look. TRUSTED_PROXY_AUTH_ENABLED lets a reverse proxy assert who the user is, which is exactly as dangerous as it sounds if the container is reachable by anything other than that proxy. And session sharing can hand out a link that joins a live terminal with no account at all. Both are off by default. Leave them that way unless you have a specific reason, and if you do enable sharing, disable it per host where it does not belong.

The AI assistant is also opt-in. When enabled it reads hosts, snippets and alerts and proposes changes for you to approve rather than applying them, and it cannot touch credentials or user settings. Admins can switch it off instance-wide.

What it is not

The container manager is deliberately limited. Upstream says plainly that it is not meant to replace Portainer or Dockge, just to poke at containers you already have. If you want image builds and stack management, keep your existing tool.

Troubleshooting

RDP or VNC tabs hang or error out. The guacd container is missing, not on the same network, or GUACD_HOST does not match its service name. Check with docker compose logs guacd.

RDP drive redirection fails. GUACD_DRIVE_PATH has to be writable by the guacd user, and the shared volume must be mounted in both containers. This one catches people because the compose snippet on the docs install page leaves the volume off guacd entirely. The file in the repository under docker/ has it. Copy that one.

Terminals connect and immediately drop behind a reverse proxy. WebSocket upgrade headers are missing. In Nginx you need proxy_set_header Upgrade $http_upgrade; and proxy_set_header Connection "upgrade"; on the location block.

Collaboration rooms behave oddly with more than one replica. Without Redis, rooms fall back to in-memory state per instance. Point every backend at the same Redis with REDIS_URL and set TERMIX_REDIS_PREFIX.

Port 8080 is already taken. Change the host side of the mapping only, and leave PORT at 8080 unless you also change the container side. Mismatching those two is a fast way to a container that looks healthy and answers nothing.

Was it worth it

I did not expect to replace my terminal, and I have not. What Termix replaced is the mess around the terminal: the tunnels I kept rebuilding, the credentials scattered across config files, the RDP session I used to open from a different machine entirely. That turned out to be most of the annoyance.

If you want to skip the setup, you can deploy Termix on Elestio in a few clicks and spend your time on the hosts instead of the host manager.

Thanks for reading ❤️ See you in the next one 👋