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.

