The rule
Only non-secret metadata syncs. Credentials never do. DBDock builds the sync payload directly from yourdbdock.config.json, and the collector drops every secret before anything is sent. Where a secret’s presence is useful (for example, “encryption is enabled”), it’s represented as a boolean flag — never the value.
What syncs
Connection
Connection
Database
type, host, port, database name, and user. Not the password.Storage
Storage
Provider and non-secret settings such as bucket name, region, and endpoint. Not access keys, secret keys, or API secrets — those are represented only as presence flags.
Backup settings
Backup settings
Format, whether compression is enabled, whether encryption is enabled, and retention settings. Not the encryption secret.
Schedules
Schedules
Schedule name, cron expression, and enabled state.
Alerts
Alerts
Channel type and non-secret settings. Not webhook URLs, Slack tokens, or SMTP passwords.
What never syncs
Your backups themselves are also not part of sync. Sync mirrors configuration metadata, not backup files or database contents. Backup files go to your chosen storage; Cloud Sync only records that a backup exists and its non-sensitive attributes.Why it’s built this way
Secrets belong in your environment, not in a config file and not in a remote mirror. This is the same principle the CLI follows everywhere — seedbdock migrate-config, which moves secrets out of config files into environment variables. Cloud Sync extends that principle across the wire: the dashboard can show you what you have configured without ever holding the keys to it.
Where it’s stored locally
The link and last-synced state live in your project under.dbdock/. Your global credentials live under ~/.dbdock/ (override with DBDOCK_HOME). Add .dbdock/ to your .gitignore if you don’t want the link committed.
Related
Cloud security
How the cloud stores and isolates data.
Key management
Where secrets should live.