Termix Self-Hosted SSH Manager: Docker & Dokploy Setup

Termix self-hosted puts a browser-based SSH manager, file manager, stats dashboard, and remote desktop gateway on your own server. It is an Apache-2.0 licensed project and a free Termius alternative: no external accounts and no paid tier. Since late 2025 it has grown from about 8,500 to over 15,000 GitHub stars, and the 2.x releases turned it from a terminal app into a full server hub. This guide covers the whole setup: deploy with Dokploy or Docker Compose, enable RDP/VNC remote desktop, and lock the deployment down.

What is Termix?

Termix is a self-hosted SSH and remote desktop management platform. One web interface covers terminal sessions, SSH tunnels, file management, server stats, Docker containers, and browser-based RDP/VNC/Telnet. The project is Apache 2.0 licensed, donate-supported, and the README is explicit: it is a self-hosted alternative to Termius that stays free forever.

Video shows the 1.x interface. Termix redesigned the UI (sidebar, host manager, navigation) in 2.3.0, so menus will look different on current versions.

What’s new since late 2025

If you last looked at Termix when it was a 1.x terminal app, a lot has shipped since:

• Remote desktop (2.0.0): RDP, VNC, and Telnet in the browser, powered by Guacamole’s guacd
• Desktop app for Windows, macOS, and Linux, plus Android and iOS apps
• Real Docker management (1.10.0) with Podman support (2.5.0), not just a container list
• RBAC roles, shared sessions, and API keys
• PostgreSQL and MySQL support (2.7.0) alongside the SQLite default
• Automations, fleet-wide commands, and alerts (ntfy, Discord, webhook)
• Termix AI (2.7.0), optional and off by default
• Telemetry is now on by default (2.6.0). Opt-out is covered in the security section below

Termix core features

The feature list that matters for daily ops:

SSH terminal, tunnels, and split screen

The terminal is the core of the app. Tabs, up to six split panels, sessions that survive a page refresh or a container restart, and per-host keepalive. Since 2.6.0 you can save split layouts, and 2.7.0 added workspaces so you can restore a whole set of sessions at once. Terminal session logging is built in if you need an audit trail of what was typed.

The tunnel story also grew up. On top of plain local tunnels with auto reconnect and health checks, 2.2.0 added remote and bridge tunnels with presets, and the desktop app has a dedicated port-forwarding tab since 2.8.0. That covers most cases where you would otherwise reach for an SSH config file full of -L and -R flags.

Remote desktop: RDP, VNC, and Telnet in the browser

This is the 2.0.0 headline feature. Termix uses Apache Guacamole’s guacd daemon to bring Windows RDP sessions, macOS/Linux VNC screens, and even Telnet gear into the same web UI as your SSH terminals. It is enabled per host, and it needs the guacd sidecar container (or an existing guacd you point to with GUACD_URL). The full setup is in the remote desktop section below.

Docker and Podman management

Since 1.10.0 the Docker view is real container management: start, stop, pause, remove, live stats, and a shell into the container. 2.2.0 added a read-only mode for restricted users, and 2.5.0 added Podman support. The README is honest about scope: it “is not meant to replace Portainer or Dockge”. For anything beyond quick ops, I still use Dockge, a self-hosted Compose stack manager. Termix Docker view is for “what is running and why is it failing”, not for stack editing.

Automations, fleets, and alerts

This is where the “server hub” pitch became real. Automations (2.7.0) chain triggers and steps: metric thresholds, host up/down events, schedules, or webhooks can fire commands and send notifications through ntfy, Discord, or generic webhooks. Fleets run one command, file push, package update, or inventory query across many hosts at once. Alerts arrived in 2.5.0. For a solo operator with a dozen servers, this replaces a pile of for-loops in bash.

One paragraph on Termix AI, because self-hosters will ask: it is off by default at both the admin and user level, propose-only (it suggests commands and runs them only after you approve, using your account’s permissions), has no access to credentials, keys, or settings, and strips secrets before sending anything to the provider. You bring your own API key, and Ollama works for a fully local setup.

