GitHub
How-to

Variables & secrets

Per-service configuration and secrets as a key × environment matrix, with org-wide defaults inherited unless overridden.

Variables are the configuration and secrets a service needs at runtime. Manage them under Deploy → Variables (scoped to the picked service).

The key × environment matrix

With a service in scope, Variables renders a matrix: one row per key, one column per environment (dev, qa, preprod, prod). A value can differ per environment, be shared across all of them, or be left unset to fall back to a default.

Org-wide defaults

Set a value once at the organization level and every service inherits it, unless a service overrides it for a specific environment. This keeps cross-cutting config (shared endpoints, common feature flags) in one place while still allowing per-service, per-environment overrides.

Secrets

Sensitive values are stored as secrets, encrypted at rest and injected into the workload at deploy time rather than written into the manifests. Per-service secrets are managed at:

GET    /api/v1/projects/{id}/secrets            # list (values redacted)
PUT    /api/v1/projects/{id}/secrets/{name}     # set or update
DELETE /api/v1/projects/{id}/secrets/{name}     # delete

Secrets surface to a running service as Kubernetes Secret-backed environment variables; plain (non-secret) variables become regular env vars on the Deployment.

Like everything else in Deploy, a variable or secret change flows through the GitOps pipeline and lands as a forge commit or PR, so there’s a complete audit trail of who changed what and when.

Relationship to k8s/ manifests

Variables are a convenience layer over standard Kubernetes objects. If you’d rather manage config in the repo directly, plain env vars live in k8s/base/deployment.yaml and secrets in a kind: Secret (or SealedSecret) referenced by the Deployment — see the config.yaml reference. Both approaches reconcile through the same path.