Set values per environment

Each deploy target of a pack is an environment in its config (staging, production). Its env gives the values of the names the pack declares, for the pack service running there:

TypeScript

// in kindgi.config.ts
environments: {
  staging: {
    // endpoint, build, registry, signingKey, tenantId…
    env: {
      ORDERS_APP_URL: 'https://backoffice.staging.example.com',
      ORDERS_DB_URL: { secret: 'orders-db-url', version: '3' },
    },
  },
},

Python

# in pyproject.toml
[tool.kindgi.environments.staging.env]
ORDERS_APP_URL = "https://backoffice.staging.example.com"
ORDERS_DB_URL = { secret = "orders-db-url", version = "3" }

• A plain value is for what isn't secret. It's committed with the pack, and visible in the deployed service's settings.
• { secret, version } names a secret in your cloud's Secret Manager (add project, the project's number, when the secret is in another project). The platform that runs the pack service resolves it; Kindgi never reads the value. Use a version number: latest changes under you.

Check it

kindgi env plan --env=staging

  The pack service's env in staging:
    required  ORDERS_APP_URL                value "https://backoffice.staging.example.com"
    required  ORDERS_DB_URL                 secret orders-db-url:3
    optional  ORDERS_API_TIMEOUT_MS         (unset: not injected)

That summary goes to stderr. On stdout, env plan prints the same environment for your infrastructure code: Terraform input by default,

{
  "env": {
    "ORDERS_APP_URL": "https://backoffice.staging.example.com"
  },
  "secret_env": {
    "ORDERS_DB_URL": {
      "secret": "orders-db-url",
      "version": "3"
    }
  }
}

or, with --format=gcloud, flags for gcloud run deploy:

--set-env-vars=ORDERS_APP_URL=https://backoffice.staging.example.com \
--set-secrets=ORDERS_DB_URL=orders-db-url:3

What it refuses

env plan exits with status 1, and names the problem, when the environment won't work:

• A required name has no value: ✗ ORDERS_DB_URL is required and has no value in environments.staging.env
• A secret is given in the clear, by its value (a URL with a password) or its name (*_KEY, *_TOKEN, *_PASSWORD, …):

  ✗ ORDERS_DB_URL's value has a credential in it (a URL with a password): give it as { secret, version } in environments.staging.env

  ✗ ORDERS_API_KEY is named like a secret: give it as { secret, version } in environments.staging.env

kindgi deploy runs the same check before it builds or sends anything:

kindgi deploy: ORDERS_DB_URL is required by the pack and has no value in environments.staging.env, so the pack service wouldn't be ready. Add it, or deploy anyway with --allow-missing-env.

Env files for other environments

kindgi env manages env files per environment: local is the pack's own files (.env, .env.local), any other name its .env.<name>:

kindgi env set ORDERS_API_URL https://orders.staging.example.com --env=staging

  ✓ Wrote ORDERS_API_URL in …/my-pack/.env.staging

kindgi env list --env=staging shows them, redacted; kindgi env unset removes one. set won't change a name a file already sets without --force, and refuses KINDGI_* names.

Under kindgi dev, a secret reference that names an environment other than local (an HTTP tool's secretRef: { envName: 'staging', … }, for example) resolves from that environment's file, .env.staging.

The pack service's environment in a deployment comes from environments.<name>.env, not from these files: env plan doesn't read them.