What dbtempo can reach, what it keeps, and what it can change.
This page is for the person who has to approve connecting a production database. Each answer describes what the code does today; the security model in the docs goes further.
Where credentials live, per connection method
| Method | Who connects | Where the credentials are |
|---|---|---|
| Direct | dbtempo’s managed runner connects to your database. | The password is sealed with a key only the collection worker can open: an X25519 key agreement and AES-256-GCM. The web application that stores it holds only the public half, so it cannot read the password back. |
| SSH tunnel | The managed runner connects through your SSH bastion. | The database password, the SSH private key and its passphrase are each sealed the same way. |
| dbtempo agent | The agent runs in your network and makes every database connection. dbtempo’s servers never connect to the database. | A password you enter in the dashboard is encrypted, handed to the agent in the reply to its own request, and written to the agent’s local config file, readable only by the agent’s user. Queue rows that carried it are deleted after a day. |
What a collection sends
Query statistics, example query text, schema and index metadata, execution plans and server configuration. A collection payload carries no table rows, and payloads are deleted after thirty days.
Where you connect a repository, dbtempo keeps the file spans it needs to locate the queries it analyzes, not a copy of the repository.
The read-only guard
Every statement the analysis tools send to a database passes a statement-aware guard. It refuses a payload with more than one statement, refuses EXPLAIN ANALYZE, and accepts only statements that begin with EXPLAIN, SHOW, SELECT, DESCRIBE or PRAGMA. It reads quotes and comments, so a second statement cannot hide inside one.
On PostgreSQL, plans are read without running the query unless a project owner turns on query execution for that project.
What stands between a recommendation and your database
- Permissions per project and per kind of change: Off, Ask me first, or Apply automatically. Everything starts off.
- Ask me first sends the change to the Awaiting approval queue; nothing runs until someone approves it.
- An allowed change still passes the safety gates, and you can limit changes to a maintenance window. Changes that briefly stall the server always need one.
- Every write attempted is on the database’s audit trail, including the ones a guardrail blocked. Plans that include it export the trail as CSV.
- Every applied change keeps the SQL that reverses it. Index removals are never applied unattended.
- Code changes open as draft pull requests through the GitHub App; dbtempo does not merge them. Code pasted into a thread never opens a pull request.
API keys
CLI API keys are checked against a SHA-256 hash. An AES-256-GCM encrypted copy is kept so the dashboard can show a key again.
Certifications
dbtempo holds no security certification and claims none. If a certification or an independent audit report is a requirement for you, ask before you rely on it.