> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tablepro.app/llms.txt
> Use this file to discover all available pages before exploring further.
# Credential Profiles
> One username and password, shared by any number of connections
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** is the first section.
Give it a name, a username, and pick where the password comes from.
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
**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
| Source | What happens on connect |
| --------------------- | ---------------------------------------------------------------------------------------------------------- |
| Saved in the Keychain | Read from the Keychain, under the profile's own id |
| Ask every time | Asked for once per profile each time TablePro runs, however many connections use it |
| `~/.pgpass` | Looked up by the host, port, database and username of whichever connection is opening |
| Read from elsewhere | Resolved from a file, an environment variable, a command's output, 1Password, Vault or AWS Secrets Manager |
Pick **Saved in the Keychain** unless something else already owns the password. **Read from elsewhere** never leaves this Mac and never syncs.
## 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.
**Settings > Sync > Credential Profiles** is the switch for carrying them between your own Macs. It is off at the source for now: the record type ships ahead of its CloudKit schema, so nothing is sent or received until that schema is deployed. Create the profile again on the second Mac in the meantime.