global.version

(often referred to as the “global Airbyte version” in the Helm chart) is the Helm value that sets the Airbyte deployment version, and it corresponds to the

AIRBYTE_VERSION

configuration variable. [[Update values.yaml](https://docs.airbyte.com/platform/deploying-airbyte/chart-v2-community#update-your-valuesyaml-file); [Configuring Airbyte](https://docs.airbyte.com/platform/operator-guides/configuring-airbyte)] In

values.yaml

it appears as:

yaml global:   version: "<your-airbyte-version>"

This is what you set to choose which Airbyte image/version your deployment runs.

From the provided knowledge, the latest versions mentioned are: - Helm chart V1 repo (

airbyte/airbyte

): up to chart version 1.9.1 with app version 2.0.1 in a GitHub issue example. [[Helm install issue](https://github.com/airbytehq/airbyte/issues/68136)] - Helm chart V2 repo (

airbyte-v2/airbyte

): up to chart version 2.0.18 with app version 2.0.0 in the docs. [[Install Airbyte](https://docs.airbyte.com/platform/deploying-airbyte#5-installing-airbyte); [Chart v2 upgrade](https://docs.airbyte.com/platform/deploying-airbyte/chart-v2-community#deploy-airbyte)] The docs don’t state if anything newer exists beyond these examples, so I can only say these are the latest versions shown in the provided sources. ### What each “version” means 1. Chart version - This is the Helm chart’s own version (e.g.

2.0.18

for

airbyte-v2/airbyte

). - It controls the Kubernetes manifests, configuration structure, etc., and is what you pass with

--version

in

helm install

. [[Chart v2 upgrade](https://docs.airbyte.com/platform/deploying-airbyte/chart-v2-community#deploy-airbyte)] 2. App version - This is the Airbyte platform version that the chart deploys (e.g. chart

2.0.18

has app version

2.0.0

). [[Install Airbyte](https://docs.airbyte.com/platform/deploying-airbyte#5-installing-airbyte)] - It corresponds to the Airbyte Docker images used by the chart. 3. Global version (

global.version

) - A value in

values.yaml

under

global.version

that sets the Airbyte deployment version, corresponding to

AIRBYTE_VERSION

. - It determines which Airbyte image/version your deployment runs. [[Chart v2 upgrade](https://docs.airbyte.com/platform/deploying-airbyte/chart-v2-community#deploy-airbyte)] Example (V2 chart):

bash helm search repo airbyte-v2 --versions # shows lines like: # airbyte-v2/airbyte  2.0.18  2.0.0  Helm chart to deploy airbyte

bash helm install airbyte airbyte-v2/airbyte \   --namespace airbyte-v2 \   --values ./values.yaml \   --version 2.0.18

Here: -

2.0.18

= chart version -

2.0.0

= app (Airbyte) version -

global.version

in

values.yaml

should match the Airbyte version you intend to run.

The error happens because the

airbyte/webapp:2.0.1

image does not exist. The webapp was removed starting with Airbyte 1.8 and its UI is now bundled into the

airbyte-server

image, so any attempt to pull

airbyte/webapp:*

for newer versions will fail. [[Airbyte 1.8 notes](https://docs.airbyte.com/release_notes/v-1.8#breaking-changes); [Helm 1.8.0 webapp issue](https://github.com/airbytehq/airbyte/issues/65096); [2.0.0 webapp pull failure](https://github.com/airbytehq/airbyte/issues/68134)] From the issues: - Users see exactly your error for

airbyte/webapp:2.0.0

and

1.8.x

because the image is gone. [[2.0.0 webapp pull failure](https://github.com/airbytehq/airbyte/issues/68134); [Helm 1.8.0 webapp issue](https://github.com/airbytehq/airbyte/issues/65096)] - Workarounds mentioned: - Disable webapp in the Helm chart: set

webapp.enabled: false

in your

values.yaml

. [[2.0.0 chart issues](https://github.com/airbytehq/airbyte/issues/68134); [Missing WEBAPP_URL](https://github.com/airbytehq/airbyte/issues/68659)] - Or, better, use a Helm chart that no longer deploys webapp: - For Helm chart V1: use chart

1.9.1

to deploy Airbyte

2.0.1

(charts

2.0.0

and

2.0.1

were removed). [[Error installing via Helm](https://github.com/airbytehq/airbyte/issues/68136)] - Or migrate to the V2 Helm chart repo (

airbyte-v2

), which is designed for Airbyte 2.x and doesn’t require a separate webapp. [[Chart v2 repo](https://github.com/airbytehq/airbyte/issues/68134)] What you should do now 1. Check which chart you’re using: - If it’s the legacy

airbyte/airbyte

chart and it still has a

webapp

section, add to your `values.yaml`:

yaml      webapp:        enabled: false

- Then redeploy. 2. Alternatively, switch to a compatible chart version: - For Airbyte 2.0.1 with V1 chart: use chart

1.9.1

. [[Error installing via Helm](https://github.com/airbytehq/airbyte/issues/68136)] - Or add the V2 repo and use a V2 chart (e.g.

2.0.18

for Airbyte 2.0.0 as shown in the issues). [[Chart v2 repo](https://github.com/airbytehq/airbyte/issues/68134)] Once webapp is disabled or you’re on a chart that doesn’t deploy it, the UI will be served from

airbyte-server

(port 8001 by default), and the

airbyte/webapp:*

pull error will disappear.

The knowledge sources don’t describe how to enable OAuth/SSO login to the Airbyte UI in versions where

webapp

has been removed, and they also don’t show any replacement configuration knobs for that flow. They only cover: 1. Removal of

airbyte-webapp

and the fact that the UI is now bundled into

airbyte-server

from 1.8 onward. [[Airbyte 1.8 breaking](https://docs.airbyte.com/release_notes/v-1.8#breaking-changes)] 2. Ingress changes needed because

webapp

no longer exists. [[Ingress 1.7+](https://docs.airbyte.com/platform/1.8/deploying-airbyte/integrations/ingress-1-7); [Ingress next](https://docs.airbyte.com/platform/next/deploying-airbyte/integrations/ingress-1-7)] 3. OAuth for connectors (to third‑party APIs) and API client credentials, not login/SSO to the UI. [[Using OAuth](https://docs.airbyte.com/platform/using-airbyte/oauth); [Configuring API access](https://docs.airbyte.com/platform/using-airbyte/configuring-api-access)] In particular: - The OAuth docs explain how to set Client ID / Client Secret for connectors (e.g., Google, Facebook) and how to create an Application to get

client_id

/

client_secret

for API access, but they do not mention configuring OAuth/SSO for user login in self‑managed/community, nor any dependency on

webapp

for that. [[Using OAuth](https://docs.airbyte.com/platform/using-airbyte/oauth); [Configuring API access](https://docs.airbyte.com/platform/using-airbyte/configuring-api-access)] - The breaking‑change and ingress docs only say that the UI is now served from `airbyte-server`; they don’t add any steps for enabling or configuring OAuth login in this new architecture. [[Airbyte 1.8 breaking](https://docs.airbyte.com/release_notes/v-1.8#breaking-changes); [Ingress 1.7+](https://docs.airbyte.com/platform/1.8/deploying-airbyte/integrations/ingress-1-7)] Because of this, I cannot reliably tell you: - How to enable OAuth/SSO login to the UI in current Community Edition without

webapp

, or - Whether the old “enable webapp to configure OAuth login” flow has a documented replacement. What is documented and still valid without `webapp`: - Connector OAuth: you can continue to configure OAuth for connectors by entering Client ID/Secret in each connector’s settings; this is independent of

webapp

. [[Using OAuth](https://docs.airbyte.com/platform/using-airbyte/oauth)] - API OAuth (client credentials): you can create an Application in the UI and use its

client_id

/

client_secret

to obtain access tokens for the Airbyte API; this also does not depend on

webapp

. [[Configuring API access](https://docs.airbyte.com/platform/using-airbyte/configuring-api-access)] For OAuth/SSO login to the Airbyte UI itself, the provided knowledge sources do not contain enough information to describe how to do this in versions where

webapp

is removed. You’ll need to check the full Airbyte docs site for SSO/IdP configuration for self‑managed, or open a GitHub issue / community forum thread to confirm the current support and exact configuration steps.