App overview

Here is a quick tour of the main areas you will use daily. The screenshots show the 1.x interface, which was redesigned in Termix 2.3.0; the workflow is the same, the layout is not.

Terminal workspace

Termix browser terminal with split SSH sessions in tabs

Screenshot shows the 1.x interface, redesigned in Termix 2.3.0.

The browser terminal supports tabs and up to six split panels. Click the <|> icon on a tab (next to the close button) to open a split screen and the SSH tool sidebar for that session.

Tools, snippets, and command history

Termix tools sidebar with SSH tools, snippets, and command history

Screenshot shows the 1.x interface, redesigned in Termix 2.3.0.

Click the hammer icon in the top right to open the tools sidebar. This is where you find SSH tools, command history, snippets, and split screen helpers.

Add and manage hosts

Termix host manager for adding SSH hosts, tags, and jump hosts

Screenshot shows the 1.x interface, redesigned in Termix 2.3.0.

Open Host Manager to add SSH hosts, set tags and folders, and enable features per host: terminal, file manager, server stats, tunnels, remote desktop. You can also configure a Jump Host here to reach servers behind a private network.

To deploy credentials, add a key in Add Credential, then return to Credential Viewer and click the green arrow on the credential to follow the deployment steps. If the target rejects the key with “Too many authentication failures”, the server is usually drowning in offered keys; here is how to fix the SSH “Too many authentication failures” error.

If you plan to use OIDC and the first login is refused, create the local admin account first, then connect your identity provider in admin settings. The 2.3.0 release added automatic OIDC provisioning, but local-first is the path of least resistance.

Server details and tunnels

Termix server details showing CPU, memory, disk stats and tunnel status

Screenshot shows the 1.x interface, redesigned in Termix 2.3.0.

After connecting to a host from the sidebar, open Server Details for CPU, memory, disk, process list, services, cron jobs, and tunnel status. Stats and tunnels only show up if they are enabled for that host in Host Manager. These are host-level snapshots, not a monitoring stack: for history, alerting, and multi-server dashboards, pair Termix with Beszel and Uptime Kuma for dedicated server monitoring.

File manager and editor

Termix file manager editing remote Linux files in the browser

Screenshot shows the 1.x interface, redesigned in Termix 2.3.0.

The file manager browses and edits files on Linux hosts directly in the UI: upload, download, compress, media playback, and since 2.7.0 a trash folder. A cross-host file clipboard (2.5.0) and server-to-server transfers (2.8.0) save you from scp round-trips. Enable File Manager on the host, then open it from the sidebar after connecting.

Admin settings and identity

Admin users open Admin Settings from their username in the bottom left. This is where you configure:

• SSO (OIDC, LDAP, GitHub, Google) and registration rules
• Export/Import in the Database tab
• SSL certificate generation, if you want Termix to serve its own TLS
• The audit log (2.4.0+) and telemetry toggle (2.6.0+)

SSH tunnel access

If a host has Terminal enabled, click the >_ icon in the sidebar to open a session. Configured tunnels show their live status in Server Details.

Command palette

Double tap Left Shift to open the command palette for quick navigation. That shortcut is still documented in the README, but worth a quick check in your build since the 2.3.0 UI redesign moved things around.

How Termix compares to a tool stack

The honest framing: Termix replaces the daily-driver collection of small tools, not the specialized ones.

Where it fits among the best self-hosted server panels: panels like Casaos or Cosmos manage the server itself, Termix manages the servers you connect to. Running both is normal, not redundant.

Accessing private networks: jump hosts, Tailscale, and Cloudflare Tunnel

Termix private network topology: jump host, Tailscale mesh, and Cloudflare Tunnel paths to a home lab

If Termix runs on a public VPS but the interesting machines live in a home lab, you have three solid paths:

