Skip to main content
Rotating a database password used to mean opening every connection that used it. Create one profile in Settings > Profiles, point those connections at it, and the next rotation is a single edit.

​
Create a profile

Credential profiles and SSH servers, with the connections using eachCredential profiles and SSH servers, with the connections using each

Settings > Profiles

1

Open Settings > Profiles

Credential Profiles is the first section.
2

Click Add Credential Profile…

Give it a name, a username, and pick where the password comes from.
3

Click Create

Every connection’s Credentials picker now offers it.
Save These as a Profile… on a connection that already has credentials filled in does the same thing without retyping them.

​
Point a connection at one

A connection signing in through a credential profileA connection signing in through a credential profile

The Credentials picker on a connection's Authentication section

Credentials sits at the top of the Authentication section. Enter Below is the default and keeps today’s behavior: the username and password belong to that connection alone. Picking a profile replaces both fields with a read-only summary, and the connection signs in with whatever the profile holds at the moment it connects. A linked connection keeps no password of its own. Linking deletes the one it had, so an encrypted export of it carries nothing and Duplicate copies the link rather than the secret.

​
Where the password comes from

Pick Saved in the Keychain unless something else already owns the password. Read from elsewhere never leaves this Mac and never syncs. Test Source runs a Read from elsewhere source without connecting. It shows the password hidden, or the error with what the command printed to stderr. Show password reveals it after Touch ID or your Mac’s password, and does the same for a password saved in the Keychain. A connection using the profile has its own Test Source, which fills in that connection’s host, port, user and database.

​
Vault database roles

A role on Vault’s database secrets engine hands out a new database user for every lease. Set Source to Read from elsewhere and Read From to HashiCorp Vault database role, then fill in: The username field greys out, because Vault generates the username too. Test Source reads a lease, shows the username and password it got, and revokes it. Each sign-in reads a new lease, so the main connection, a second database, and a backup each sign in as a user of their own. While connected, the lease renews before it expires. When Vault stops renewing it, at the role’s maximum TTL or when renewal fails, the connection signs in again with a new lease before the old user is revoked. Disconnecting revokes the lease. The generated password stays in memory: it never reaches the Keychain, connections.json, or iCloud. An OIDC role must allow the redirect URI http://localhost:8250/oidc/callback, the one vault login -method=oidc uses. A connection that needs an OIDC sign-in offers Sign In instead of failing.

​
A command that works for every connection

The output of a command runs in bash for whichever connection is opening. Write {host}, {port}, {user} and {database} where the command needs them, and each becomes that connection’s value as one quoted word, with or without quotes around the placeholder. The same values arrive as TABLEPRO_HOST, TABLEPRO_PORT, TABLEPRO_USER and TABLEPRO_DATABASE, plus TABLEPRO_CONNECTION_NAME.
{host} and {port} are the ones typed in the form, never the local port of a tunnel. ${host} is left for bash. Reuse Result For keeps the output for 5 minutes, 15 minutes, an hour or 8 hours, so a reconnect inside that window skips the command. Set it below the lifetime of whatever the command prints. The output stays in memory, and a connect that fails throws it away so the next one runs the command again.

​
Additional secrets

Some engines sign in with more than a password: an AWS secret access key, a Snowflake private key, a service account JSON. Additional Secrets in the profile editor lists them per database type. A connection reads only the secrets its own type declares, so one profile can carry several engines’ keys without them colliding.

​
Rename, duplicate and delete

Right-click a row in Settings > Profiles for Edit… and Duplicate. The row’s trailing label says how many connections use it. Delete Profile is at the bottom of the editor. Deleting hands the username and the password to each connection that used it, as that connection’s own credentials, so nothing stops connecting. Two profiles cannot share a name, since every picker offers them by name alone.

​
Sharing and sync

An exported connection carries its profile by name, alongside the name, the username and where the password comes from. Importing on a Mac that has no profile of that name creates one set to ask for the password; a profile already there is left as it is and the connection links to it. The password never travels, and a profile reading its password from a file or a command exports as one that asks. With iCloud Sync on, Settings > Sync > Credential Profiles carries profiles between your Macs: the name, the username, and where the password comes from. The password and any additional secrets stay in the Keychain. They cross only while Passwords is on in the same pane, and only when saved after it was turned on. A profile set to Read from elsewhere arrives as Ask every time, and a source set on the second Mac stays on that Mac. Which connections use a profile is kept on each Mac, so pick the profile in Credentials again on the second one. A profile arriving under a name already taken gets a number after it, such as prod (2). Deleting a profile deletes it on your other Macs too.