Environment variables
How Pact is configured: what you set in the app, what your operator sets on the deployment, and why your credentials never live in a shared environment variable.
Pact splits configuration into two layers that never mix. Knowing which layer a setting belongs to tells you where to change it — and, more importantly, who can read it.
The two layers
| Layer | Set by | Set where | Scope |
|---|---|---|---|
| Tenant configuration | You, in the app | Settings UI | Your tenant only |
| Platform configuration | Whoever runs the deployment | Deployment environment | The whole install |
Everything you configure as a customer — your email provider, your calendar and CRM connections, your own AI provider key, your telephony credentials, sending windows, retention periods — is tenant configuration. It is stored encrypted in the database, scoped to your tenant, and edited through Settings. None of it is an environment variable, and no other tenant on the same deployment can read it.
Bring your own keys, through the UI
Provider credentials are entered in the app and stored encrypted at rest — never pasted into a shared environment variable, never printed back to you after saving, and never logged. If a setup guide anywhere tells you to hand a credential to an operator to put in the deployment environment, that is the wrong path: use the connector's own screen under Settings instead.
Why your credentials are not environment variables
An environment variable is process-wide. On a multi-tenant deployment that means every tenant's traffic runs in a process that can read it — so a shared env var is structurally the wrong place for anything tenant-specific. Pact's BYOK (bring-your-own-key) flow exists to keep that boundary intact: credentials go in the database, encrypted, under your tenant's row.
The practical consequences:
- Rotating a key is self-service. Change it in Settings; no deploy, no ticket.
- Revoking access is immediate and scoped. Disconnecting a connector drops your credential, and only yours.
- An operator does not need your secrets to run the platform for you.
What the browser can see
The web app compiles a small number of settings into the JavaScript bundle it
ships to browsers. By convention every one of them is prefixed NEXT_PUBLIC_,
and that prefix is a promise about visibility, not importance:
`NEXT_PUBLIC_` means world-readable
Anything with that prefix is embedded in the client bundle and can be read by anyone who loads the page — view-source, devtools, a saved copy of the file. It is the right home for the API base URL or the app name. It is never the right home for a secret, and a secret placed there is disclosed the moment the build deploys, whether or not the value is ever used.
If you are reviewing a Pact deployment for security, this is a useful thing to check directly: nothing sensitive should appear in the served JavaScript.
Running Pact yourself
Self-hosting is an Enterprise arrangement and comes with the full platform variable reference — database and pool configuration, the secrets backend and KMS wrapping, provider credentials, storage, telephony, billing and cost controls — plus the deployment topology it assumes. It is not a one-click distribution; treat it as an operator project.
Start with Self-hosting, and talk to your account team for the platform reference and a deployment review. Pact staff and Enterprise self-hosting customers can read the full list at Platform environment variables.