https://linen.dev logo
Join Slack
Powered by
We're trying to install Airbyte 2.0.1 with Helm ch...
# replication-ask-ai
t
We're trying to install Airbyte 2.0.1 with Helm chart v2.0.19 on Kubernetes. The bootloader fails and it looks like the database creation also fails. Here are some logs. What are we doing wrong? 2025-12-10 163257 Unsetting empty environment variable 'AB_INSTANCE_ADMIN_CLIENT_SECRET' 2025-12-10 163257 Unsetting empty environment variable 'DEFAULT_DATAPLANE_GROUP_NAME' 2025-12-10 163257 Unsetting empty environment variable 'AB_INSTANCE_ADMIN_CLIENT_ID' 2025-12-10 163257 Unsetting empty environment variable 'AB_JWT_SIGNATURE_SECRET' 2025-12-10 163257 Unsetting empty environment variable 'AB_INSTANCE_ADMIN_PASSWORD' 2025-12-10 163300 2025-12-10 163300 _ _ _ _ 2025-12-10 163300 / | (_)____/ /_ __ __/ /____ 2025-12-10 163300 / /| | / / ___/ __ \/ / / / __/ _ \ 2025-12-10 163300 / _ |/ / / / /_/ / /_/ / /_/ __/ 2025-12-10 163300 /_/ |_/_/_/ /_.___/\__, /\__/\___/ 2025-12-10 163300 /____/ 2025-12-10 163300 : airbyte-bootloader : 2025-12-10 163300 2025-12-10 163306 2025-12-10 163306,684 [main] INFO i.m.c.e.DefaultEnvironment(<init>):170 - Established active environments: [k8s, control-plane, edition-community] 2025-12-10 163309 2025-12-10 163309,864 [main] INFO c.z.h.HikariDataSource(<init>):79 - HikariPool-1 - Starting... 2025-12-10 163309 2025-12-10 163309,987 [main] INFO c.z.h.HikariDataSource(<init>):81 - HikariPool-1 - Start completed. 2025-12-10 163309 2025-12-10 163309,996 [main] INFO c.z.h.HikariDataSource(<init>):79 - HikariPool-2 - Starting... 2025-12-10 163309 2025-12-10 163309,997 [main] INFO c.z.h.HikariDataSource(<init>):81 - HikariPool-2 - Start completed. 2025-12-10 163310 2025-12-10 163310,563 [main] INFO i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'INFO' for logger: 'io.netty' 2025-12-10 163310 2025-12-10 163310,564 [main] INFO i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'ERROR' for logger: 'com.zaxxer.hikari' 2025-12-10 163310 2025-12-10 163310,564 [main] INFO i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'INFO' for logger: 'io.grpc' 2025-12-10 163310 2025-12-10 163310,564 [main] INFO i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'INFO' for logger: 'io.temporal' 2025-12-10 163310 2025-12-10 163310,565 [main] INFO i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'ERROR' for logger: 'com.zaxxer.hikari.pool' 2025-12-10 163310 2025-12-10 163310,565 [main] INFO i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'INFO' for logger: 'io.fabric8.kubernetes.client' 2025-12-10 163316 2025-12-10 163316,066 [main] INFO i.m.r.Micronaut(start):101 - Startup completed in 15475ms. Server Running: http://airbyte-bootloader:9002 2025-12-10 163317 2025-12-10 163317,662 [main] INFO i.a.f.ConfigFileClient(<init>):141 - path /etc/launchdarkly/flags.yml does not exist, will return default flag values 2025-12-10 163319 2025-12-10 163319,466 [main] INFO i.a.c.s.RemoteDefinitionsProvider(<init>):82 - Created remote definitions provider for URL 'https://connectors.airbyte.com/files/' and registry 'oss'... 2025-12-10 163319 2025-12-10 163319,467 [main] INFO i.a.c.i.c.SeedBeanFactory(seedDefinitionsProvider):46 - Using remote definitions provider for seeding 2025-12-10 163320 2025-12-10 163320,789 [main] INFO i.a.b.Bootloader(load):71 - Initializing auth secrets... 2025-12-10 163323 2025-12-10 163323,570 [main] INFO i.a.b.AuthKubernetesSecretInitializer(initializeSecrets):30 - Initializing auth secret in Kubernetes... 2025-12-10 163323 2025-12-10 163323,673 [main] INFO i.a.b.AuthKubernetesSecretInitializer(getOrCreateSecretValue):108 - Using existing value for secret key instance-admin-password 2025-12-10 163323 2025-12-10 163323,762 [main] INFO i.a.b.AuthKubernetesSecretInitializer(getOrCreateSecretValue):108 - Using existing value for secret key instance-admin-client-id 2025-12-10 163323 2025-12-10 163323,775 [main] INFO i.a.b.AuthKubernetesSecretInitializer(getOrCreateSecretValue):108 - Using existing value for secret key instance-admin-client-secret 2025-12-10 163323 2025-12-10 163323,788 [main] INFO i.a.b.AuthKubernetesSecretInitializer(getOrCreateSecretValue):108 - Using existing value for secret key jwt-signature-secret 2025-12-10 163323 2025-12-10 163323,877 [main] INFO i.a.b.K8sSecretHelper(createOrUpdateSecret):45 - Secret with name airbyte-auth-secrets already exists. Updating it... 2025-12-10 163323 2025-12-10 163323,973 [main] INFO i.a.b.K8sSecretHelper(createOrUpdateSecret):53 - Successfully updated secret airbyte-auth-secrets 2025-12-10 163323 2025-12-10 163323,974 [main] INFO i.a.b.AuthKubernetesSecretInitializer(initializeSecrets):32 - Finished initializing auth secret. 2025-12-10 163323 2025-12-10 163323,975 [main] INFO i.a.b.Bootloader(load):76 - Initializing databases... 2025-12-10 163323 2025-12-10 163323,975 [main] INFO i.a.b.Bootloader(initializeDatabases):220 - Initializing databases... 2025-12-10 163323 2025-12-10 163323,977 [main] WARN i.a.d.c.DatabaseAvailabilityCheck$DefaultImpls(check):65 - Waiting for database to become available... 2025-12-10 163323 2025-12-10 163323,980 [main] INFO i.a.d.c.DatabaseAvailabilityCheck$DefaultImpls(isDatabaseConnected$lambda$6):96 - Testing airbyte configs database connection... 2025-12-10 163355 2025-12-10 163355,071 [main] [1;31mERROR[0;39m i.a.d.c.DatabaseAvailabilityCheck$DefaultImpls(isDatabaseConnected$lambda$6):103 - Failed to verify database connection. 2025-12-10 163355 org.jooq.exception.DataAccessException: Error getting connection from data source HikariDataSource (HikariPool-2) 2025-12-10 163355 at io.airbyte.db.init.DatabaseInitializer$DefaultImpls.initialize(DatabaseInitializer.kt:85) 2025-12-10 163355 at io.airbyte.db.init.ConfigsDatabaseInitializer.initialize(ConfigsDatabaseInitializer.kt:20) 2025-12-10 163355 at io.airbyte.bootloader.Bootloader.initializeDatabases(Bootloader.kt:221) 2025-12-10 163355 at io.airbyte.bootloader.Bootloader.load(Bootloader.kt:77) 2025-12-10 163355 at io.airbyte.bootloader.ApplicationKt.main(Application.kt:25) 2025-12-10 163355 Caused by: java.sql.SQLTransientConnectionException: HikariPool-2 - Connection is not available, request timed out after 30064ms (total=0, active=0, idle=0, waiting=0) 2025-12-10 163355 at com.zaxxer.hikari.pool.HikariPool.createTimeoutException(HikariPool.java:709) 2025-12-10 163355 at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:188) 2025-12-10 163355 at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:146) 2025-12-10 163355 at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:99) 2025-12-10 163355 at org.jooq.impl.DataSourceConnectionProvider.acquire(DataSourceConnectionProvider.java:87) 2025-12-10 163355 ... 24 common frames omitted 2025-12-10 163355 Caused by: org.postgresql.util.PSQLException: Connection to airbyte-db-svc.airbyte.svc.cluster.local:5432 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections. 2025-12-10 163540 2025-12-10 163543 2025-12-10 163543,083 [main] [1;31mERROR[0;39m i.a.d.c.DatabaseAvailabilityCheck$DefaultImpls(isDatabaseConnected$lambda$6):103 - Failed to verify database connection. 2025-12-10 163543 org.jooq.exception.DataAccessException: Error getting connection from data source HikariDataSource (HikariPool-2) 2025-12-10 163543 at org.jooq_3.19.18.POSTGRES.debug(Unknown Source) 2025-12-10 163543 at org.jooq.impl.DataSourceConnectionProvider.acquire(DataSourceConnectionProvider.java:90) 2025-12-10 163543 at org.jooq.impl.DefaultExecuteContext.connection(DefaultExecuteContext.java:651) 2025-12-10 163543 at org.jooq.impl.AbstractQuery.connection(AbstractQuery.java:388) ... 2025-12-10 163543 at io.airbyte.db.check.DatabaseAvailabilityCheck$DefaultImpls.isDatabaseConnected$lambda$6(DatabaseAvailabilityCheck.kt:97) 2025-12-10 163543 at io.airbyte.db.check.DatabaseAvailabilityCheck$DefaultImpls.check(DatabaseAvailabilityCheck.kt:71) 2025-12-10 163543 at io.airbyte.db.check.ConfigsDatabaseAvailabilityCheck.check(ConfigsDatabaseAvailabilityCheck.kt:18) 2025-12-10 163543 at io.airbyte.db.init.DatabaseInitializer$DefaultImpls.initialize(DatabaseInitializer.kt:85) 2025-12-10 163543 at io.airbyte.db.init.ConfigsDatabaseInitializer.initialize(ConfigsDatabaseInitializer.kt:20) 2025-12-10 163543 at io.airbyte.bootloader.Bootloader.initializeDatabases(Bootloader.kt:221) 2025-12-10 163543 at io.airbyte.bootloader.Bootloader.load(Bootloader.kt:77) 2025-12-10 163543 at io.airbyte.bootloader.ApplicationKt.main(Application.kt:25) 2025-12-10 163543 Caused by: java.sql.SQLTransientConnectionException: HikariPool-2 - Connection is not available, request timed out after 30000ms (total=0, active=0, idle=0, waiting=0) 2025-12-10 163543 at com.zaxxer.hikari.pool.HikariPool.createTimeoutException(HikariPool.java:709) 2025-12-10 163543 at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:188) 2025-12-10 163543 at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:146) 2025-12-10 163543 at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:99) 2025-12-10 163543 at org.jooq.impl.DataSourceConnectionProvider.acquire(DataSourceConnectionProvider.java:87) 2025-12-10 163543 ... 24 common frames omitted 2025-12-10 163543 Caused by: org.postgresql.util.PSQLException: Connection to airbyte-db-svc.airbyte.svc.cluster.local:5432 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections. 2025-12-10 163543 Caused by: java.net.ConnectException: Connection refused 2025-12-10 163543 at java.base/sun.nio.ch.Net.pollConnect(Native Method) 2025-12-10 163543 at java.base/sun.nio.ch.Net.pollConnectNow(Net.java:682) 2025-12-10 163543 at java.base/sun.nio.ch.NioSocketImpl.timedFinishConnect(NioSocketImpl.java:542) 2025-12-10 163543 at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:592) 2025-12-10 163543 at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:327) 2025-12-10 163543 at java.base/java.net.Socket.connect(Socket.java:751) 2025-12-10 163543 at org.postgresql.core.PGStream.createSocket(PGStream.java:261) 2025-12-10 163543 at org.postgresql.core.PGStream.<init>(PGStream.java:122) 2025-12-10 163543 at org.postgresql.core.v3.ConnectionFactoryImpl.tryConnect(ConnectionFactoryImpl.java:146) 2025-12-10 163543 at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:289) 2025-12-10 163543 ... 14 common frames omitted 2025-12-10 163655 2025-12-10 163655 2025-12-10 163655,091 [main] INFO i.a.d.c.DatabaseAvailabilityCheck$DefaultImpls(check):73 - Database is not ready yet. Please wait a moment, it might still be initializing... 2025-12-10 163701 2025-12-10 163701,091 [main] WARN i.a.d.c.DatabaseAvailabilityCheck$DefaultImpls(check):65 - Waiting for database to become available... 2025-12-10 163701 2025-12-10 163701,092 [main] INFO i.a.d.c.DatabaseAvailabilityCheck$DefaultImpls(isDatabaseConnected$lambda$6):96 - Testing airbyte configs database connection...
k
You’re not doing anything obviously wrong in Kubernetes itself—the issue is the specific Helm chart version you’re using. From the logs, the bootloader is repeatedly failing to connect to Postgres: > Connection to 
airbyte-db-svc.airbyte.svc.cluster.local:5432
refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections. That means: - The bootloader pod is starting correctly. - It cannot open a TCP connection to the database service hostname/port. - Either the DB pod/service is not up, or the chart’s DB configuration is broken. For Airbyte 2.0.x there was a known problem with the 2.0.0 / 2.0.1 Helm charts. Those chart versions were removed from the repo and are no longer deployable; instead, you must use a 1.x chart version to deploy Airbyte 2.0.1. [[Multiple issues](https://github.com/airbytehq/airbyte/issues/68134); [Chart error](https://github.com/airbytehq/airbyte/issues/68136)] Specifically: - The v2 charts 
2.0.0
and 
2.0.1
were deleted from the Helm repo and Artifact Hub and should not be used.[[Chart error](https://github.com/airbytehq/airbyte/issues/68136)] - To deploy Airbyte 2.0.1, you should deploy Helm chart v1.9.1 from the v1 Helm repo.[[Chart error](https://github.com/airbytehq/airbyte/issues/68136)] Also, note that the v2 Helm charts live in a different Helm repo than v1:
Copy code
bash # V1 repo helm repo add airbyte <https://airbytehq.github.io/helm-charts> helm repo update  # V2 repo helm repo add airbyte-v2 <https://airbytehq.github.io/charts> helm repo update ```[[Add Helm repo](<https://docs.airbyte.com/platform/deploying-airbyte#1-add-the-helm-repository>); [Multiple issues](<https://github.com/airbytehq/airbyte/issues/68134>)]  ### What to do  1. **Stop using Helm chart v2.0.19 for 2.0.1**; instead: 2. Add/update the **v1** Helm repo:     ```bash    helm repo add airbyte <https://airbytehq.github.io/helm-charts>    helm repo update
3. Install / upgrade using chart 
airbyte/airbyte
version 
1.9.1
, which is the supported chart for Airbyte 2.0.1 (per the GitHub issue):
Copy code
bash    helm upgrade --install airbyte airbyte/airbyte \      --version 1.9.1 \      --namespace airbyte \      --create-namespace \      -f your-values.yaml
4. After redeploying with chart 1.9.1, check that the Postgres pod and service are up:
Copy code
bash    kubectl get pods,svc -n airbyte
If, after switching to chart 1.9.1, the DB is still not coming up, the knowledge sources don’t provide further detail on additional DB-specific misconfigurations; at that point you’d need to inspect the Postgres pod logs and your custom values, but that’s beyond what’s covered in the provided docs/issues.
t
@kapa.ai Is this set up correctly to use Helm Chart v2.0.19 on Airbyte 2.0.1? Can you see any reason why our deployment would fail? airbyte\base\helmrepository.yaml: apiVersion: source.toolkit.fluxcd.io/v1 kind: HelmRepository metadata: name: airbyte namespace: airbyte spec: interval: 1h url: https://airbytehq.github.io/charts airbyte\base\helmrelease.yaml: apiVersion: helm.toolkit.fluxcd.io/v2 kind: HelmRelease metadata: name: airbyte namespace: airbyte spec: interval: 1h chart: spec: chart: airbyte sourceRef: kind: HelmRepository name: airbyte namespace: airbyte version: 2.0.19 values: global: airbyteUrl: https://airbyte.${zone_name} edition: community image: registry: ${ecr_mirror}.dkr.ecr.eu-west-1.amazonaws.com/dockerhub tag: 2.0.1 logging: level: 'INFO' serviceAccountName: airbyte-admin minio: enabled: false postgresql: enabled: true temporal: livenessProbe: enabled: true readinessProbe: enabled: true serviceAccount: create: true name: airbyte-admin annotations: eks.amazonaws.com/role-arn: arnawsiam::${aws_account}:role/airbyte airbyte\staging\helmrelease-patch.yaml: apiVersion: helm.toolkit.fluxcd.io/v2 kind: HelmRelease metadata: name: airbyte namespace: airbyte spec: values: global: storage: type: s3 bucket: log: tails-airbyte-staging state: tails-airbyte-staging workloadOutput: tails-airbyte-staging s3: region: eu-west-1 authenticationType: instanceProfile minio: enabled: false postgresql: enabled: true airbyteBootloader: resources: requests: cpu: 250m memory: 256Mi limits: cpu: 500m memory: 1Gi cron: resources: requests: cpu: 100m memory: 300Mi server: resources: requests: cpu: 250m memory: 512Mi extraEnv: - name: AWS_REGION value: eu-west-1 temporal: resources: requests: cpu: 100m memory: 512Mi worker: resources: requests: cpu: 300m memory: 1Gi extraEnv: - name: AWS_REGION value: eu-west-1 workloadApiServer: resources: requests: cpu: 150m memory: 512Mi workloadLauncher: resources: requests: cpu: 100m memory: 300Mi
k
A message from kapa.ai
No—based on the provided docs and GitHub issues, that setup is not a supported / recommended combination, and it can definitely explain your failing deployment. ### 1. Chart repo and chart name You are correctly pointing Flux to the Helm chart V2 repo:
Copy code
yaml spec:   url: <https://airbytehq.github.io/charts>
That is the documented v2 repo (
airbyte-v2
), distinct from the v1 repo (
airbyte
).[[Add repo](https://docs.airbyte.com/platform/deploying-airbyte#1-add-the-helm-repository)] However, in this repo, the chart is conventionally referenced as 
airbyte-v2/airbyte
when installing via 
helm
.[[Install v2](https://docs.airbyte.com/platform/deploying-airbyte/chart-v2-community#deploy-airbyte); [Next install](https://docs.airbyte.com/platform/next/deploying-airbyte/chart-v2-community#deploy-airbyte)] Flux’s 
HelmRelease
uses the repository URL + 
chart: airbyte
, which is fine as long as the chart actually exists there under that name—which it does according to the docs—so this part is probably okay and consistent with the “airbyte-v2/airbyte” chart in that repo. ### 2. Version compatibility: chart vs. app The crucial mismatch is:
Copy code
yaml version: 2.0.19      # Helm chart ... global.image.tag: 2.0.1  # Airbyte app
The v2 docs stress that Helm chart versions and Airbyte platform versions do not match and that each chart is designed for a specific Airbyte app version (shown as 
APP VERSION
). You must choose the chart version first, based on the 
APP VERSION
column of 
helm search repo airbyte-v2 --versions
, and then deploy that chart version; the chart itself pulls the correct Airbyte image version.[[Chart v2 mapping](https://docs.airbyte.com/platform/deploying-airbyte/chart-v2-community#deploy-airbyte); [Next chart v2 mapping](https://docs.airbyte.com/platform/next/deploying-airbyte/chart-v2-community#deploy-airbyte); [Enterprise chart v2](https://docs.airbyte.com/platform/enterprise-setup/chart-v2-enterprise#deploy-airbyte)] The docs show (for example):
Copy code
text NAME                CHART VERSION   APP VERSION airbyte-v2/airbyte  2.0.18          2.0.0 airbyte-v2/airbyte  2.0.17          1.8.5 ... airbyte-v2/airbyte  2.0.1           1.6.1 airbyte-v2/airbyte  2.0.0           1.6.0 ```[[Chart v2 mapping](<https://docs.airbyte.com/platform/deploying-airbyte/chart-v2-community#deploy-airbyte>)]  So:  - To run **Airbyte 2.0.0**, you use **chart `2.0.18`**.   - To run **Airbyte 1.8.5**, you use **chart `2.0.17`**.    The knowledge sources you provided **do not list a chart 2.0.19** at all, so there is no documented mapping from chart `2.0.19` to a particular Airbyte APP VERSION. I cannot find any official confirmation that chart `2.0.19` is intended for Airbyte `2.0.1` or any guidance to override the image tag the way you’re doing.    The maintainers explicitly warn that for Helm v2 you must:  - Look up the chart/App mapping with `helm search repo airbyte-v2 --versions`. - Deploy using the **Helm chart version**, *not* by trying to force a different platform version.[[Multiple issues](<https://github.com/airbytehq/airbyte/issues/68134>)]  This makes your combo (chart 2.0.19 + image tag 2.0.1) unsupported per the docs, and it’s a plausible root cause for DB-related failures.  ### 3. Known 2.0.x chart issues  For v1 charts and 2.0.x platform, maintainers removed chart versions `2.0.0` and `2.0.1` from the **v1** repo because they were problematic and clarified that you must deploy 2.0.1 using `v1.9.1` instead.[[Chart error](<https://github.com/airbytehq/airbyte/issues/68136>)]    Separately, they emphasise:  > Helm chart V2 and Airbyte version 2.0 aren’t the same thing. You can still use your old Helm chart V1 with Airbyte 2.0, or Helm Chart V2 with Airbyte 1.x. If you are ready to migrate to Helm chart V2, you can, but it’s not obligatory until Airbyte 2.1.[[Multiple issues](<https://github.com/airbytehq/airbyte/issues/68134>)]  So for **Airbyte 2.0.1**, the documented safe path is:  - Use **v1 Helm chart** with a supported version (e.g. `1.9.1`) to run 2.0.1.[[Chart error](<https://github.com/airbytehq/airbyte/issues/68136>)] - Or, if using v2 charts, pick a chart version whose `APP VERSION` matches a supported 1.x or 2.0.0 per the mapping in the docs; there is no official statement in these sources that 2.0.19 is meant for 2.0.1.  ### 4. Why this could manifest as DB connection failures  Your logs (from the previous message) show the bootloader cannot reach `airbyte-db-svc.airbyte.svc.cluster.local:5432`. The provided sources do not give a line‑by‑line mapping of all `values.yaml` keys for v2.0.19, but they do say that v2 Helm charts are significantly different and require careful migration of values.[[Multiple issues](<https://github.com/airbytehq/airbyte/issues/68134>)]    Running an **undocumented chart version** (`2.0.19`) together with a **manually forcibly-set image tag** (`2.0.1`) means:  - You have no guarantee that the DB service / statefulset / env vars / probes in chart 2.0.19 match what the 2.0.1 image expects. - If the chart’s built‑in Postgres config changed (e.g., service name, port, timing, init containers), the bootloader could fail to connect exactly as you’re seeing.  Because the docs you shared don’t include 2.0.19 or its `values`, I can’t definitively point to a specific mis‑keyed value in your snippet. But the **version mismatch itself is already outside the documented, supported matrix** and is a sufficient explanation for “mysterious” bootloader/DB failures.  ### 5. Concrete next steps (within what the docs support)  Within the constraints of the knowledge you provided, the safest options are:  1. **If you must stay on Airbyte 2.0.1:**      Use *v1* Helm chart `1.9.1` from the `<https://airbytehq.github.io/helm-charts>` repo, as the maintainers explicitly recommend for 2.0.1.[[Chart error](<https://github.com/airbytehq/airbyte/issues/68136>)]  2. **If you want to use Helm chart v2:**      - List v2 charts and their `APP VERSION` with:      ```bash      helm search repo airbyte-v2 --versions
[[Chart v2 mapping](https://docs.airbyte.com/platform/deploying-airbyte/chart-v2-community#deploy-airbyte)] - Pick the chart version whose APP VERSION is officially the one you want (e.g. chart 
2.0.18
→ app 
2.0.0
). - Let the chart manage the Airbyte image tag instead of overriding 
global.image.tag
to 2.0.1. Given the docs and issues you shared, I can’t confirm that 
2.0.19
is a valid or recommended chart version for 2.0.1, and the maintainers explicitly advise against assuming chart and app versions line up. That’s the main reason your deployment is likely failing.
Open in Slack
PreviousNext
Powered by