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

# Vault

> Encrypt customer Perflo sessions and provider action context with the derived Transit key.

# Configure Vault Transit

Vault encrypts customer access and refresh credentials, beneficiary destinations, approval session identifiers and URLs, and provider preparation context. PostgreSQL stores only ciphertext and the context needed to select the correct Transit derivation.

## Grant the application minimum access

The shipped policy grants encrypt, decrypt, and inspect access to `neobank-perflo-credentials`:

```hcl theme={null}
path "transit/encrypt/neobank-perflo-credentials" {
  capabilities = ["update"]
}

path "transit/decrypt/neobank-perflo-credentials" {
  capabilities = ["update"]
}

path "transit/keys/neobank-perflo-credentials" {
  capabilities = ["read"]
}
```

Create the Transit key with `derived=true`. Derivation contexts isolate customer connections, beneficiaries, and operations under one managed key.

## Use TLS in production

Production refuses cleartext Vault. The server deployment mounts `ca.pem`, `server.pem`, and `server-key.pem`, points the application at `https://vault:8200`, and configures the CA for the API, worker, and bootstrap sidecar. The scheduler has no Vault access.

## Back up recoverable state

Back up Vault data, bootstrap state, TLS material, and PostgreSQL together. Losing the Vault key while provider devices remain active makes their credentials impossible to decrypt or revoke. Revoke provider devices before intentionally deleting either store.