Skip to main content
DBDock Cloud stores database credentials and runs jobs on your behalf, so it’s built to keep each account’s data private and its secrets protected.

Sign-in

DBDock Cloud uses OAuth — there’s no password for you to set, reuse, or leak. The same sign-in secures the dashboard, the CLI login, and the MCP server.

Credentials at rest

Connection and storage credentials you enter in the dashboard are encrypted at rest. DBDock uses them to reach your database or bucket when a job runs, and masks them in logs. They’re never exposed back to the browser or to MCP clients.

Account isolation

Every request is authenticated and scoped to your own account. You can only see and act on your own connections, backups, storage, schedules, and alerts. In a team workspace, members act on the owner’s resources by design — access is shared deliberately within the workspace, not across accounts.

Encrypted backups

Backups are encrypted with AES-256-GCM (see Encryption). Managed storage is encrypted, and backups written to your own bucket are encrypted by DBDock before they leave.

MCP access

The MCP server authenticates through the same OAuth flow and confines an assistant to your account. It lets an assistant ask DBDock to act — it never hands your database credentials to the client.

What the CLI sends

When you link a project with Cloud Sync, only non-secret metadata is uploaded. Database passwords, storage keys, encryption secrets, and webhook URLs stay on your machine. The full contract is in Data handling.

Your responsibilities

Security is shared. DBDock protects the platform; you protect the keys to your data.

Guard your encryption secret

It’s what makes a downloaded backup restorable.

Use least-privilege credentials

Give DBDock only the database and bucket permissions it needs.

Manage team access

Remove members when they no longer need access.

Report issues privately

Use private vulnerability reporting, not public issues.