Airbyte is an open-source data integration engine that helps you consolidate your data in your data warehouses, lakes and databases.

Airbyte

<@U04S8PLJWMT> Could you elaborate "The recommended/configured way in an EKS deployment remains editing and providing `flags.yaml` directly."

The knowledge sources only mention `flags.yaml` in the context of configuring heartbeat and destination timeout behavior; they do **not** describe where `flags.yaml` should live or how exactly to mount/provide it in an EKS (or any Kubernetes) deployment. [[Heartbeats](<https://docs.airbyte.com/platform/understanding-airbyte/heartbeats#technical-details>)]  From the docs we know only that:  - Certain runtime behaviors (e.g.,     - `heartbeat-max-seconds-between-messages`     - `heartbeat.failSync`     - `destination-timeout-max-seconds`     - `destination-timeout.failSync`     )     are configured via a file named `flags.yaml`. [[Heartbeats](<https://docs.airbyte.com/platform/understanding-airbyte/heartbeats#technical-details>)]  However, the provided materials do **not** specify:  - Whether `flags.yaml` should be baked into the container image vs. mounted via ConfigMap/Secret. - The exact path where `flags.yaml` must be placed in the container. - Any EKS‑specific mechanism for supplying `flags.yaml`.  They do describe that other sensitive configuration is typically provided via Kubernetes Secrets and referenced from `values.yaml` in Helm deployments, but `flags.yaml` itself is not explicitly tied into that mechanism in the docs you shared. [[Kubernetes secrets](<https://docs.airbyte.com/platform/enterprise-setup/implementation-guide#configure-kubernetes-secrets>)]  So, regarding:  &gt; “The recommended/configured way in an EKS deployment remains editing and providing `flags.yaml` directly.”  I’m not able to confirm or elaborate this from the official documentation in the knowledge sources. There is no explicit, documented “recommended way” for EKS that explains how to provide `flags.yaml`.  If you can share the rest of your question (it seems cut off after “Should the flags.yaml”), or any deployment snippet/Helm values you’re using, I can help interpret it—but I won’t be able to point to an official pattern for `flags.yaml` beyond what’s in the heartbeat docs.

In Airbyte’s context, that sentence means:  - Runtime behaviors like heartbeats and destination timeouts are controlled via a configuration file named `flags.yaml`.   - For EKS (and more generally Kubernetes) deployments, the *intended* way to change these behaviors is to edit `flags.yaml` yourself and provide it as part of your deployment, rather than toggling them through some UI or ad-hoc mechanism. - Specifically, heartbeats and timeouts are configured there, for example:     - `heartbeat-max-seconds-between-messages` and `heartbeat.failSync` for sources.     - `destination-timeout-max-seconds` and `destination-timeout.failSync` for destinations. [[Heartbeats](<https://docs.airbyte.com/platform/understanding-airbyte/heartbeats#technical-details>)]  The knowledge sources do not show the exact mounting/packaging pattern for `flags.yaml` in EKS (e.g., ConfigMap vs. direct file on disk), only that these flags are configured via `flags.yaml` and are the mechanism to adjust heartbeat and destination timeout behavior. [[Heartbeats](<https://docs.airbyte.com/platform/understanding-airbyte/heartbeats#technical-details>)]