Scoped variables
Set config at global, environment, or service scope with clear precedence.
Deliver
Configuration & Secrets
Scoped config and secrets, masked and governed
Manage application configuration as variables scoped at the global, environment, or service level, with clear precedence and secret values masked. Secrets route into a dedicated store, and you can point a tenant at your own vault rather than the default backend.
- Config scoped and precedence enforced at every level, from global down to a single service
- Secret values that never surface in the clear, with every change recorded in a tamper-evident trail
- Secrets governance that works with your existing vault or the platform default, without a forced migration
The problem
When configuration and secrets are scattered across pipeline files, environment stores, and team-managed backends, there is no enforced precedence and no single place to govern what each service actually sees. A secret that leaks into a log, or a config value set at the wrong scope, can stay invisible for weeks, and proving what changed and when is nearly impossible when an auditor asks.
Without IntegraCI
- Config scattered with no enforced scope precedence
- Secret values exposed in logs and configuration views
- Secrets and plain config held in the same place
- Each team wires its own vault integration independently
With IntegraCI
- Config scoped at global, environment, or service level with clear precedence
- Secret values masked in the surface and never shown in the clear
- Secrets routed into a dedicated store, kept separate from config
- Tenants can point to their own vault instead of the default backend
What you get
Secrets masked
Secret values are masked in the surface and never shown in the clear.
Dedicated secrets store
Secrets route into a dedicated store, kept separate from your config.
Bring your own vault
Point a tenant at your own vault instead of the default backend.
How it works
- 1
Set variables
Define config at the scope that fits, from global down to a service.
- 2
Store secrets
Secret values route into the dedicated store, masked in the UI.
- 3
Bind a backend
Optionally point the tenant at your own vault.
How it stays governed
The same gates everyone passes, applied here.
Gated by policy
Access to set, read, or override a scoped variable is governed by policy as code, so only the right principals can touch global, environment, or service-level config. The same rules apply whether a team is writing a plain variable or storing a secret.
Recorded, tamper-evident
Every variable change, secret write, and vault binding update is recorded once in a tamper-evident audit trail. You can show which principal set what value, at which scope, and when, without relying on log files that can be altered.
Works with your stack
Connect the tools you already run.
Vault backends plug in under the secrets store seam; identity providers govern who can read or write each scope.
- Apple
- Argo Project
- AWS
- Cloudflare
- CNCF
- Coder
- Crunchy Data
- Daytona
- Env0
- Keycloak
- MongoDB
- Okta
- OutSystems
- Pulumi
- Rancher
- Red Hat
- Sonatype
- +31 more
Who it’s for
Where teams reach for it.
Multi-environment config with enforced precedence
A team running development, staging, and production sets a database host at the global scope and overrides it per environment. The service always picks up the most specific value, with no ambiguity about which config wins.
Secrets management for regulated workloads
Teams subject to compliance requirements need proof that secret values are never exposed in a dashboard or log. Secret values stay masked in the surface and route into a dedicated store, giving you an audit trail that records access without surfacing the value.
Layering governance onto your existing vault
Organizations with a vault already in production can point IntegraCI at their own backend rather than adopting the default store. Scope precedence and policy-governed access layer on top of the vault you already operate.
Questions, answered.
Does IntegraCI replace my existing vault?
No. IntegraCI can use its own dedicated secrets store, or you can point a tenant at your own vault. Scope precedence and policy-governed access layer on top of the backend you choose, so you do not need to migrate off your existing secrets infrastructure.
How are secrets kept separate from regular config?
Secret values route into a dedicated secrets store rather than sitting alongside plain config variables. The surface masks secret values at all times, so they are never shown in the clear regardless of who is viewing the configuration page.
Who can set or change a secret value?
Access to write or override a scoped variable is governed by policy as code. The same rule set applies at every scope, so a developer who can set a service-level variable does not automatically gain write access to environment or global config.
How does scope precedence work when the same key is defined at multiple levels?
You define config at the global, environment, or service level. The most specific scope wins: a service-level value overrides an environment-level value, which overrides a global value. The platform enforces this order rather than leaving it to convention.
Put Configuration & Secrets on your stack.
Request a demo, or read the docs to see how it fits the tools you already run.