@kapa.ai, I am trying to use feature flags in my Kubernetes deployment. It's a custom Kubernetes deployment, and I am not using Helm charts. I am using Airbyte 1.7. I created a

flags.yaml

file in

/etc/airbyte/flags.yaml

directory in containers for Airbyte services like airbyte-server, airbyte-workload-launcher, etc. Then, I provided the following environment variables to these containers.

"FEATURE_FLAG_PATH": "/etc/airbyte/flags.yaml"

"FEATURE_FLAG_CLIENT": "OPENFEATURE"

"OPENFEATURE_SDK_FILE_PATH": "/etc/airbyte/flags.yaml"

However, this does not work. I couldn't find much documentation about feature flag management. What is the issue with my approach? How can I provide feature flags to Airbyte 1.7 with my Kubernetes deployment?

Airbyte 1.7 does support feature flags, but the available docs only describe them at the level of environment variables, not how to wire a

flags.yaml

file into a custom (non‑Helm) Kubernetes deployment. From the 1.7 configuration reference, we know: - There is a

FEATURE_FLAG_PATH

env var, and a related

FEATURE_FLAG_BASEURL

in some manifests, but the docs do not explain expected format, client type, or how file‑based flags should be structured. [[Configuring Airbyte](https://docs.airbyte.com/platform/1.7/operator-guides/configuring-airbyte)] - Example Kubernetes/Helm configurations show

FEATURE_FLAG_PATH

and other feature‑flag–related env vars simply being set on pods, but again without any description of the file format or the

FEATURE_FLAG_CLIENT

/

OPENFEATURE_*

variables you’re using. [[Issue 48809](https://github.com/airbytehq/airbyte/issues/48809); [Issue 50979](https://github.com/airbytehq/airbyte/issues/50979)] The only explicit guidance the docs give for Kubernetes‑side secrets and configuration in 1.7 is: - Pre‑create a Kubernetes Secret (usually

airbyte-config-secrets

) and then refer to that from your deployment (or

values.yaml

if using Helm). [[Preconfiguring Secrets](https://docs.airbyte.com/platform/1.7/deploying-airbyte/creating-secrets); [Customize deployment](https://docs.airbyte.com/platform/1.7/deploying-airbyte#4-optional-for-customized-installations-only-customize-your-deployment)] - Configure Airbyte globally via environment variables listed in the configuration guide. [[Configuring Airbyte](https://docs.airbyte.com/platform/1.7/operator-guides/configuring-airbyte)] There is no documentation in these sources about: - Supported

FEATURE_FLAG_CLIENT

values for OSS 1.7 - How

OPENFEATURE_SDK_FILE_PATH

is consumed, or if OpenFeature is supported in 1.7 - The required schema/format for

flags.yaml

, or examples of a working file‑based setup Because of that, I can’t reliably tell you: - Whether

OPENFEATURE

is a valid client for 1.7 OSS - Whether

OPENFEATURE_SDK_FILE_PATH

is even read by Airbyte 1.7 - Whether a plain file at

/etc/airbyte/flags.yaml

is a supported way to provide flags in that version So: - The issue with your current approach is likely that Airbyte 1.7 OSS does not officially document or guarantee support for OpenFeature / file‑based

flags.yaml

configuration, and the environment variables you’re setting are not documented as supported inputs for that release. - The only documented and supported way to “configure features” in 1.7 in Kubernetes, based on these sources, is via the environment variables listed in the configuration guide, and by pre‑provisioning secrets (for secrets‑related options) and wiring them into the pod env as usual. [[Configuring Airbyte](https://docs.airbyte.com/platform/1.7/operator-guides/configuring-airbyte); [Preconfiguring Secrets](https://docs.airbyte.com/platform/1.7/deploying-airbyte/creating-secrets)] Since the knowledge sources don’t contain a working example or spec for feature flags via a YAML file, I cannot give you a correct

flags.yaml

format or a guaranteed‑working env var combination. The safest path, given the available information, is: 1. Use the documented environment variables only (e.g., feature‑flag‑related ones listed in the config guide), and inject them directly into your Kubernetes manifests, possibly via ConfigMaps/Secrets. 2. If you need more advanced flagging (e.g., OpenFeature, file‑based flags), open a GitHub issue or discuss post against the exact 1.7 version to get implementation‑specific guidance from the core team, since this behavior is not documented in the 1.7 docs we have.