For Helm chart V2,

AB_JWT_SIGNATURE_SECRET

is no longer set as a raw env var; it’s mapped into the

global.auth.security

section of

values.yaml

. From the V1 → V2 mapping tables:

yaml global:   auth:     security:       jwtSignatureSecret: "<your-jwt-signature-secret>"

AB_JWT_SIGNATURE_SECRET

→

global.auth.security.jwtSignatureSecret

.[[1.8 chart v2 comm](https://docs.airbyte.com/platform/1.8/deploying-airbyte/chart-v2-community#update-your-valuesyaml-file); [2.0 chart v2 comm](https://docs.airbyte.com/platform/2.0/deploying-airbyte/chart-v2-community#update-your-valuesyaml-file)] For Enterprise it’s the same mapping:

AB_JWT_SIGNATURE_SECRET

→

global.auth.security.jwtSignatureSecret

.[[2.0 chart v2 ent](https://docs.airbyte.com/platform/2.0/enterprise-setup/chart-v2-enterprise#update-your-valuesyaml-file)] Where the value comes from: - The docs only state the mapping; they do not describe how the original secret is generated. They just show that in V2 you must provide it via

global.auth.security.jwtSignatureSecret

.[[2.0 chart v2 comm](https://docs.airbyte.com/platform/2.0/deploying-airbyte/chart-v2-community#update-your-valuesyaml-file)] - Several GitHub issues show it being read from the

airbyte-auth-secrets

Kubernetes secret as

jwt-signature-secret

, then exposed as

AB_JWT_SIGNATURE_SECRET

in deployments, but they don’t document the generation process either.[[duplicate AB_JWT](https://github.com/airbytehq/airbyte/issues/58591); [abctl env snippet](https://github.com/airbytehq/airbyte/issues/60918)] So for your upgrade: 1. Read the existing value from your current cluster’s

airbyte-auth-secrets

secret (key

jwt-signature-secret

). 2. Use that same value in your new

values.yaml

under

global.auth.security.jwtSignatureSecret

.

The knowledge sources don’t explicitly document what

AIRBYTE_DUMMY_SECRET

is used for or how to migrate it to Helm chart V2, so there’s some uncertainty here. From the abctl/Helm-related GitHub issue,

AIRBYTE_DUMMY_SECRET

is just one of the env vars created in the

airbyte-abctl-airbyte-secrets

secret and injected into pods, but there is no corresponding key in the V1→V2 mapping tables and no

global.*

field for it in

values.yaml

.[[Helm issue](https://github.com/airbytehq/airbyte/issues/65129); [values ref](https://docs.airbyte.com/platform/2.0/deploying-airbyte/values)] Given the docs: - It is not listed in the official “Environment variable → Helm chart V2 equivalent” tables for either Community/Core or Enterprise, so there is no documented V2 field you must set for it.[[Chart v2 community](https://docs.airbyte.com/platform/2.0/deploying-airbyte/chart-v2-community#update-your-valuesyaml-file); [Chart v2 enterprise](https://docs.airbyte.com/platform/2.0/enterprise-setup/chart-v2-enterprise#update-your-valuesyaml-file)] - It also does not appear in the “V1 key → V2 key” renaming table.[[Chart v2 community](https://docs.airbyte.com/platform/2.0/deploying-airbyte/chart-v2-community#update-your-valuesyaml-file)] So, based on the available information: - There is no documented place in Helm chart V2

values.yaml

where you must define

AIRBYTE_DUMMY_SECRET

. - It appears to be an internal placeholder secret used by abctl-generated manifests, not a configuration you’re expected to carry over manually. If your upgrade is failing with an error specifically about

AIRBYTE_DUMMY_SECRET

being missing, that behavior is not described in the docs; it would likely be an abctl/Helm bug similar to the open issue you’re already seeing.[[Helm issue](https://github.com/airbytehq/airbyte/issues/65129)] In that case, the next step would be: - Check whether abctl created a secret like

airbyte-abctl-airbyte-secrets

containing

AIRBYTE_DUMMY_SECRET

, and - If the failure persists, follow or comment on the open GitHub issue, since the docs don’t provide an official migration path for this variable.

CUSTOMERIO_API_KEY

does have a documented mapping in Helm chart V2. In Helm chart V1 it was an environment variable; in Helm chart V2 you configure it under

global.customerio.apiKey

in your

values.yaml

.[[Chart v2 community](https://docs.airbyte.com/platform/deploying-airbyte/chart-v2-community#update-your-valuesyaml-file); [Chart v2 enterprise](https://docs.airbyte.com/platform/enterprise-setup/chart-v2-enterprise#update-your-valuesyaml-file)] Example:

yaml global:   customerio:     apiKey: "<your-Customer.io-API-key>"

Where the value comes from: - The docs only state the mapping; they do not describe how you originally obtained it. It is your Customer.io workspace API key that you (or your team) configured previously as

CUSTOMERIO_API_KEY

. - For the upgrade, reuse the same value you used in your 1.x deployment and place it in

global.customerio.apiKey

.

You can ignore

CUSTOMERIO_API_KEY

if you don’t use Customer.io. In the Helm chart V2 migration tables,

CUSTOMERIO_API_KEY

is only listed as an optional mapping to `global.customerio.apiKey`; there is no indication that it’s required for Airbyte to run.[[Chart v2 community](https://docs.airbyte.com/platform/deploying-airbyte/chart-v2-community#update-your-valuesyaml-file); [Chart v2 enterprise](https://docs.airbyte.com/platform/enterprise-setup/chart-v2-enterprise#update-your-valuesyaml-file)] So in your `values.yaml`: - Do not set

global.customerio.apiKey

at all, or - Explicitly leave the

customerio

block out. If your deployment is failing specifically because this variable is missing, that behavior is not described in the docs, and the knowledge sources don’t provide a workaround beyond simply omitting it.