ElectraDB
Guides

Security: TLS, passwords, IP allowlist and encryption

This page covers how connections to your database are protected and what you can control: who can connect, how credentials are handled, and how your account is secured.

1. Connect with verified TLS

Every connection string uses sslmode=verify-full. Your client encrypts the connection and checks two things: that the certificate was issued by a trusted certificate authority, and that it belongs to your database's hostname (<id>.db.electradb.com). That stops anyone from impersonating your database, even on a network they control.

The certificate comes from Let's Encrypt, a public certificate authority, so you do not need to download a CA file: your system's trusted authorities are enough.

  • psql and other libpq tools: add sslrootcert=system to the connection string (libpq 16 or later).
  • Python (psycopg): pass sslrootcert="system" (libpq 16 or later).
  • Java (JDBC): add sslfactory=org.postgresql.ssl.DefaultJavaSSLFactory to use the JVM's trusted authorities.

Ready-to-run examples for each language are in the Quickstart. Keep sslmode=verify-full: weaker modes such as require encrypt the connection but do not check who you are talking to.

2. Restrict access with an IP allowlist

Each database has an IP allowlist. Add up to 50 IP addresses or CIDR ranges, one per line, on the database page, or send them with PUT /api/v1/databases/{id}/allowlist:

{ "cidrs": ["203.0.113.0/24", "198.51.100.7"] }

When the list has entries, only those addresses can connect. An empty list allows all addresses, so set one as soon as you know where your application runs. Remember to include every address your application, CI and team connect from.

3. Database passwords

  • Each database has its own owner role (u_<id>) and password. The password is generated for you.
  • It is shown once, right after the database is created or the password is reset. Store it in your secrets manager and pass it to your app through the environment, as the Quickstart examples do.
  • Reset it on the database page or with POST /api/v1/databases/{id}/reset-password. A new password is generated and the old one stops working immediately.
  • Passwords are stored with scram-sha-256 in PostgreSQL, and our copy is encrypted at rest.
  • You get an owner role on the app database, not a superuser, and no access to the servers themselves.

4. Encryption and isolation

  • In transit: TLS on every database connection, as above.
  • Backups: encrypted on the server before upload, with a separate key for each database, and each database's backups are kept in their own storage area with their own credentials. See Backups and point-in-time restore.
  • Isolation: every database runs in its own isolated environment with network policies, so other databases on the same servers cannot reach it.
  • Location: your database and its backups stay in the region you chose. See Regions and data residency.

5. Secure your account

  • Two-factor sign-in with an authenticator app (TOTP), with one-time recovery codes. The account owner can require it for every team member.
  • Teams: invite colleagues instead of sharing a login. Removing a member ends their sessions and revokes the API keys they created.
  • API keys are shown once and stored only as a hash. Give automation a read-only key where it only needs to read: read-only keys cannot change anything and never receive a database password.
  • Deletion protection stops a database from being deleted by the dashboard or the API until you turn it off.
  • Sign-in alerts tell you when your account is used from a new browser or network.

6. Reporting a security issue

Write to the security address listed in our Legal notice. The technical and organisational measures we commit to are listed in the Data Processing Agreement.