⭐ SSL Subsystem

The SSL Subsystem is responsible for generating, storing, and mounting TLS certificates for all database engines that support encrypted connections. It ensures secure transport between clients and database containers by providing a consistent, predictable certificate workflow across MySQL, PostgreSQL, Redis, KeyDB, Dragonfly, and MongoDB.

This page explains how the SSL subsystem works, how certificates are generated, where they are stored, and how StartActions integrate with it.

Purpose of the SSL Subsystem The SSL subsystem provides:

Automatic certificate generation

Automatic CA creation

Engine‑specific certificate mounting

Predictable directory structure

Secure defaults

Integration with all StartActions

TLS enforcement for supported engines

It ensures every database can be started with secure transport without requiring manual certificate management.

Supported Database Engines

Engine	SSL/TLS Support
MySQL	Yes
PostgreSQL	Yes
Redis	Yes
KeyDB	Yes
Dragonfly	Yes
MongoDB	Yes

Every engine that supports TLS is fully integrated with the SSL subsystem.

Certificate Types Generated The SSL subsystem generates three certificate components:

1. CA Certificate A root certificate authority used to sign server certificates.

2. Server Certificate A certificate specific to the database instance.

3. Server Key The private key associated with the server certificate.

These files are used by the database engine to enable TLS.

Directory Structure All certificates are stored under a predictable directory:

Code /data/coolify/ssl// Inside this directory:

Code ca.pem server.pem server.key This structure is identical for all engines.

Certificate Generation Workflow mermaid flowchart TD A[StartAction] --> B[Request SSL] B --> C[Generate CA] C --> D[Generate Server Certificate] D --> E[Generate Server Key] E --> F[Store Certificates] F --> G[Mount into Container] G --> H[Configure Engine for TLS] How StartActions Use SSL Each StartAction integrates with the SSL subsystem in a consistent way:

1. Request Certificates If the database configuration enables SSL, the StartAction requests certificate generation.

2. Mount Certificates Certificates are mounted into engine‑specific directories: | Engine | Mount Path | |-------------|------------------------| | MySQL | /etc/mysql/ssl | | PostgreSQL | /etc/postgresql/ssl | | Redis | /etc/redis/ssl | | KeyDB | /etc/keydb/ssl | | Dragonfly | /etc/dragonfly/ssl | | MongoDB | /etc/mongodb/ssl |

3. Configure TLS Flags StartActions pass engine‑specific TLS flags:

MySQL --ssl-ca --ssl-cert --ssl-key

PostgreSQL ssl = on ssl_ca_file ssl_cert_file ssl_key_file

Redis / KeyDB / Dragonfly --tls-port --tls-cert-file --tls-key-file --tls-ca-cert-file

MongoDB --tlsMode --tlsCertificateKeyFile --tlsCAFile

4. Inject Environment Variables StartActions expose certificate paths via environment variables: *_SSL_CA *_SSL_CERT *_SSL_KEY

(Engine‑specific prefixes vary.)

Security Considerations

1. Private Key Protection Server keys are stored with strict permissions.

2. Predictable Directory Isolation Each database instance has its own certificate directory.

3. No Shared Certificates Every database receives unique certificates.

4. Automatic Regeneration Certificates are regenerated if missing or invalid.

Example Certificate Directory /data/coolify/ssl/12345/ ca.pem server.pem server.key Where 12345 is the database ID.

Example Compose Snippet (Conceptual) Code volumes:

• /data/coolify/ssl/:/etc/mysql/ssl

environment: MYSQL_SSL_CA=/etc/mysql/ssl/ca.pem MYSQL_SSL_CERT=/etc/mysql/ssl/server.pem MYSQL_SSL_KEY=/etc/mysql/ssl/server.key Why the SSL Subsystem Matters The SSL subsystem ensures:

Secure transport

Predictable certificate handling

Engine‑specific TLS configuration

Consistent mounting paths

Automatic certificate lifecycle

Zero manual certificate management

It is a foundational part of the platform’s security model.