Skip to main content

TLS & Encryption

All database connections use TLS. There is no option to disable it.

Certificate Authority​

FoundryDB issues certificates from Let's Encrypt. Certificates are automatically renewed before expiry, no action required.

The issuing CA chain is trusted by all major operating systems and runtimes. No custom CA installation is needed.

Certificate Lifecycle​

Each service domain (for example yourdb.foundrydb.com) is fronted by a publicly trusted certificate that the platform obtains and maintains for you over the ACME protocol.

TLS certificate provisioning & auto-renewal
Certificate issued · installed · serving verified TLS
FoundryDBcert managerACME →Let's EncryptACME CAinstall →ServiceTLS 1.2/1.3verify-full →Clientverifies
FoundryDB cert managerLet's Encrypt (ACME CA)Issued · installed · servingService endpointACME challenge

The certificate is provisioned and kept current automatically:

  1. Order. The platform places an ACME order with Let's Encrypt for the service domain.
  2. Validate. Let's Encrypt issues a challenge. The platform answers it to prove it controls the domain, then Let's Encrypt verifies the answer.
  3. Issue. Let's Encrypt signs and returns the leaf certificate together with its CA chain.
  4. Install. The certificate and chain are installed on the service endpoint and the engine begins serving them.
  5. Serve. Clients connect over TLS 1.2 or 1.3 and verify the certificate and hostname.

Automatic Renewal​

Let's Encrypt certificates are short-lived. Well before a certificate expires, the platform automatically re-runs the order, validate, and issue steps, then hot-installs the renewed certificate on the service endpoint. Renewal needs no downtime and no action from you. Because renewal stays ahead of expiry, clients always see a valid certificate.

Where TLS Terminates​

TLS terminates at the service endpoint your client connects to: the database engine (or its in-front proxy) on the service VM, presenting the Let's Encrypt certificate for your service domain. For engines that expose a connection pooler (PgBouncer for PostgreSQL, ProxySQL for MySQL), TLS terminates at the pooler's TLS port. The platform does not man-in-the-middle your traffic between separate hops; the cert your client validates is the cert the endpoint serves.

Most engines negotiate TLS in two styles, both reflected in the ports table below:

  • STARTTLS / protocol-level upgrade (PostgreSQL, MySQL, SQL Server): the client connects on the standard port and upgrades the plaintext handshake to TLS before any credentials are sent.
  • Direct TLS (MongoDB, Valkey, Kafka, OpenSearch): the TLS handshake happens immediately on connect, before any application protocol bytes.

Verify a Certificate​

# PostgreSQL
echo | openssl s_client -connect yourdb.foundrydb.com:5432 -starttls postgres 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

# MySQL
echo | openssl s_client -connect yourdb.foundrydb.com:3306 -starttls mysql 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

# MongoDB, Valkey, Kafka, OpenSearch (direct TLS)
echo | openssl s_client -connect yourdb.foundrydb.com:27017 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

TLS Ports​

EnginePortProtocol
PostgreSQL5432TLS via STARTTLS
PostgreSQL (PgBouncer)5433TLS via STARTTLS
MySQL3306TLS via STARTTLS
MySQL (ProxySQL)6033TLS via STARTTLS
MongoDB27017Direct TLS
Valkey6380Direct TLS
Kafka9093Direct TLS (SASL_SSL)
OpenSearch9200HTTPS
SQL Server (Babelfish)1433TLS

TLS Version​

All endpoints negotiate TLS 1.2 or TLS 1.3. TLS 1.0 and 1.1 are not accepted.

Client Configuration​

Verification is the client's half of the handshake the diagram ends on. Each driver exposes a verify mode that decides how strictly it checks the certificate the endpoint presents:

  • Verify cert and hostname (PostgreSQL verify-full, MySQL VERIFY_IDENTITY): the client validates the chain against the system CA bundle and confirms the certificate was issued for the hostname it connected to. This is the recommended mode and the one shown in the diagram; it defeats both eavesdropping and impersonation.
  • Verify cert only (PostgreSQL verify-ca, MySQL VERIFY_CA): the chain is validated but the hostname is not, so a valid certificate for a different name would still be accepted.
  • Encrypt only (PostgreSQL require, MySQL REQUIRED): traffic is encrypted but the certificate is not verified, leaving the connection open to impersonation.

Because the platform serves a publicly trusted Let's Encrypt certificate matching your service domain, the strict verify modes work out of the box with the system CA bundle, with no custom truststore or pinned certificate required.

PostgreSQL (sslmode)​

sslmodeBehaviour
verify-fullVerify server cert and hostname (recommended)
verify-caVerify cert but not hostname
requireEncrypt, skip verification

Recommended:

PGPASSWORD=secret psql "host=yourdb.foundrydb.com user=app sslmode=verify-full"

MySQL (--ssl-mode)​

ssl-modeBehaviour
VERIFY_IDENTITYVerify cert + hostname (recommended)
VERIFY_CAVerify cert only
REQUIREDEncrypt, skip verification
mysql -h yourdb.foundrydb.com -u app -p --ssl-mode=VERIFY_IDENTITY

MongoDB​

mongodb://app:secret@yourdb.foundrydb.com:27017/defaultdb?tls=true

Valkey (redis-cli)​

redis-cli -h yourdb.foundrydb.com -p 6380 --tls --user app --pass secret

Kafka​

Configure ssl.truststore with the system CA bundle, and security.protocol=SASL_SSL.

security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-256
ssl.truststore.location=/etc/ssl/certs/ca-certificates.crt

Encryption at Rest​

Storage Volumes​

All storage volumes are encrypted at rest using AES-256 at the infrastructure level. This is enforced by default and cannot be disabled. Encryption covers:

  • Database storage where your live data resides
  • Backup storage for local backups and write-ahead logs
  • System storage including the database engine

Encryption is transparent to your application with no performance impact. You can verify the status of any service:

curl -u admin:password https://api.foundrydb.com/managed-services/{id} \
  | jq '.storage_encrypted'
# true

Credentials​

All sensitive data stored by the platform (database passwords, API tokens, connection strings) is encrypted with AES-256-GCM before being persisted. Credentials are never stored in plaintext.

Backups​

Backups are encrypted with AES-256-GCM before upload to object storage. Each backup receives a unique encryption key. Both scheduled and on-demand backups are encrypted by default.