@kapa.ai I'm getting the following error when trying to deploy airbyte with abctl using chart version 1.8.5:

Encountered an issue deploying Airbyte:                                                                                                                                                                                                                                                                      
            Pod: airbyte-abctl-workload-launcher-5c8f7fdd56-kksdj.187fd31f8c5f4819
            Reason: Failed
            Message: Error: couldn't find key dataplane-client-id in Secret airbyte-abctl/airbyte-auth-secrets
            Count: 13

This error is tied to how the dataplane client credentials (

dataplane-client-id

/

dataplane-client-secret

) are managed inside the

airbyte-auth-secrets

secret, and it has come up repeatedly with abctl / Helm installs (including 1.6.x and later 1.8.x). The knowledge sources show a few important patterns: 1. Having a pre‑created

airbyte-auth-secrets

breaks dataplane secret injection Multiple users who manually created or externally managed the

airbyte-auth-secrets

(to set

instance-admin-email

/

instance-admin-password

) hit exactly your error: > Error: couldn't find key dataplane-client-id in Secret .../airbyte-auth-secrets [[1.6.0 deploy issue](https://github.com/airbytehq/airbyte/issues/58587)] In 1.8.5, a user reports that the workload launcher cannot become healthy and that the issue goes away only when they stop pre‑creating / managing `airbyte-auth-secrets`: > The main problem here is to have the secret airbyte-auth-secrets pre-created. [...] having the secret pre-created and managed externally, the secret was not being updated even though i have configured the role to do so. [...] With Helm v1 + 1.8.5 I commented out: > -

global.auth.instanceAdmin.secretName

> -

global.auth.instanceAdmin.emailSecretKey

> -

global.auth.instanceAdmin.passwordSecretKey

[[1.6.0 deploy issue](https://github.com/airbytehq/airbyte/issues/58587)] Once those are commented out, Helm/bootloader is allowed to create and manage

airbyte-auth-secrets

itself, and the dataplane keys are populated. 2. Workaround from the issue for 1.8.5 that you can apply Based on that report, for chart

1.8.5

installed via `abctl`/Helm, the recommended remediation is: - Do not pre‑create

airbyte-auth-secrets

. - In your values (or

abctl

config) remove or comment out any overrides that fix the auth secret name/keys, for example:

yaml      global:        auth:          instanceAdmin:            # comment these out / remove            # secretName: "airbyte-auth-secrets"            # emailSecretKey: "instance-admin-email"            # passwordSecretKey: "instance-admin-password"

- Delete the existing secret (if present) so Airbyte can recreate it:

bash      kubectl delete secret -n airbyte-abctl airbyte-auth-secrets

- Re‑run the deployment with

abctl

, letting Airbyte create and manage

airbyte-auth-secrets

. The bootloader then populates

dataplane-client-id

and

dataplane-client-secret

and the workload‑launcher should start. [[1.6.0 deploy issue](https://github.com/airbytehq/airbyte/issues/58587)] 3. Why manually patching the secret often doesn’t help Some users tried to: - Read values from the

dataplane_client_credentials

DB table and manually add them to the secret, or - Delete rows from

dataplane

/

dataplane_client_credentials

and reinstall. These attempts did not reliably fix the workload‑launcher error in 1.6.x and 1.8.x, because the bootloader/initializer overwrites or expects to control those values in the auth secret, and a pre‑managed secret interferes with that flow. [[1.6.0 deploy issue](https://github.com/airbytehq/airbyte/issues/58587)] So, for your 1.8.5 abctl deployment, the action most consistent with the reported successful workaround is: 1. Stop manually managing

airbyte-auth-secrets

(remove

global.auth.instanceAdmin.*

overrides). 2. Delete the existing

airbyte-auth-secrets

in the

airbyte-abctl

namespace. 3. Re‑deploy with

abctl

so Airbyte can create and populate the secret (including

dataplane-client-id

). If you’ve already done this and the error persists, the knowledge sources do not provide a confirmed additional fix path beyond the above workaround and version changes (e.g., some users moved to 1.7.1 where things “worked out of the box”). [[1.6.0 chart issue](https://github.com/airbytehq/airbyte/issues/62468)]