1. Jump host: configure a bastion in Host Manager and let Termix hop through it. The bastion is the one host you deliberately expose.
2. Mesh VPN: put Termix and your home nodes on the same overlay network. This is now native: Tailscale SSH authentication landed in 2.4.0, Tailscale/WireGuard host integration in 2.5.0, and 2.7.0 added a custom Headscale endpoint, so you can self-host your own Tailscale control server with Headscale and point Termix at it.
3. Cloudflare Tunnel: 2.3.0 added SSH over Cloudflare Tunnel. cloudflared makes outbound connections only, so the home firewall stays closed.

One operational rule worth stealing from the project’s own docs: run Termix outside the network it manages. If your management plane lives inside the lab and the lab goes down, you lose the tools you need to fix the lab.

For an always-on home node, a low-power box is the right tool; an N150 mini PC idles at 5-8W at the wall, next to nothing against an old desktop. I compared the current picks in the mini PC home server guide.

What you need before you deploy

The “run this tonight” checklist:

Termix requirements and sizing

Official benchmarks (Termix docs, tested on v2.7.0) make this one of the cheapest self-hosted services to justify:

Translation: the smallest VPS tier from any real provider is enough, which puts this in the few euros/dollars per month range. Benchmarks do not include remote desktop load, so if you plan long RDP sessions, use the guacd sizing row. If you are shopping, the cheapest Hetzner Cloud plans are a good baseline for EU latency, or Vultr if you need a global footprint.

VPS prices jumped across the board in 2026 — if you’re rethinking a rented box, see what changed and when a mini PC wins.

Here is the target architecture before you deploy:

Termix deploy architecture: browser to reverse proxy to Termix and guacd containers with SSH and RDP/VNC targets

Deploy Termix with Dokploy

If you already use Dokploy, this is the fastest path: automatic HTTPS, the dokploy-network wired up, and one-click redeploy. If you do not have Dokploy yet, start with the Dokploy install guide.

Step 1: Create the service

1. Open your Dokploy project
2. Click Add Service and choose Compose
3. Name it termix

Step 2: Paste the compose file

The full walkthrough of service types is in how to deploy a Docker Compose app in Dokploy. Use this compose, which pins the version and adds the guacd sidecar:

services:
  termix:
    image: ghcr.io/lukegus/termix:2.8.0
    networks:
      - dokploy-network
    restart: unless-stopped
    environment:
      - PORT=8080
      - ENABLE_TELEMETRY=false   # optional, locks telemetry off
    volumes:
      - termix-data:/app/data
    depends_on:
      - guacd

  guacd:
    image: guacamole/guacd:1.6.0
    restart: unless-stopped
    networks:
      - dokploy-network
    # no ports: keep 4822 internal

networks:
  dokploy-network:
    external: true

volumes:
  termix-data:

Step 3: Domain and port

Create a domain in Dokploy and map it to port 8080. Deploy, then open https://your-domain.com and complete the first-run setup (create the admin account; the onboarding flow was reworked in 2.7.0, so it may differ from older screenshots).

Step 4: Verify

• In Dokploy, both services show Running: termix and guacd
• Open the domain, log in, and confirm the version under Admin Settings
• If remote desktop errors later with “guacd unreachable”, the fix is usually name resolution across the shared network: set GUACD_URL=tcp://guacd:4822 explicitly on the termix service

Deploy Termix with Docker Compose (standalone)

No Dokploy? Plain Compose works the same. This mirrors the official docs compose, with the version pinned and guacd kept internal:

services:
  termix:
    image: ghcr.io/lukegus/termix:2.8.0
    container_name: termix
    restart: unless-stopped
    ports:
      - "8080:8080"
    environment:
      PORT: "8080"
      # ENABLE_TELEMETRY: "false"
    volumes:
      - termix-data:/app/data
    depends_on:
      - guacd
    networks:
      - termix-net

  guacd:
    image: guacamole/guacd:1.6.0
    container_name: guacd
    restart: unless-stopped
    networks:
      - termix-net
    # no ports: keep 4822 internal

