@kapa.ai I'm using the helm chart v2 to deploy airbyte. The workload launcher cannot initialize the data-plane. 2025-12-23 093535,663 [main] INFO i.a.f.ConfigFileClient(<init>):141 - path /flags does not exist, will return default flag values 2025-12-23 093535,865 [main] ERROR i.m.r.Micronaut(handleStartupException):362 - Error starting Micronaut server: Failed to initialize data-plane java.lang.RuntimeException: Failed to initialize data-plane at io.airbyte.workload.launcher.authn.DataplaneIdentityService.initialize(DataplaneIdentityService.kt:58) at io.airbyte.workload.launcher.StartupApplicationEventListener.onApplicationEvent(StartupApplicationEventListener.kt:34) at io.airbyte.workload.launcher.StartupApplicationEventListener.onApplicationEvent(StartupApplicationEventListener.kt:20) at io.micronaut.context.event.ApplicationEventPublisherFactory.notifyEventListeners(ApplicationEventPublisherFactory.java:266) at io.micronaut.context.event.ApplicationEventPublisherFactory$2.publishEvent(ApplicationEventPublisherFactory.java:226) at io.micronaut.http.server.netty.discovery.NettyServiceDiscovery.onStart(NettyServiceDiscovery.java:54) at io.micronaut.http.server.netty.discovery.$NettyServiceDiscovery$Definition$Exec.dispatch(Unknown Source) at io.micronaut.context.AbstractExecutableMethodsDefinition$DispatchedExecutableMethod.invoke(AbstractExecutableMethodsDefinition.java:456) at io.micronaut.context.DefaultBeanContext$BeanExecutionHandle.invoke(DefaultBeanContext.java:3987) at io.micronaut.aop.chain.AdapterIntroduction.intercept(AdapterIntroduction.java:91) at io.micronaut.aop.chain.MethodInterceptorChain.proceed(MethodInterceptorChain.java:143) at io.micronaut.http.server.netty.discovery.NettyServiceDiscovery$ApplicationEventListener$onStart1$Intercepted.onApplicationEvent(Unknown Source) at io.micronaut.context.event.ApplicationEventPublisherFactory.notifyEventListeners(ApplicationEventPublisherFactory.java:266) at io.micronaut.context.event.ApplicationEventPublisherFactory$2.publishEvent(ApplicationEventPublisherFactory.java:226) at io.micronaut.http.server.netty.NettyHttpServer.fireStartupEvents(NettyHttpServer.java:720) at io.micronaut.http.server.netty.NettyHttpServer.start(NettyHttpServer.java:330) at io.micronaut.http.server.netty.NettyHttpServer.start(NettyHttpServer.java:124) at io.micronaut.runtime.Micronaut.start(Micronaut.java:81) at io.airbyte.workload.launcher.ApplicationKt.main(Application.kt:10) Caused by: org.openapitools.client.infrastructure.ClientException: Client error : 403 Forbidden at io.airbyte.api.client.generated.DataplaneApi.initializeDataplane(DataplaneApi.kt:377) at io.airbyte.api.client.generated.DataplaneApi.initializeDataplane$default(DataplaneApi.kt:366) at io.airbyte.workload.launcher.authn.DataplaneIdentityService.initialize(DataplaneIdentityService.kt:42) ... 18 common frames omitted What am I missing?

The knowledge sources show the same error pattern with Helm v2 / Airbyte 2.x: the workload-launcher fails with

Failed to initialize data-plane

and a 403 from the server when calling the Dataplane API. [[Multiple issues 2.0.0](https://github.com/airbytehq/airbyte/issues/68134)] From those issues, there are two configuration areas you should check: 1. Dataplane group configuration (v1 → v2 change) When upgrading or deploying v2, if

global.dataplaneGroups.defaultDataplaneGroupName

is left

null

, the platform can’t associate workloads with a dataplane group and things break in non-obvious ways. One user fixed “no jobs launching” by explicitly setting this value in their Helm values: [[airbyte services stuck](https://github.com/airbytehq/airbyte/issues/68115)]

yaml    global:      dataplaneGroups:        defaultDataplaneGroupName: "AUTO"

Make sure you have this (or another valid group name) set in your

values.yaml

before installing/upgrading. 2. Auth / dataplane identity & secrets Several users hit dataplane initialization / auth problems when: - The

airbyte-auth-secrets

secret was pre-created and managed externally, and -

global.auth.instanceAdmin.*

values were pointing to that secret. In those cases, the secret was not updated with the dataplane client credentials, and the workload-launcher could not obtain a valid token. One workaround that resolved “Failed to obtain or add dataplane access token” was to remove those overrides so the chart can manage the secret itself: [[Could not deploy 1.6.x](https://github.com/airbytehq/airbyte/issues/58587)] Specifically, in

values.yaml

either: - Don’t pre-create

airbyte-auth-secrets

, and - Comment out / remove:

yaml      global:        auth:          instanceAdmin:            secretName: airbyte-auth-secrets            emailSecretKey: instance-admin-email            passwordSecretKey: instance-admin-password

or ensure that if you do manage the secret yourself, it is allowed to be updated and actually contains the dataplane client id/secret generated by Airbyte (otherwise the server will return 403 to the workload-launcher). Because the 403 is coming from the Airbyte server’s Dataplane API, the problem is almost certainly with these auth/dataplane settings rather than Kubernetes networking. If after: - Setting

global.dataplaneGroups.defaultDataplaneGroupName

(e.g.

"AUTO"

), and - Letting the chart manage

airbyte-auth-secrets

(or ensuring it’s correctly populated and updatable), you still see the 403, the knowledge sources do not provide further concrete steps for this exact scenario. In that case, you may need to share your

values.yaml

and server logs around the Dataplane API call in a GitHub issue or the forum for more targeted help.

@kapa.ai After doing some research, I've just realised that the airbyte-server-svc selectors are not restrictive enough. This service concerns every pod containing the label app.kubernetes.io/name=airbyte. This leads to routing errors. I manually added an additional label to the server pod, updated the service selectors with this new label, and now everything is working fine. Is there a problem with the chart?

A message from kapa.ai