Is your feature request related to a problem? Please describe.
Zarf already tracks some deployment state for a package, such as installed components, but it does not currently expose the full effective configuration that was applied during deployment. This makes it difficult for orchestration tools to reliably detect package-level configuration drift.
For tools managing Zarf deployments declaratively, it is important to know not only what was intended to be applied, but what Zarf actually applied at deployment time. That configuration can then be stored in the tool’s own state and later compared against the current deployed package configuration.
Today, Zarf exposes some deployment metadata, but there does not appear to be a way to retrieve the full set of deploy-time inputs that influenced a deployment, such as values, variables, component selection, overrides, or other mutations
This becomes challenging when a package is later re-deployed with different inputs by another user, tool, automation, or workflow. An orchestration tool may no longer have a reliable way to determine whether the deployed package configuration still matches what it originally applied.
Describe the behavior you'd like
-
Given an orchestration tool deploys a Zarf package with a specific set of values, variables, selected components, or other deploy-time configuration
-
When the deployment completes
-
Then Zarf exposes the effective configuration that was applied so the orchestration tool can persist it in its own state
-
Given a Zarf package has already been deployed to a cluster
-
When an orchestration tool queries the deployment through the SDK, CLI, or another supported interface
-
Then Zarf returns the current or last-applied deployment configuration for that package
-
Given an orchestration tool has a previously saved copy of the applied configuration
-
When it compares that configuration to the current or last-applied configuration returned by Zarf
-
Then the tool can determine whether package-level configuration drift has occurred
Ideally, Zarf would persist and expose an applied package configuration record representing the effective configuration used during deployment. Examples of useful data could include:
- Package identity, version, and/or digest
- Installed components (already tracked today)
- Variables and values supplied at deploy time
- Effective Helm values or value overrides
- Package mutations or deployment overrides
- Other deploy-time inputs that influence the resulting deployment
- Optionally, a stable digest/hash of the effective configuration
For drift detection, the most useful representation would be the resolved/effective configuration after defaults, variables, overrides, and mutations have been applied, since that reflects what Zarf actually used during deployment.
Sensitive inputs would likely need to be handled differently than non-sensitive configuration. Rather than exposing plaintext secrets, it would be helpful for Zarf to identify which deploy-time inputs are considered sensitive so orchestration tools can treat them appropriately in their own state (for example, avoiding plaintext persistence, using protected state, redaction, or other secret-handling mechanisms).
Describe alternatives you've considered
-
Orchestration tools maintain their own copy of deploy-time configuration
This preserves what the tool intended to apply, but it does not solve the problem of re-querying the cluster later to determine what configuration Zarf last applied. If another user, automation, or workflow re-deploys the package with different inputs, the orchestrator’s saved state becomes stale and there is no reliable comparison point.
-
Infer drift by inspecting Kubernetes resources
In practice, this is difficult and unreliable because deploy-time configuration may be transformed through defaults, templating, Helm rendering, mutations, generated values, or other package behavior. The resulting resources do not necessarily map cleanly back to the original deployment inputs.
-
Compare only package identity and installed components
This catches some changes, but misses important configuration drift when the same package and components are deployed with different values, variables, or other deploy-time overrides.
-
Treat all deploy-time configuration as sensitive
One option would be for orchestration tools to treat all deploy-time inputs as sensitive by default. While this is conservative from a security perspective, it makes the resulting state more opaque and limits the ability to safely surface or log non-sensitive configuration for troubleshooting, observability, or drift analysis. Having a way to identify which inputs are sensitive would allow tools to handle configuration more appropriately.
Additional context
This request is about improving how Zarf participates in declarative and state-aware deployment workflows.
A common need for orchestration tools is to:
- Capture the effective configuration Zarf applied during deployment
- Persist that configuration in the tool’s own state
- Re-query Zarf later for the current or last-applied configuration
- Compare the two to detect drift
Sensitive inputs would likely need different handling than non-sensitive configuration. The goal would not be to expose plaintext secrets, but to allow orchestration tools to identify which deploy-time inputs are sensitive so they can be treated appropriately in downstream state, logging, and drift detection workflows.
This capability would make it easier for integrations such as GitOps controllers, CI/CD systems, platform automation, custom operators, infrastructure-as-code tooling, and audit/compliance workflows to reason about whether deployed package state still matches what was originally applied.
For orchestration and declarative workflows, this information would need to be programmatically queryable. An SDK-based interface would likely be the most useful for integrations, though a CLI experience could also be valuable for troubleshooting and inspection workflows.
Is your feature request related to a problem? Please describe.
Zarf already tracks some deployment state for a package, such as installed components, but it does not currently expose the full effective configuration that was applied during deployment. This makes it difficult for orchestration tools to reliably detect package-level configuration drift.
For tools managing Zarf deployments declaratively, it is important to know not only what was intended to be applied, but what Zarf actually applied at deployment time. That configuration can then be stored in the tool’s own state and later compared against the current deployed package configuration.
Today, Zarf exposes some deployment metadata, but there does not appear to be a way to retrieve the full set of deploy-time inputs that influenced a deployment, such as values, variables, component selection, overrides, or other mutations
This becomes challenging when a package is later re-deployed with different inputs by another user, tool, automation, or workflow. An orchestration tool may no longer have a reliable way to determine whether the deployed package configuration still matches what it originally applied.
Describe the behavior you'd like
Given an orchestration tool deploys a Zarf package with a specific set of values, variables, selected components, or other deploy-time configuration
When the deployment completes
Then Zarf exposes the effective configuration that was applied so the orchestration tool can persist it in its own state
Given a Zarf package has already been deployed to a cluster
When an orchestration tool queries the deployment through the SDK, CLI, or another supported interface
Then Zarf returns the current or last-applied deployment configuration for that package
Given an orchestration tool has a previously saved copy of the applied configuration
When it compares that configuration to the current or last-applied configuration returned by Zarf
Then the tool can determine whether package-level configuration drift has occurred
Ideally, Zarf would persist and expose an applied package configuration record representing the effective configuration used during deployment. Examples of useful data could include:
For drift detection, the most useful representation would be the resolved/effective configuration after defaults, variables, overrides, and mutations have been applied, since that reflects what Zarf actually used during deployment.
Sensitive inputs would likely need to be handled differently than non-sensitive configuration. Rather than exposing plaintext secrets, it would be helpful for Zarf to identify which deploy-time inputs are considered sensitive so orchestration tools can treat them appropriately in their own state (for example, avoiding plaintext persistence, using protected state, redaction, or other secret-handling mechanisms).
Describe alternatives you've considered
Orchestration tools maintain their own copy of deploy-time configuration
This preserves what the tool intended to apply, but it does not solve the problem of re-querying the cluster later to determine what configuration Zarf last applied. If another user, automation, or workflow re-deploys the package with different inputs, the orchestrator’s saved state becomes stale and there is no reliable comparison point.
Infer drift by inspecting Kubernetes resources
In practice, this is difficult and unreliable because deploy-time configuration may be transformed through defaults, templating, Helm rendering, mutations, generated values, or other package behavior. The resulting resources do not necessarily map cleanly back to the original deployment inputs.
Compare only package identity and installed components
This catches some changes, but misses important configuration drift when the same package and components are deployed with different values, variables, or other deploy-time overrides.
Treat all deploy-time configuration as sensitive
One option would be for orchestration tools to treat all deploy-time inputs as sensitive by default. While this is conservative from a security perspective, it makes the resulting state more opaque and limits the ability to safely surface or log non-sensitive configuration for troubleshooting, observability, or drift analysis. Having a way to identify which inputs are sensitive would allow tools to handle configuration more appropriately.
Additional context
This request is about improving how Zarf participates in declarative and state-aware deployment workflows.
A common need for orchestration tools is to:
Sensitive inputs would likely need different handling than non-sensitive configuration. The goal would not be to expose plaintext secrets, but to allow orchestration tools to identify which deploy-time inputs are sensitive so they can be treated appropriately in downstream state, logging, and drift detection workflows.
This capability would make it easier for integrations such as GitOps controllers, CI/CD systems, platform automation, custom operators, infrastructure-as-code tooling, and audit/compliance workflows to reason about whether deployed package state still matches what was originally applied.
For orchestration and declarative workflows, this information would need to be programmatically queryable. An SDK-based interface would likely be the most useful for integrations, though a CLI experience could also be valuable for troubleshooting and inspection workflows.