Manage credentials

Store, update, and rotate the credentials Backup uses to connect to your database.

Credentials live on the data source. Backup stores them KMS-encrypted; the plaintext is decrypted only inside the backup worker for the duration of a single job.

Provide credentials

After creating a data source, the credentials page opens automatically. You can also reach it later from the data source's detail view → Credentials.

Two input modes:

Paste a complete URI:

Postgres

postgresql://user:password@host:5432/dbname?sslmode=require

MongoDB

mongodb://user:password@host:27017/dbname?tls=true&authSource=admin

Backup parses and stores the URI as-is.

Fill in:

Host – DNS name or IP.
Port – database port.
User / Password – authentication.
Database name – the database (Postgres) or default database (Mongo) to back up.
Mongo-specific: authSource, scheme (mongodb vs mongodb+srv).

Click Save credentials. They're encrypted before they hit the Backup database; see Encryption and security.

When you save credentials, the dashboard automatically chains a connection test before redirecting you back to the data source detail page – so most of the time, a green badge appears without you clicking anything.

You can re-run the test on demand from the data source page if you ever change your firewall or want a fresh sanity check.

Rotate credentials

Generate new credentials in your database

ALTER USER ... PASSWORD '...' for Postgres or db.updateUser(...) / db.createUser(...) for Mongo.

Update the data source

Open the data source in the dashboard → Credentials → Edit. Paste the new URI or update individual fields.

Save

The dashboard auto-verifies after save; watch for the green badge. Future scheduled backups use the new credentials immediately. Any in-flight backup using the old credentials finishes normally.

Revoke the old role

After the next scheduled backup completes successfully on the new credentials, you can revoke or delete the old database role.

Use a read-only role

Backup only needs read access. Running with reduced privileges limits the blast radius if the credentials ever leak.

CREATE ROLE norcube_backup LOGIN PASSWORD '...';
GRANT pg_read_all_data TO norcube_backup;
GRANT pg_read_server_files TO norcube_backup;  -- if your dump needs extensions

db.createUser({
  user: 'norcube_backup',
  pwd: '...',
  roles: [{ role: 'read', db: 'myDatabase' }],
});