> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hoista.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Credentials

> Where provider tokens are stored, and how to keep them in 1Password.

Hoista needs an API token for each provider account you connect. Agents never see these. Hoista adds the token to each request it sends to the provider.

## Connect with the least access

Paste the token into Desktop, or enter it in the CLI's hidden prompt. To pipe it from a password manager, use `--token-stdin`:

```bash theme={null}
hoist accounts add railway --token-stdin
```

Limit each token to the projects and permissions Hoista needs. An agent's access level limits what it can ask Hoista to do, but the token sets what Hoista itself can do at the provider.

## Where tokens are stored

| Where Hoista runs | Storage |
| - | - |
| macOS | Keychain, through Apple's `security` tool |
| Windows | Windows Credential Manager |
| Linux | Secret Service |
| A remote | A sealed file that only the credential keeper can open |

Hoista never falls back to a plain file on disk. **Settings → Vault** shows where each token is and whether it still works. Use **Replace** or **Reconnect** there when a token expires or you rotate it. From the CLI, `hoist accounts rotate ACCOUNT` checks the new token with the provider before it replaces the old one.

Agent credentials and webhook secrets are kept in the same store.

## Keep a token in 1Password

Hoista can keep a 1Password secret reference in place of the token. The token stays in 1Password.

1. Install the 1Password CLI (`op`) and turn on its desktop app integration. On a remote, use a service account limited to the items Hoista needs.
2. Copy the field's secret reference, such as `op://Hoista/Railway/token`.
3. Paste the reference where you'd paste the token, in Desktop or with `--token-stdin`.

Hoista checks the reference before saving the account. When it needs the token, it runs `op read`. It holds the value in memory for at most 15 minutes, or 5 minutes unused, so a token you rotate in 1Password is picked up. If 1Password can't provide it, the request fails. Hoista doesn't fall back to an older token.

On a remote, set `OP_SERVICE_ACCOUNT_TOKEN` as a secret variable at your provider. Only the credential keeper receives it.

> [!WARNING]
>
> **Move to a new computer** and `hoist remote push` resolve 1Password references and carry the token values. Protect the export file like the tokens themselves.

## What isn't supported

Hoista supports its built-in store and individual 1Password references. It doesn't support other password managers, whole-vault integrations, HashiCorp Vault or cloud KMS keys.

If you think a token leaked, revoke it at the provider first, then follow the [incident checklist](https://docs.hoista.dev/security/incident-response.md).

## Related

> [card] [Connect hosting accounts](https://docs.hoista.dev/guides/accounts.md)
>
> Connect, check and rotate accounts.

> [card] [Remote runtime](https://docs.hoista.dev/security/remote-runtime.md)
>
> How a remote keeps your tokens.

> [card] [Incident checklist](https://docs.hoista.dev/security/incident-response.md)
>
> What to do if something looks wrong.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.