volumes:
  termix-data:
    driver: local

networks:
  termix-net:
    driver: bridge

Start and verify:

docker compose up -d
docker compose ps                       # both containers Up
docker compose logs termix --tail 50    # watch startup/migrations
curl -fsS -o /dev/null -w '%{http_code}\n' http://localhost:8080   # expect 200

Then open http://your-server-ip:8080 and finish the initial setup. After login, check Admin Settings for the version and the telemetry toggle.

If you plan to keep 8080 exposed on a LAN-only box, fine. On a public server, do not: put a reverse proxy in front (next section) and firewall the raw port.

Useful environment variables beyond PORT (full list in the Termix docs):

Two failure modes to expect on fresh installs: port 8080 already bound by another stack (change the host side of the mapping), and a stale termix-data volume from a pre-2.x install (check the logs for migration errors before assuming the image is broken).

Post-deploy checklist

The first ten minutes after either deploy path:

Then harden it. The security section below is not optional reading for this particular app.

Enable Termix remote desktop with guacd

Remote desktop arrived in 2.0.0 and is the feature that turns Termix from an SSH tool into a genuine all-in-one. Both compose files above already include the sidecar; this section explains the knobs.

Enable per host. In Host Manager, enable the remote desktop feature on the host, then set the protocol and connection details. Protocols and when to use them:

Capacity. The official benchmarks add roughly 1 core and 1 GB RAM when guacd is in play. Long RDP sessions are CPU-bound on the guacd container, not on Termix itself.

Keep guacd private. Some docs examples publish 4822:4822. That is a LAN pattern. On a VPS, do not publish 4822; keep both containers on the same compose or Dokploy network and let them talk internally. guacd has no authentication of its own, so anything that can reach 4822 can drive your desktop sessions.

Point at an existing guacd. Already running Guacamole? Skip the sidecar and set GUACD_URL=tcp://your-guacd-host:4822 on the termix service.

Known pain points from the 2026 releases, now fixed: RDP through a jump host works since 2.6.0, and VNC to macOS Screen Sharing stopped showing black screens with the 2.7.0/2.8.0 fixes. If you see either symptom, you are on an old tag.

Reverse proxy and HTTPS (Nginx, Traefik, Caddy)

The golden rule: never expose raw port 8080 to the internet. Termix holds SSH credentials, so it sits behind HTTPS and ideally an additional access layer.

Termix is WebSocket-heavy (terminals, RDP, live stats), so the one reverse-proxy mistake to avoid is missing upgrade headers. Symptoms: the UI loads, then terminals disconnect or never connect.

server {
    listen 443 ssl;
    server_name termix.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
    }
}

labels:
  - "traefik.enable=true"
  - "traefik.http.routers.termix.rule=Host(`termix.example.com`)"
  - "traefik.http.routers.termix.entrypoints=websecure"
  - "traefik.http.routers.termix.tls.certresolver=myresolver"
  - "traefik.http.services.termix.loadbalancer.server.port=8080"

termix.example.com {
    reverse_proxy 127.0.0.1:8080
}

Two extras for special setups: sub-path deployments work with VITE_BASE_PATH=/termix/ (1.11.1+), and 2.7.0 added trusted-proxy auth (TRUSTED_PROXY_AUTH_* env vars) if your proxy owns the login flow, for example behind Authelia or similar.

Database options: SQLite, PostgreSQL, or MySQL

The default is SQLite in the termix-data volume, and for a solo operator that is the right answer: fewer moving parts, one file to back up.

PostgreSQL, MySQL, and MariaDB are supported since 2.7.0 for central backups or multi-instance setups:

environment:
  DATABASE_DIALECT: "postgres"        # or mysql (MariaDB uses mysql + a mariadb:// URL)
  DATABASE_URL: "postgres://termix:password@db:5432/termix"
  # DATABASE_SSL: "require"           # for untrusted networks

