Connection Security
TLS encrypts connections between Dispatcharr and external Redis/PostgreSQL services in modular deployments. This prevents credentials and data from being sent in plaintext over the network.
Note
Connection security is only available in modular deployment mode. AIO mode uses internal services that do not require encryption.
Overview¶
Three levels of connection security are supported:
| Level | What it does | When to use |
|---|---|---|
| TLS | Encrypts traffic between Dispatcharr and the database | Connections cross a network boundary |
| TLS + Server Verification | Encrypts traffic and verifies the server's identity using a CA certificate | Protecting against man-in-the-middle attacks |
| Mutual TLS (mTLS) | Both sides verify each other with certificates | The database server requires client authentication |
Each level builds on the previous one. You can enable encryption without verification, or verification without mutual TLS.
Certificate Volume Mount¶
Server verification and mutual TLS require certificate files to be accessible inside the container. If you are only encrypting the connection without verification, no certificate files are needed.
Mount a directory containing your certificates as a read-only volume:
Mount the same volume on both the web and celery services.
Redis TLS¶
| Variable | Required | Description |
|---|---|---|
REDIS_SSL |
Yes | Set to true to enable TLS |
REDIS_SSL_VERIFY |
No | Verify the server's identity (default: true). Set to false for self-signed certs without a CA |
REDIS_SSL_CA_CERT |
No | Path to the CA certificate used to verify the server |
REDIS_SSL_CERT |
No | Path to the client certificate (only if the server requires client authentication) |
REDIS_SSL_KEY |
No | Path to the client private key (only if the server requires client authentication) |
Redis TLS — encrypted with server verification
Redis mTLS — mutual authentication
PostgreSQL TLS¶
| Variable | Required | Description |
|---|---|---|
POSTGRES_SSL |
Yes | Set to true to enable TLS |
POSTGRES_SSL_MODE |
No | How strictly to verify the server (default: verify-full). Options: verify-full, verify-ca, require |
POSTGRES_SSL_CA_CERT |
No | Path to the CA certificate used to verify the server |
POSTGRES_SSL_CERT |
No | Path to the client certificate (only if the server requires client authentication) |
POSTGRES_SSL_KEY |
No | Path to the client private key (only if the server requires client authentication) |
Verification modes:
verify-full— verifies the server certificate and checks that the hostname matches (most secure, default)verify-ca— verifies the server certificate but does not check the hostnamerequire— encrypts the connection but does not verify the server's identity
PostgreSQL TLS — encrypted with full verification
PostgreSQL TLS — encrypted, no verification
PostgreSQL mTLS — mutual authentication
Important Notes¶
- TLS environment variables must match across the
webandceleryservices - Certificate paths refer to paths inside the container, not on the host
- Dispatcharr validates certificate file paths at startup and will fail with a clear error message if a file is not found
- If you override
REDIS_URLorCELERY_BROKER_URLwith a custom value, the URL scheme (redis://vsrediss://) must match theREDIS_SSLsetting. Most users do not need to set these — Dispatcharr builds the URL automatically - The Connection Security panel in System Settings displays the current TLS status for each service