HEX
Server: LiteSpeed
System: Linux houston.panomity.com 6.8.0-100-generic #100-Ubuntu SMP PREEMPT_DYNAMIC Tue Jan 13 16:40:06 UTC 2026 x86_64
User: nudepix (1011)
PHP: 7.4.33
Disabled: pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_get_handler,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,pcntl_async_signals,pcntl_unshare,
Upload Files
File: //opt/agentcloud/airbyte/docs/deploying-airbyte/on-kubernetes-via-helm.md
# Deploy Airbyte on Kubernetes using Helm

## Overview

Airbyte allows scaling sync workloads horizontally using Kubernetes. The core components \(api
server, worker, etc\) run as deployments while the scheduler launches connector-related pods on
different nodes.

## Quickstart

If you don't want to configure your own Kubernetes cluster and Airbyte instance, you can use the
free, open-source project [Plural](https://www.plural.sh/) to bring up a Kubernetes cluster and
Airbyte for you. Use [this guide](on-plural.md) to get started.

Alternatively, you can deploy Airbyte on [Restack](https://www.restack.io) to provision your
Kubernetes cluster on AWS. Follow [this guide](on-restack.md) to get started.

:::note

Airbyte running on Self-Hosted Kubernetes doesn't support DBT Transformations. Please refer to
[#5901](https://github.com/airbytehq/airbyte/issues/5091)

:::

:::note

Airbyte Kubernetes Community Edition does not support basic auth by default. To enable basic auth,
consider adding a reverse proxy in front of Airbyte.

:::

## Getting Started

### Cluster Setup

For local testing we recommend following one of the following setup guides:

- [Docker Desktop \(Mac\)](https://docs.docker.com/desktop/kubernetes)
- [Minikube](https://minikube.sigs.k8s.io/docs/start)
  - NOTE: Start Minikube with at least 4gb RAM with `minikube start --memory=4000`
- [Kind](https://kind.sigs.k8s.io/docs/user/quick-start/)

For testing on GKE you can
[create a cluster with the command line or the Cloud Console UI](https://cloud.google.com/kubernetes-engine/docs/how-to/creating-a-zonal-cluster).

For testing on EKS you can [install eksctl](https://eksctl.io/introduction/) and run
`eksctl create cluster` to create an EKS cluster/VPC/subnets/etc. This process should take 10-15
minutes.

For production, Airbyte should function on most clusters v1.19 and above. We have tested support on
GKE and EKS. If you run into a problem starting Airbyte, please reach out on the `#troubleshooting`
channel on our [Slack](https://slack.airbyte.io/) or
[create an issue on GitHub](https://github.com/airbytehq/airbyte/issues/new?assignees=&labels=type%2Fbug&template=bug-report.md&title=).

### Install `kubectl`

If you do not already have the CLI tool `kubectl` installed, please follow
[these instructions to install](https://kubernetes.io/docs/tasks/tools/).

### Configure `kubectl`

Configure `kubectl` to connect to your cluster by using `kubectl use-context my-cluster-name`.

For GKE:

1. Configure `gcloud` with `gcloud auth login`.
2. On the Google Cloud Console, the cluster page will have a `Connect` button, which will give a
   command to run locally that looks like

   `gcloud container clusters get-credentials $CLUSTER_NAME --zone $ZONE_NAME --project $PROJECT_NAME`.

3. Use `kubectl config get-contexts` to show the contexts available.
4. Run `kubectl config use-context $GKE_CONTEXT` to access the cluster from `kubectl`.

For EKS:

1. [Configure your AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)
   to connect to your project.
2. Install [eksctl](https://eksctl.io/introduction/)
3. Run `eksctl utils write-kubeconfig --cluster=<CLUSTER NAME>` to make the context available to
   `kubectl`
4. Use `kubectl config get-contexts` to show the contexts available.
5. Run `kubectl config use-context <eks context>` to access the cluster with `kubectl`.

### Install helm

To install helm simply run:

For MacOS:

`brew install helm`

For Linux:

1. Download installer script
   `curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3`
2. Assign required premissions `chmod 700 get_helm.sh`
3. Run script `./get_helm.sh`

### Add Helm Repository

From now charts are stored in helm-repo thus there're no need to clone the repo each time you need
to deploy the chart.

To add remote helm repo simply run: `helm repo add airbyte https://airbytehq.github.io/helm-charts`.

Where `airbyte` is the name of the repository that will be indexed locally.

After adding the repo, perform the repo indexing process by running `helm repo update`.

After this you can browse all charts uploaded to repository by running `helm search repo airbyte`

It'll produce output similar to below:

```text
NAME                            	CHART VERSION	APP VERSION	DESCRIPTION
airbyte/airbyte                 	0.49.9       	0.50.33    	Helm chart to deploy airbyte
airbyte/airbyte-api-server      	0.49.9       	0.50.33    	Helm chart to deploy airbyte-api-server
airbyte/airbyte-bootloader      	0.49.9       	0.50.33    	Helm chart to deploy airbyte-bootloader
airbyte/connector-builder-server	0.49.9       	0.50.33    	Helm chart to deploy airbyte-connector-builder-...
airbyte/cron                    	0.49.9       	0.50.33    	Helm chart to deploy airbyte-cron
airbyte/metrics                 	0.49.9       	0.50.33    	Helm chart to deploy airbyte-metrics
airbyte/pod-sweeper             	0.49.9       	0.50.33    	Helm chart to deploy airbyte-pod-sweeper
airbyte/server                  	0.49.9       	0.50.33    	Helm chart to deploy airbyte-server
airbyte/temporal                	0.49.9       	0.50.33    	Helm chart to deploy airbyte-temporal
airbyte/webapp                  	0.49.9       	0.50.33    	Helm chart to deploy airbyte-webapp
airbyte/worker                  	0.49.9       	0.50.33    	Helm chart to deploy airbyte-worker
```

## Deploy Airbyte

### Default deployment

If you don't intend to customise your deployment, you can deploy airbyte as is with default values.

In order to do so, run the command:

```
helm install %release_name% airbyte/airbyte
```

**Note**: `release_name` should only contain lowercase letters and optionally dashes (`release_name`
must start with a letter).

### Custom deployment

In order to customize your deployment, you need to create `values.yaml` file in the local folder and
populate it with default configuration override values.

`values.yaml` example can be located in
[charts/airbyte](https://github.com/airbytehq/airbyte-platform/blob/main/charts/airbyte/values.yaml)
folder of the Airbyte repository.

After specifying your own configuration, run the following command:

```text
helm install --values path/to/values.yaml %release_name% airbyte/airbyte
```

### External Logs with S3

:::info

S3 logging was tested on
[Airbyte Helm Chart Version 0.50.13](https://artifacthub.io/packages/helm/airbyte/airbyte/0.50.13)

:::

Create a file called `airbyte-logs-secrets.yaml` to store the AWS Keys and other informations:

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: airbyte-logs-secrets
type: Opaque
stringData:
  AWS_KEY: <AWS_KEY>
  AWS_SECRET_KEY: <AWS_SECRET_KEY>
  S3_LOG_BUCKET: <BUCKET_NAME>
  S3_LOG_BUCKET_REGION: <REGION>
```

Run `kubectl apply -f airbyte-logs-secrets.yaml -n <NAMESPACE>` to create the secret in the
namespace you're using Airbyte. This file contains more than just the keys but it needs for now.
Future updates will make the configuration easier.

Change the global section to use `S3` external logs.

```yaml
global:
  # <...>
  state:
    # -- Determines which state storage will be utilized; "MINIO", "S3", or "GCS"
    storage:
      type: "S3"
  # <...>
  logs:
    accessKey:
      password: ""
      existingSecret: "airbyte-logs-secrets"
      existingSecretKey: "AWS_KEY"
    secretKey:
      password: ""
      existingSecret: "airbyte-logs-secrets"
      existingSecretKey: "AWS_SECRET_KEY"
  # <...>
  storage:
    type: "S3"

  minio:
    # Change from true to false
    enabled: false
    nodeSelector: {}
    tolerations: []
    affinity: {}
```

GCS Logging information is below but you can try to use `External Minio` as well but it was not
tested yet. Feel free to run tests and update the documentation.

Add extra env variables to the following blocks:

```yaml
worker:
  extraEnv:
    - name: AWS_ACCESS_KEY_ID
      valueFrom:
        secretKeyRef:
          name: airbyte-logs-secrets
          key: AWS_KEY
    - name: AWS_SECRET_ACCESS_KEY
      valueFrom:
        secretKeyRef:
          name: airbyte-logs-secrets
          key: AWS_SECRET_KEY
    - name: STATE_STORAGE_S3_ACCESS_KEY
      valueFrom:
        secretKeyRef:
          name: airbyte-logs-secrets
          key: AWS_KEY
    - name: STATE_STORAGE_S3_SECRET_ACCESS_KEY
      valueFrom:
        secretKeyRef:
          name: airbyte-logs-secrets
          key: AWS_SECRET_KEY
    - name: STATE_STORAGE_S3_BUCKET_NAME
      valueFrom:
        secretKeyRef:
          name: airbyte-logs-secrets
          key: S3_LOG_BUCKET
    - name: STATE_STORAGE_S3_REGION
      valueFrom:
        secretKeyRef:
          name: airbyte-logs-secrets
          key: S3_LOG_BUCKET_REGION
```

and also edit the server block:

```yaml
server:
  extraEnv:
    - name: AWS_ACCESS_KEY_ID
      valueFrom:
        secretKeyRef:
          name: airbyte-logs-secrets
          key: AWS_KEY
    - name: AWS_SECRET_ACCESS_KEY
      valueFrom:
        secretKeyRef:
          name: airbyte-logs-secrets
          key: AWS_SECRET_KEY
    - name: STATE_STORAGE_S3_ACCESS_KEY
      valueFrom:
        secretKeyRef:
          name: airbyte-logs-secrets
          key: AWS_KEY
    - name: STATE_STORAGE_S3_SECRET_ACCESS_KEY
      valueFrom:
        secretKeyRef:
          name: airbyte-logs-secrets
          key: AWS_SECRET_KEY
    - name: STATE_STORAGE_S3_BUCKET_NAME
      valueFrom:
        secretKeyRef:
          name: airbyte-logs-secrets
          key: S3_LOG_BUCKET
    - name: STATE_STORAGE_S3_REGION
      valueFrom:
        secretKeyRef:
          name: airbyte-logs-secrets
          key: S3_LOG_BUCKET_REGION
```

Than run:
`helm upgrade --install %RELEASE_NAME% airbyte/airbyte -n <NAMESPACE> --values /path/to/values.yaml --version 0.50.13`

### External Logs with GCS

:::Info
GCS Logging is similar to the approach taken for S3 above, with a few small differences
GCS logging was tested on [Airbyte Helm Chart Version 0.54.69](https://artifacthub.io/packages/helm/airbyte/airbyte/0.54.69)
:::

#### Create Google Cloud Storage Bucket

1. **Access Google Cloud Console**: Go to the Google Cloud Console and select or create a project
   where you want to create the bucket.
2. **Open Cloud Storage**: Navigate to "Storage" > "Browser" in the left-side menu.
3. **Create Bucket**: Click on "Create bucket". Give your bucket a unique name, select a region for the bucket, and configure other settings such as storage class and access control according to your requirements. Finally, click "Create". The buckect will be referenced as `<bucket_name>`

#### Create Google Cloud Service Account

1. **Open IAM & Admin**: In the Cloud Console, navigate to "IAM & Admin" > "Service Accounts".
2. **Create Service Account**: Click "Create Service Account", enter a name, description, and then click "Create".
3. **Grant Permissions**: Assign the role of "Storage Object Admin" to the service account by selecting it from the role list.
4. **Create Key**: After creating the service account, click on it, go to the "Keys" tab, and then click "Add Key" > "Create new key". Choose JSON as the key type and click "Create". The key file will be downloaded automatically to your computer.
5. **Encode Key**: Encode GCP credentials file contents using Base64. This key will be referenced as `<encoded_key>` 

#### Update the values.yaml with the GCS Logging Information below

Update the following Environment Variables in the global section:

```
global:
 state:
   storage:
     type: "GCS"

 logs:
   storage:
     type: "GCS"
   gcs:
     bucket: "<bucket_name>"
     credentials: "/secrets/gcs-log-creds/gcp.json"      
     credentialsJson: "<encoded_key>"
```


Update the following Environment Variables in the worker section:
```
worker:
 
 extraEnv:
   - name: STATE_STORAGE_GCS_BUCKET_NAME
     value: <bucket_name>
   - name: STATE_STORAGE_GCS_APPLICATION_CREDENTIALS
     value: /secrets/gcs-log-creds/gcp.json
   - name: CONTAINER_ORCHESTRATOR_SECRET_NAME
     value: <%RELEASE_NAME%>-gcs-log-creds
   - name: CONTAINER_ORCHESTRATOR_SECRET_MOUNT_PATH
     value: /secrets/gcs-log-creds
```

Then run:
`helm upgrade --install %RELEASE_NAME% airbyte/airbyte -n <NAMESPACE> --values /path/to/values.yaml --version 0.54.69`

### External Airbyte Database

:::info

This was tested using
[Airbyte Helm Chart Version 0.50.13](https://artifacthub.io/packages/helm/airbyte/airbyte/0.50.13).
Previous or newer version can change how the external database can be configured.

:::

The Airbyte Database only works with Postgres 13. Make sure the database is accessible inside the
cluster using `busy-box` service using `telnet` or `ping` command.

:::warning

If you're using the external database for the first time you must ensure the database you're going
to use exists. The default database Airbyte will try to use is `airbyte` but you can modified it in
the `values.yaml`.

:::

:::warning

You can use only one database to a one Airbyte Helm deployment. If you try to use the same database
for a different deployment it will have conflict with Temporal internal databases.

:::

Create a Kubernetes secret to store the database password. Save the file as `db-secrets.yaml`.

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secrets
type: Opaque
stringData:
  DATABASE_PASSWORD: <PASSWORD>
```

Run `kubectl apply -f db-secrets.yaml -n <NAMESPACE>` to create the secret in the namespace you're
using Airbyte.

Afterward, modify the following blocks in the Helm Chart `values.yaml` file:

```yaml
postgresql:
  # Change the value from true to false.
  enabled: false
```

Then:

```yaml
externalDatabase:
  # Add the host, username and database name you're using.
  host: <HOST>
  user: <USERNAME>
  database: <DATABASE_NAME>
  password: ""
  existingSecret: "db-secrets"
  existingSecretPasswordKey: "DATABASE_PASSWORD"
  port: 5432
  jdbcUrl: ""
```

Keep password empty as the Chart will use the `db-secrets` value. Edit only the host, username, and
database name. If your database is using a differnet `port` or need an special `jdbcUrl` you can
edit here. This wasn't fully tested yet.

Next, reference the secret in the global section:

```yaml
global:
  database:
    secretName: "db-secrets"
    secretValue: "DATABASE_PASSWORD"
```

Unfortunately, the `airbyte-bootloader` configuration uses this variable. Future improvements are
planned.

Upgrade the chart by running:

```shell
helm upgrade --install %RELEASE_NAME% airbyte/airbyte -n <NAMESPACE> --values /path/to/values.yaml --version 0.50.13
```

## Migrate from old chart to Airbyte v0.52.0 and latest chart version

To assist with upgrading to Airbyte App version 0.52.0 and higher with the latest Helm Charts, we've
simplified and consolidated several configuration options. Here's a breakdown of the changes:

**Application.yaml Updates**:

- We've streamlined the configuration for logs and state storage.
- Instead of separate configurations for logs and state, we now have a unified storage
  configuration.
- The proposed changes involve specifying the storage type and bucket names directly, along with
  credentials where necessary.

**Helm Configuration Updates:**

- The global configuration now includes a simplified storage section specifying the type and bucket
  names for logs, state, and workload output.
- Credentials for MinIO are now set directly in the Helm values, ensuring smoother integration.
- Unused configurations have been removed, and configurations have been aligned with the simplified
  application.yaml.

**Technical Details and Renaming:**

- We've renamed or consolidated several environment variables for clarity and consistency.
- Unused methods and classes have been removed, ensuring a cleaner codebase.
- Some configurations have been split into separate files for better management and compatibility
  with different storage options.

**Additional Changes:**

- We've added support for workload output storage explicitly, improving flexibility and clarity in
  configuration.
- The Helm charts have been updated to reflect these changes, removing or replacing old environment
  variables for storage configuration.
- These changes aim to simplify configuration management and improve the overall user experience
  during upgrades. Please review these updates and let us know if you have any questions or need
  further assistance.

### **Migration Steps**

This guide aims to assist customers upgrading to the latest version of the Airbyte Helm charts,
specifically those using custom configurations for external logging and databases with AWS (S3) and
GCS (Google Cloud Buckets).

### **For AWS S3 Users**

#### **Prerequisites**

- Access to your Kubernetes cluster where Airbyte is deployed.
- Helm and kubectl installed and configured on your machine.
- Existing Airbyte deployment using AWS S3 for storage and AWS Secrets Manager for secret
  management.

#### **Migration Steps**

1. **Creating or Updating Kubernetes Secrets**

If using AWS access keys, create a Kubernetes secret to store these credentials. If relying on an
IAM role from an instance profile, this step can be skipped. Apply the following Kubernetes
manifest, replacing the example AWS credentials with your actual credentials:

```yaml
# Replace the example AWS credentials below with your actual credentials.
apiVersion: v1
kind: Secret
metadata:
  name: airbyte-config-secrets
type: Opaque
stringData:
  s3-access-key-id: AKIAIOSFODNN7EXAMPLE # Enter your AWS Access Key ID here
  s3-secret-access-key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY # Enter your AWS Secret Access Key here
```

2. **Update Airbyte Configuration**

   In your `airbyte.yml` configuration file, add the following configuration, adjusting
   `<aws-region>` to match your AWS region:

   ```yaml
   global:
     storage:
       type: s3
       storageSecretName: airbyte-config-secrets
       bucket:
         log: airbyte-storage
         state: airbyte-storage
         workloadOutput: airbyte-storage
       s3:
         region: <aws-region>
         authenticationType: credentials # Use "credentials" or "instanceProfile"
         accessKeyIdSecretKey: aws-secret-manager-access-key-id # Omit if using instanceProfile
         secretAccessKeySecretKey: aws-secret-manager-secret-access-key # Omit if using instanceProfile

     secretsManager:
       type: awsSecretManager
       storageSecretName: airbyte-config-secrets
       awsSecretManager:
         region: <aws-region>
         authenticationType: credentials # Use "credentials" or "instanceProfile"
         accessKeyIdSecretKey: aws-secret-manager-access-key-id # Omit if using instanceProfile
         secretAccessKeySecretKey: aws-secret-manager-secret-access-key # Omit if using instanceProfile
         tags:
           - key: team
             value: deployment
           - key: business-unit
             value: engineering
   ```

3. **Remove Deprecated Configuration from `values.yaml`**

   Edit your `values.yaml` or `airbyte-pro-values.yaml` files to remove any deprecated storage and
   secrets manager environment variables related to S3 and AWS Secrets Manager. Ensure
   configurations like `state.storage.type: "S3"` and AWS access keys under `server.extraEnv` and
   `worker.extraEnv` are removed.

### **For GCS Users**

#### **Prerequisites**

- Access to your Kubernetes cluster where Airbyte is deployed.
- Helm and kubectl installed and configured on your machine.
- Existing Airbyte deployment using Google Cloud Storage (GCS) and Google Secret Manager (GSM) for
  secret management.

#### **Migration Steps**

1. **Setting Up or Updating Kubernetes Secrets**

   For Google Secret Manager, you may use existing credentials or create new ones. Apply a
   Kubernetes manifest like below, replacing `<CREDENTIALS_JSON_BLOB>` with your GCP credentials
   JSON blob:

   ```yaml
   apiVersion: v1
   kind: Secret
   metadata:
     name: gcp-cred-secrets
   type: Opaque
   stringData:
     gcp.json: <CREDENTIALS_JSON_BLOB>
   ```

   Or use `kubectl` to create the secret directly from a file:

   ```sh
   kubectl create secret generic gcp-cred-secrets --from-file=gcp.json=<path-to-your-credentials-file>.json
   ```

2. **Update Airbyte Configuration**

   In your `airbyte.yml` configuration file, add the following configuration, adjusting
   `<project-id>` to match your GCP project ID:

   ```yaml
   global:
     storage:
       type: gcs
       storageSecretName: gcp-cred-secrets
       bucket:
         log: airbyte-storage
         state: airbyte-storage
         workloadOutput: airbyte-storage
       gcs:
         authenticationType: credentials
         projectId: <project-id>
         credentialsPath: /secrets/gcs-log-creds/gcp.json

     secretsManager:
       type: googleSecretManager
       storageSecretName: gcp-cred-secrets
       googleSecretManager:
         authenticationType: credentials
         projectId: <project-id>
         credentialsSecretKey: gcp-creds.json
   ```

3. **Remove Deprecated Configuration from `values.yaml`**

   Edit your `values.yaml` files to remove any deprecated storage and secrets manager environment
   variables related to GCS. Ensure configurations like `global.state.storage.type: "GCS"` and GCS
   credentials paths under `extraEnv` are removed.

This guide ensures that you leverage the latest Helm chart configurations for Airbyte, aligning with
best practices for managing storage and secrets in Kubernetes environments for AWS and GCS users.