How Databasus enforces security?

Databasus 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 your S3 or other cloud storages (if you enable it);

Therefore, there is a main priority for Databasus 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;
  • Databasus 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.

Databasus enforces security on three levels:

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

Level 1: sensitive data encryption

Internally, Databasus uses PostgreSQL DB to store connection details, configs, settings of notifiers and storages (S3, Azure Blob Storage, FTP, etc.).

Any sensitive data is encrypted. For example:

  • passwords
  • tokens
  • webhooks with secrets

So in DB Databasus 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 (./databasus-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. Databasus 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 ./databasus-data/secret.key)
  • Backup ID
  • Random salt (unique per backup)

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

Level 3: read-only access to DB

Databasus 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, Databasus 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, Databasus will warn you.

Databasus 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 Databasus is compromised, server is hacked, secret key is stolen and credentials are decrypted, attackers cannot corrupt your database.

Two-factor authentication at sign-in

A password alone opens every database credential, storage key and backup the instance holds, so an administrator can require a second factor for password sign-in. With it on, a correct password sends a six-digit code to the account's email address, and the sign-in finishes only once that code is entered. The code stops working ten minutes after it was sent, is discarded after five wrong guesses, and requesting another one replaces it. Turning the setting on guards the next sign-in and leaves sessions that are already open working.

The setting covers password sign-in. Signing in through Google or GitHub still issues a token directly, because those providers run their own multi-factor checks - an instance that wants the second factor to cover everybody does not configure them.

It can only be turned on when the instance has a mail server and every active administrator holds a real email address, so nobody switches it on and locks the instance out. If the mail server later stops delivering, nobody gets in with a password, which is deliberate: a broken mail server must not quietly downgrade authentication back to one factor. An operator with shell access on the server switches it off again:

docker exec -it databasus ./main --disable-2fa

The command reports what it changed and records it in the audit log, so an instance that stopped asking for codes says why. It is documented beside password recovery on the password page.

🛡️ Security & reliability engineering

Databasus handles sensitive data. Before each release, automated checks look for security issues and verify that backups can be restored. These checks reduce risk, but cannot guarantee that software is free of vulnerabilities.

Static analysis

CodeQL checks Go, JavaScript/TypeScript and GitHub Actions workflows. gitleaks scans the release's Git history for leaked secrets. semgrep checks source code, Dockerfiles and CI workflows against security rules. These scans run before each release and on a weekly schedule.

Open CRITICAL CodeQL findings in the release analysis block publication. HIGH findings produce warnings.

OpenAI's Codex Security also provides regular, deeper audits. These can find architectural issues that narrower scans may miss. They are separate from the automated release checks.

Dependency management

Ordinary updates wait seven complete days for packages, development tools and GitHub Actions, or fourteen days for images, database clients and standalone verification extensions. Maintainers check publication dates and compatibility, including exact version selections and security updates that can bypass age filters. Exceptions are reported with a reason.

Dependency Review Action compares the candidate release with the previous release and blocks newly introduced vulnerabilities rated HIGH or CRITICAL. govulncheck blocks the Go check when our code can call a function with a known vulnerability. The go mod verify command checks downloaded Go modules against their recorded checksums.

Before release and development-image publication, mise run verify-deps checks fixed versions of tools, images and GitHub Actions. It also checks that related runtime versions agree and verifies hashes and executable permissions for database clients committed to the repository. These checks cover a defined list of local declarations and files. Package managers separately verify locked versions and the checksums of downloaded packages.

The local dependency check does not certify the safety of third-party code or enforce a minimum publication age for every dependency. Release selection and review remain the maintainer's responsibility.

Container and CI security

  • Trivy scans the application image on amd64 and arm64. CRITICAL vulnerabilities with an available fix fail the check. HIGH vulnerabilities with an available fix are reported without blocking it; vulnerabilities without a fix are excluded from this check.
  • A separate Trivy configuration scan blocks HIGH and CRITICAL findings in the application, verification-agent and selected test Dockerfiles.
  • Third-party GitHub Actions are fixed to full commit SHAs. This prevents a moved tag from silently changing the action code we run.
  • Workflows default to read-only repository access. Individual jobs receive additional permissions only when needed.

Testing and verification

Unit and integration tests cover critical behavior. Before each release, full backup-and-restore tests run against real database containers for every supported engine and major version. They check that data can be restored, not just that a backup file was created.

Release checks also include lint, type checks, browser tests, image smoke tests and native amd64 and arm64 builds and tests. Publication waits for all required jobs to pass, including the security checks described above.

Reporting a vulnerability

Report vulnerabilities privately using the contact options in SECURITY.md. Please do not open a public issue. Security reports take priority.