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.