Secrets are never written in code. Where a definition needs one (a webhook’s signing secret, an inbound hook’s shared secret), pass env("NAME"):

​
Where values come from

  1. The process environment (what CI sets).
  2. A .env file next to pawabase.toml (local development; never commit it).
Real environment variables win over .env.

​
What validate and deploy do

  • pawabase validate checks the shape of your definitions and doesn’t need secrets.
  • pawabase plan and deploy need the variable. If one is unset, nothing is sent: deploy refuses first, so you never half-deploy.
  • Secrets are write-only: sent when a definition is created or changes, never read back or compared. plan therefore shows nothing for an unchanged secret.

​
Rotating a secret

  1. Set the new value in your environment (and in the other service).
  2. Run pawabase deploy --force-secrets to resend secrets even though nothing else changed.

​
The API key

PAWABASE_API_KEY is the credential that lets plan and deploy talk to your environment. It must be a secret key (pb_sk…) with the Deploy and configure preset. Create it in Studio’s API keys page, and keep it in .env locally and in your CI’s secret store.

​
Studio’s Secrets

Studio’s Access → Secrets page holds values referenced as secret://NAME in settings that Studio manages (provider client secrets and so on). Those aren’t part of IaC; see Secrets.

​
Good practice

  • A different key and different secrets per environment.
  • Scope the deploy key to what it needs; revoke and rotate if a CI log leaks it.
  • Never print env() values in your own code.

Plan and deploy

What gets sent.

Webhooks

Where secrets are used.