@kapa.ai I have been trying to deploy a Self-Managed Community version Airbyte Platform app v1.8.5 and chart v2.0.17 in my GKE cluster using helm chart v2.0. Getting following error in airbyte-server module.

io.micronaut.context.exceptions.ConfigurationException: Could not resolve placeholder ${WEBAPP_URL}

The knowledge sources show that this

WEBAPP_URL

placeholder error can happen when migrating to / using Helm chart V2, because: • Since Airbyte 1.8, the separate

airbyte-webapp

component was removed and the webapp is bundled into the

airbyte-server

image, but some components (including

airbyte-server

) may still expect

WEBAPP_URL

to be present as an environment variable. [Multiple issues; Missing WEBAPP_URL] • In chart V2, the documented mapping is: ◦

AIRBYTE_URL

→

global.airbyteUrl

◦

WEBAPP_URL

→

global.webapp.url

[Chart v2 mapping] However, there is a known issue where

WEBAPP_URL

is not actually rendered into the env ConfigMap even when

global.webapp.url

is set, causing exactly the error you’re seeing. One user worked around it by manually adding

WEBAPP_URL

to the

env-configmap.yaml

so that the

airbyte-airbyte-env

ConfigMap contains it. [Missing WEBAPP_URL] Given only the provided sources, the most concrete, supported options are: 1. Set

WEBAPP_URL

via Helm values (intended path) In your

values.yaml

for chart

2.0.17

(Self‑Managed Community 1.8.5):

global:
     airbyteUrl: "https://your-airbyte-domain.example.com"   # or your ingress URL
     webapp:
       url: "https://your-airbyte-domain.example.com"        # maps to WEBAPP_URL

This is how the docs say

WEBAPP_URL

should be configured. [Chart v2 mapping] 2. If the above still doesn’t populate

WEBAPP_URL

(known bug) The sources indicate that in some chart versions,

WEBAPP_URL

is not emitted even when

global.webapp.url

is set. In that case, the documented workaround is to manually ensure

WEBAPP_URL

is present in the env ConfigMap used by

airbyte-server

(typically

airbyte-airbyte-env

), e.g. by editing the rendered

env-configmap.yaml

before applying it, or by adding an extra env var through your own overlay so that

WEBAPP_URL

exists. [Missing WEBAPP_URL] Because the knowledge sources don’t include the exact templates for chart

2.0.17

, I can’t say with certainty whether setting

global.webapp.url

alone will fix it in that specific version. If you’ve already set

global.webapp.url

and still see the error, the sources explicitly confirm that manually adding

WEBAPP_URL

to the env ConfigMap is a valid workaround. [Missing WEBAPP_URL] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai Now

dataplane-client-id

and

dataplane-client-secret

are not created in

airbyte-auth-secrets

during helm deployment.

The knowledge sources show this is a known issue pattern around 1.6–1.8 and Helm, but they do not document a supported way to force‑create

dataplane-client-id

/

dataplane-client-secret

in

airbyte-auth-secrets

for your exact combo (app 1.8.5, chart 2.0.17). I’ll summarize what is known and what has worked for others, but note that this is based on issues, not official guidance. What’s going on • The bootloader / workload‑launcher expects

dataplane-client-id

and

dataplane-client-secret

keys in the

airbyte-auth-secrets

secret and fails with errors like “couldn’t find key dataplane-client-id in Secret …/airbyte-auth-secrets” when they’re missing. [1.6.x dataplane error; 1.6.0 install fails] • When users pre‑create

airbyte-auth-secrets

(for instance admin email/password), the bootloader sometimes does not add or update the dataplane keys, so they never appear. [1.6.x dataplane error] Workarounds observed in the sources 1. Let Airbyte create

airbyte-auth-secrets

itself One user who had the same problem (missing dataplane keys in

airbyte-auth-secrets

) fixed it by: ◦ Removing their custom

airbyte-auth-secrets

configuration from

values.yaml

(these fields): ▪︎

global.auth.instanceAdmin.secretName

▪︎

global.auth.instanceAdmin.emailSecretKey

▪︎

global.auth.instanceAdmin.passwordSecretKey

[Failed to obtain dataplane token] ◦ Deleting the existing

airbyte-auth-secrets

from the cluster. ◦ Re‑deploying Helm so that Airbyte could create

airbyte-auth-secrets

on its own. After that, the secret contained both the instance admin keys and the

dataplane-client-id

/

dataplane-client-secret

, and the workload‑launcher started working. [Failed to obtain dataplane token] 2. Avoid managing

airbyte-auth-secrets

externally The same user notes that when they tried to manage

airbyte-auth-secrets

themselves (pre‑created secret, managed externally), the dataplane keys were not updated even though the role should have allowed it. [Failed to obtain dataplane token] So the pattern from the issues is: ◦ If you must manage instance admin credentials, avoid pre‑creating `airbyte-auth-secrets`; instead, let Airbyte own that secret and configure admin credentials some other way. ◦ If you already pre‑created it, delete it and redeploy so the bootloader can recreate and populate it. What you can try for 1.8.5 / chart 2.0.17 Given the above (and the lack of 2.0.17‑specific docs in the sources), the most consistent approach based on real reports is: 1. Remove any configuration that points Airbyte at a pre‑existing

airbyte-auth-secrets

(e.g.

global.auth.instanceAdmin.secretName

etc., if you have them set). 2. Delete the

airbyte-auth-secrets

secret from your namespace. 3. Re‑run your Helm install/upgrade and let Airbyte recreate

airbyte-auth-secrets

. 4. Inspect the secret to confirm it now contains

dataplane-client-id

and

dataplane-client-secret

. If you’ve already done exactly this and the keys are still not created, the knowledge sources do not provide a documented, supported way to manually seed those values for this version; they only show that: • Manually copying values from

dataplane_client_credentials

into the secret did not work for at least one user. [1.6.x dataplane error] • Some users simply moved to a later version (e.g. 1.7.1) where things “worked out of the box.” [1.6.0 install fails] So if the “let Airbyte recreate `airbyte-auth-secrets`” approach doesn’t fix it on 1.8.5 / 2.0.17, the available sources don’t give enough detail to recommend a safe manual fix. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.