Termix is configured primarily through environment variables passed to the Docker container. Most settings have sensible defaults so a minimal deployment only needsDocumentation 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.
PORT, but you can tune everything from the HTTP port to every detail of your OIDC provider.
Core variables
The port that the internal nginx reverse proxy listens on. Map the same port on the host side in your
ports declaration.docker-compose.yml
Absolute path inside the container where Termix stores its encrypted SQLite databases, SSL certificates, and other persistent data. Mount a Docker volume here so data survives container restarts.
The UID that the
node process user is remapped to inside the container. Set this to match your host user to avoid permission issues on the mounted volume.The GID that the
node process group is remapped to inside the container.bcrypt cost factor used when hashing passwords. Higher values are more secure but make login slower. The default of
10 is appropriate for most deployments; values between 10 and 14 are typical.SSL variables
Set to
"true" to activate the HTTPS nginx configuration. When enabled, Termix generates a self-signed TLS certificate on first start and reconfigures nginx to redirect all HTTP traffic to the SSL port.The port that the HTTPS listener binds to when
ENABLE_SSL=true. Make sure to expose this port in your ports mapping.Path to the TLS certificate file. Termix reads this path when configuring nginx. If you supply your own certificate, write it to this path (or change the variable to match your certificate location) before starting the container.
Path to the TLS private key file that pairs with
SSL_CERT_PATH.The domain name embedded in the auto-generated self-signed certificate’s CN and Subject Alternative Name fields. Set this to your actual domain when using the built-in SSL so that browsers show the correct hostname.
OIDC variables
These variables let you pre-configure an OIDC provider at container startup rather than entering the settings through the admin UI. All five marked required must be present together; if any are missing, the environment-based OIDC config is ignored and you must configure OIDC through the UI instead.The client ID issued by your identity provider when you registered the Termix application.
The client secret issued by your identity provider.
The issuer URL of your OIDC provider (e.g.
https://accounts.example.com). Termix appends /.well-known/openid-configuration to this URL during discovery.The authorization endpoint URL where Termix redirects users to log in with your provider.
The token endpoint URL that Termix calls to exchange an authorization code for tokens.
The userinfo endpoint URL. When omitted, Termix discovers the endpoint from
.well-known/openid-configuration or falls back to common paths automatically.A dot-separated path into the userinfo payload that Termix uses as the unique identifier for each OIDC user. Common values are
sub, email, or preferred_username. Nested paths like profile.id are supported.A dot-separated path into the userinfo payload from which Termix reads the display name to show in the UI.
Space-separated list of OAuth 2.0 scopes requested during authorization. Adjust if your provider requires additional scopes to return the claims you configured in
OIDC_IDENTIFIER_PATH and OIDC_NAME_PATH.Comma-separated list of identifiers or patterns that are permitted to sign in via OIDC. When empty, any successfully authenticated OIDC user is allowed. See the Authentication page for pattern syntax.
Set to
"true" to allow new accounts to be created automatically when an OIDC user logs in for the first time, independently of the global registration toggle. When "false", new OIDC users can only be created if the global allow_registration setting is enabled in the admin UI.Minimal docker-compose example
docker-compose.yml
OIDC example
docker-compose.yml
OIDC settings configured via environment variables take precedence over settings saved through the admin UI. To use the UI-based configuration instead, omit all
OIDC_* variables from your container environment.