Keep the termix-data volume even on an external database. It still holds the encryption keys, SSL certificates, and session recordings, so the “just delete the volume” instinct after switching to Postgres will cost you your stored credentials.

Cost/ops note: an external DB is one more service to back up, patch, and connection-limit. Unless you have a concrete reason (shared cluster, centralized backups), SQLite plus volume backups is the boring, correct default.

Termix security: updates, exposure, and telemetry

This section replaces the “it’s self-hosted, so it’s safe” hand-wave, because 2026 tested that assumption. Termix has published over 30 security advisories, several critical. An app that stores SSH credentials for all your servers deserves the same discipline as your VPN.

Which version should you run?

Three practical rules:

• Pin the image tag (ghcr.io/lukegus/termix:2.8.0), never :latest on an internet-facing credential vault. Updates become a deliberate docker compose pull && docker compose up -d, and on Dokploy that is covered by how to update Docker Compose stacks in Dokploy.
• Update faster if you run multi-user. Much of the 2026 wave was cross-user (IDOR, credential theft). A single-admin box has a smaller blast radius; a team install does not.
• Watch the advisories, not just releases: the GitHub security tab is where criticals appear first.

Verify after updating: docker compose ps shows the pinned tag (or check the service in Dokploy), and the version in Admin Settings matches.

Lock down access

• Disable open registration. Anyone who finds your URL should not be able to create an account.
• If you use SSO, allow-list it. OIDC_ALLOWED_USERS (and the admin-side allow-list setting) restricts which identities can get in. 2.7.0 added PKCE and trusted-proxy auth for stricter setups.
• Enable the audit log (Admin Settings, 2.4.0+). After your next login, check that entries appear; an audit log you never look at is decoration.
• HTTPS always, through the reverse proxy setup above. For an SSH-credential vault on a public IP, add IP allow-listing at the proxy or a VPN front door.
• Firewall the host. My baseline for a public Docker box is in how I secured my Docker server with UFW, and CrowdSec adds brute-force protection worth having in front of any login page.
• Be careful with session-share links. 2.6.0 added sharing live terminal/RDP sessions via link with no account required. Convenient for pairing, risky by default. If you do not need it, disable it globally or per host.

Telemetry and privacy

Since 2.6.0, Termix sends a daily ping to PostHog by default. Per the README it contains a random instance ID, user and host counts, version, and feature usage. No usernames, hostnames, or IPs. That is about as benign as telemetry gets. It is still your server making a daily call you did not ask for, so make the choice explicitly.

Opt out either way: Admin Settings → General, or set ENABLE_TELEMETRY=false in the environment, which locks the toggle off for the whole instance. My take: on a personal box the env var is the set-and-forget answer.

Backups and recovery

What is in termix-data (the /app/data volume): the SQLite database, per-user encryption keys, generated SSL certs, and session recordings. Back it up like you would a database, not like a static site:

# find the exact volume name (compose prefixes it with the project name)
docker volume ls | grep termix

# tar it up
docker run --rm -v termix_termix-data:/data -v $(pwd):/backup alpine \
  tar czf /backup/termix-data-$(date +%F).tar.gz -C /data .

Ship the archive off-box (S3-compatible storage, restic, whatever you already use). The Export/Import in Admin Settings is a good supplement for hosts and credentials, but it is not a substitute for the volume backup.

Troubleshooting common Termix issues

FAQ

Final thoughts

Termix self-hosted has outgrown the “nice SSH web client” label. With remote desktop, fleet commands, and real container management in one Apache-2.0 package, it covers most of what a solo operator opens five tabs for, and the release cadence through 2026 shows a project that is very much alive. The trade-off is update discipline: run 2.5.1 or newer, pin the tag, and treat it with the respect you would give any credential vault.

If you are starting from a bare server, the Dokploy install guide gets you the deployment layer first, and the self-hosted Tailscale with Headscale setup pairs perfectly with Termix 2.7.0’s native Headscale support for reaching home labs.