Secrets and environment

These guides keep a pack's secrets and settings where they belong, on your machine and in a deployment, and get each to the code that needs it.

A pack's code needs three kinds of values, and Kindgi keeps them apart:

• Secrets a tool uses for a tenant: an API key, a signing key. A tool declares them by name, and Kindgi resolves them for each call into ctx.secrets, at the scope recorded when the tool version was registered (Where values live). Model providers, HTTP tools, MCP endpoints and webhooks name theirs by name too. A model provider's key is its provider's only: no tool or endpoint gets it.
• Env values a tool uses per project: a base URL, a region, an account id, which aren't secret but differ per tenant, org or project. A tool declares them by name, and Kindgi resolves them for each call into ctx.env: the project's value before its org's and the tenant's.
• Your code's own environment: a service URL, a database your app owns, a feature flag. Your code reads them from process.env or os.environ, and the pack declares which ones it needs.

On your machine, kindgi dev keeps secrets and your code's environment in env files: your app's own, and Kindgi's own .kindgi/secrets.env for the secrets you store. In a deployment, secrets live in the runtime's secrets store, and the pack service gets the environment the pack declares.

• Keep local values in env files: what kindgi dev reads, and what reaches your code.
• Store a secret: kindgi secrets, its environments and scopes.
• Declare the environment your code reads: env.required and env.optional.
• Set values per environment: the pack service's environment in staging or production, and kindgi env plan.
• Keep your tools' code away from your keys: the sandbox kindgi dev runs your pack's code in, and how to open a path a tool needs.

Give a tool a secret and Give a tool per-project values show the tool's side.