Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Termix-SSH/Termix/llms.txt

Use this file to discover all available pages before exploring further.

Termix ships with built-in SSL support. When you enable it, the container generates a self-signed TLS certificate on first start, configures nginx to serve HTTPS, and automatically redirects all plain HTTP requests to the secure port. For public-facing production deployments you can either supply your own certificate or terminate TLS at an external reverse proxy.

​
How the built-in SSL works

Termix runs an nginx reverse proxy inside the container that fronts all backend services. Two nginx configurations are included:
  • HTTP-only (nginx.conf) — the default; listens on PORT only.
  • HTTPS with HTTP redirect (nginx-https.conf) — activated when ENABLE_SSL=true; listens on both PORT (redirects to HTTPS) and SSL_PORT (serves HTTPS with HSTS).
On startup, the entrypoint script:
  1. Checks whether a certificate already exists at SSL_CERT_PATH.
  2. If a certificate exists, validates that it does not expire within the next 30 days. If it is expired or expiring soon, it is deleted and regenerated.
  3. If no certificate exists, generates a 2048-bit RSA self-signed certificate valid for 365 days using OpenSSL.
  4. Writes the rendered nginx config to /tmp/nginx/nginx.conf and starts nginx.
The HTTPS nginx configuration sets Strict-Transport-Security (max-age=31536000; includeSubDomains) and enforces TLS 1.2 and TLS 1.3 with strong cipher suites.
Self-signed certificates cause browser warnings. For production use either supply a certificate from a trusted CA or place Termix behind a reverse proxy that handles TLS termination.

​
Enabling built-in HTTPS

1

Set the SSL environment variables

Add the following to your docker-compose.yml:
docker-compose.yml
services:
  termix:
    image: ghcr.io/lukegus/termix:latest
    ports:
      - "8080:8080"
      - "8443:8443"
    volumes:
      - termix-data:/app/data
    environment:
      PORT: "8080"
      ENABLE_SSL: "true"
      SSL_PORT: "8443"
      SSL_DOMAIN: "termix.example.com"
SSL_DOMAIN is embedded in the generated certificate’s CN and Subject Alternative Name. If you are using a real domain, set this to that domain name.
2

Start the container

docker compose up -d
On first start you will see log lines similar to:
SSL enabled - using HTTPS configuration with redirect
Generating SSL certificates for domain: termix.example.com
SSL certificates generated successfully for domain: termix.example.com
3

Access Termix over HTTPS

Navigate to https://your-host:8443. The browser will show a certificate warning for self-signed certificates; you can bypass this for internal/home-lab use or replace the certificate with one from a trusted CA (see below).HTTP requests to port 8080 are redirected to HTTPS automatically.

​
Supplying your own certificate

If you have a certificate from a trusted CA (e.g. Let’s Encrypt), mount it into the container and point the SSL variables at it:
docker-compose.yml
services:
  termix:
    ports:
      - "8080:8080"
      - "8443:8443"
    volumes:
      - termix-data:/app/data
      - /etc/letsencrypt/live/termix.example.com/fullchain.pem:/app/data/ssl/termix.crt:ro
      - /etc/letsencrypt/live/termix.example.com/privkey.pem:/app/data/ssl/termix.key:ro
    environment:
      PORT: "8080"
      ENABLE_SSL: "true"
      SSL_PORT: "8443"
      SSL_CERT_PATH: "/app/data/ssl/termix.crt"
      SSL_KEY_PATH: "/app/data/ssl/termix.key"
When you supply your own certificate Termix will still check the expiry date at startup. If the certificate expires within 30 days of startup, Termix will delete it and generate a new self-signed certificate in its place. Ensure you renew and remount your certificate before that window.
For production deployments, run Termix in HTTP-only mode (the default) and handle TLS at a reverse proxy. This is the recommended approach because it lets a single proxy manage certificates for multiple services. Termix’s nginx config already passes through X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Host, and X-Forwarded-Port headers, so Termix correctly detects the original client IP and scheme when sitting behind a proxy.
Termix uses WebSockets for SSH terminal connections (/ssh/websocket/) and SSH tunnels (/ssh/tunnel/). Your reverse proxy must upgrade WebSocket connections or terminal sessions will not work.
nginx.conf
server {
    listen 80;
    server_name termix.example.com;
    return 301 https://$host$request_uri;
}

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

    ssl_certificate     /etc/letsencrypt/live/termix.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/termix.example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;

    # Required for WebSocket support (SSH terminal, tunnels)
    proxy_http_version  1.1;
    proxy_set_header    Upgrade $http_upgrade;
    proxy_set_header    Connection "upgrade";

    proxy_set_header    Host              $http_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_set_header    X-Forwarded-Host  $http_host;
    proxy_set_header    X-Forwarded-Port  $server_port;

    proxy_read_timeout  86400s;
    proxy_send_timeout  86400s;

    location / {
        proxy_pass http://127.0.0.1:8080;
    }
}

​
SSL environment variable reference

VariableDefaultDescription
ENABLE_SSLfalseSet to "true" to activate HTTPS mode
SSL_PORT8443Port for the HTTPS listener
SSL_CERT_PATH/app/data/ssl/termix.crtPath to the TLS certificate
SSL_KEY_PATH/app/data/ssl/termix.keyPath to the TLS private key
SSL_DOMAINlocalhostDomain embedded in the auto-generated certificate
See Environment Variables for the full variable reference.

Build docs developers (and LLMs) love

Get started for freeTalk to us