PlanetScale SSL: Configure Secure Connections (2026)

PlanetScale uses SSL/TLS to encrypt the data flowing between your application and the database, preventing eavesdropping and ensuring data integrity.

Let’s see PlanetScale’s SSL in action. Imagine you have a Node.js application using the mysql2 driver to connect to your PlanetScale database.

const mysql = require('mysql2');

const connection = mysql.createConnection({
  host: 'your_planetscale_host.psdb.cloud',
  user: 'your_username',
  password: 'your_password',
  database: 'your_database_name',
  ssl: {
    rejectUnauthorized: false // For initial testing, but NOT recommended for production
  }
});

connection.connect(function(err) {
  if (err) {
    console.error('Database connection failed: ' + err.stack);
    return;
  }
  console.log('Connected to PlanetScale database as id ' + connection.threadId);
});

This code snippet establishes a connection. The crucial part for SSL is the ssl object within the connection configuration. By default, PlanetScale requires SSL.

The core problem PlanetScale’s SSL solves is that of man-in-the-middle attacks. Without encryption, an attacker could intercept the network traffic between your application and the database, reading sensitive data like user credentials or financial information, or even modifying it. SSL/TLS establishes a secure, encrypted tunnel using public-key cryptography. When your client (your application) connects, it negotiates a secure session with the PlanetScale server. The server presents its SSL certificate, which your client verifies. If verification succeeds, they both agree on a symmetric encryption key to use for the rest of the session.

Here’s how it works under the hood for PlanetScale:

1. Client Hello: Your application initiates a connection and sends a "Client Hello" message. This message includes the TLS versions it supports and a list of cipher suites it can use.
2. Server Hello: PlanetScale’s database server responds with a "Server Hello," selecting the TLS version and cipher suite to use. It also sends its SSL certificate.
3. Certificate Verification: Your application’s TLS library checks the PlanetScale certificate. This involves verifying its signature against a trusted Certificate Authority (CA). PlanetScale provides its root CA certificate for this purpose.
4. Key Exchange: Your application and the PlanetScale server perform a key exchange (e.g., using RSA or Diffie-Hellman) to securely generate a shared secret. This secret is used to derive the symmetric encryption keys for the session.
5. Encrypted Communication: Once the handshake is complete, all subsequent data exchanged between your application and the database is encrypted using the agreed-upon symmetric keys.

The primary lever you control is the ssl configuration in your database connection string or object. For most drivers, this involves a boolean ssl: true or an object with more granular options. PlanetScale strongly recommends using the CA certificate to verify the server’s identity.

To get the PlanetScale CA certificate, you can usually find it in your PlanetScale dashboard under connection settings, or download it directly from a trusted source like DigiCert. For example, if you’re using Node.js mysql2 and want to properly verify the certificate:

const mysql = require('mysql2');
const fs = require('fs');

const connection = mysql.createConnection({
  host: 'your_planetscale_host.psdb.cloud',
  user: 'your_username',
  password: 'your_password',
  database: 'your_database_name',
  ssl: {
    ca: fs.readFileSync('/path/to/your/planetscale_ca.pem')
  }
});

connection.connect(function(err) {
  if (err) {
    console.error('Database connection failed: ' + err.stack);
    return;
  }
  console.log('Connected securely to PlanetScale database as id ' + connection.threadId);
});

Here, fs.readFileSync('/path/to/your/planetscale_ca.pem') loads the certificate file, and passing it to the ca option tells the client to use this CA to validate the server’s certificate. This rejectUnauthorized: true (which is the default when ca is provided) is what prevents man-in-the-middle attacks.

A common point of confusion is rejectUnauthorized. When set to false, your client will not verify the server’s certificate. This allows connections even if the certificate is expired, self-signed, or issued by an untrusted CA, making it vulnerable. While useful for quick local testing where you might not have the CA readily available, it should never be used in production. The ssl object in PlanetScale’s connection details often includes ssl:{ rejectUnauthorized: false } for ease of initial setup, but the documentation explicitly states this is for compatibility and not recommended for production.

The next challenge you’ll encounter is managing different SSL configurations for various environments (development, staging, production) and ensuring your application’s dependencies are up-to-date with trusted CA bundles.