Keep connection configuration out of code

Connection details change more often than code. The database moves to a new host, a password rotates after someone leaves, staging points at a different server than production. If those values live in your source files, every change means a code change, a commit, and a redeploy — and the secrets sit in git history forever.

Keep the host, port, full account name, password, and database in deployment secrets. Do not commit them, print them in logs, or put them in browser code.

Locally that usually means an env file that stays out of version control:

# .env — listed in .gitignore
DB_HOST=127.0.0.1
DB_PORT=3306
DB_USER=notes_app
DB_PASSWORD=replace-with-a-generated-secret
DB_NAME=notes_app

In production, use your platform’s secret store instead of a file. The code reads process.env either way, so nothing changes between environments except the values.

Verify the wiring at startup by logging the non-secret parts:

console.log(`db: ${process.env.DB_USER}@${process.env.DB_HOST}/${process.env.DB_NAME}`)

Never log the password. This one line catches the classic mistake where production quietly loaded staging values.

Use a short connection timeout and a bounded pool queue. They turn a network or capacity problem into a controlled failure instead of an unlimited wait.

TLS for remote connections

Remote database connections need TLS. Use the certificate authority supplied by the hosting provider:

ssl: {
  ca: process.env.DB_CA,
  minVersion: 'TLSv1.2',
}

When TLS is misconfigured, the driver fails with a certificate error such as self-signed certificate in certificate chain or a hostname mismatch. Do not fix certificate errors with rejectUnauthorized: false. That setting keeps the encryption but stops verifying who you are encrypting to, which allows a machine-in-the-middle to read your credentials and data. Fix the CA, hostname, or provider configuration instead.