How Postgresus enforces security?

Postgresus is responsible for sensitive data:

  • it accesses your DB;
  • it backs it up (meaning makes a copy of data);
  • it keeps credentials to be able to access your DB on a regular basis;
  • it saves backups in cloud storages (if you enable it) - so other people can see them;

Therefore, there is a main priority for Postgresus to be enterprise-level secure and reliable.

To make sure:

  • sensitive data is never exposed and always encrypted;
  • backups are encrypted and useless even if someone sees them in the cloud storage;
  • Postgresus doesn't even receive access to DB with write or update access;
  • all actions are logged and can be audited;

All these steps protect your data. As you know, there is no 100% secure system, but we do our best to make it as secure as possible. Even in case of hacking, nobody will be able to corrupt your data.

Postgresus enforces security on three levels:

  1. Sensitive data encryption;
  2. Backups encryption;
  3. Read-only access to DB.

Level 1: sensitive data encryption

Internally, Postgresus uses PostgreSQL DB to store connection details, configs, settings of notifiers and storages (S3, Google Drive, Dropbox, etc.).

Any sensitive data is encrypted. For example:

  • passwords
  • tokens
  • webhooks with secrets

So in DB Postgresus keeps only hashes or encoded values. For encryption is used AES-256-GCM algorithm. Also, despite the encryption, those values are never exposed via API or UI.

The secret key used for encryption is stored on local storage (./postgresus-data/secret.key by default) and is not present in the DB itself. So DB compromise doesn't give access to sensitive data.

Level 2: backups encryption

Each backup file is encrypted on the fly during backup creation. Postgresus uses AES-256-GCM encryption algorithm, which ensures that backup data cannot be read without the encryption key and any tampering is detected during decryption.

Backups flow through this pipeline:

PostgreSQL pg_dump → Compression → Encryption → Cloud Storage

Each backup gets its own unique encryption key derived from:

  • Master key (stored in ./postgresus-data/secret.key)
  • Backup ID
  • Random salt (unique per backup)

Result: Even if someone gains access to your cloud storage (S3, Google Drive, etc.), they cannot read the backups without your master key.

Level 3: read-only access to DB

Postgresus enforces the principle of least privilege - it only needs read access to create backups, never write access. This protects your database from accidental or malicious data corruption through the backup tool.

Before accepting database credentials, Postgresus performs checks across three levels:

  1. Role-level: Verifies the user is NOT a superuser and cannot create roles or databases
  2. Database-level: Ensures no CREATE or TEMP privileges
  3. Table-level: Confirms zero write permissions (INSERT, UPDATE, DELETE, TRUNCATE, etc.)

The database user must pass all three checks to be considered read-only. If any write privilege is detected, Postgresus will warn you.

Postgresus suggests creating read-only users for you with proper permissions:

  • Grants SELECT on all current and future tables
  • Grants USAGE on schemas (but not CREATE)
  • Explicitly revokes all write privileges

Result: Even if Postgresus is compromised, server is hacked, secret key is stolen and credentials are decrypted, attackers cannot corrupt your database.