Airbyte
Airbyte is available as a Xooshe ready-made app for data integration and connector-based pipelines.
Dependencies
The current official Airbyte Helm chart is deployed with:
- An existing PostgreSQL service for Airbyte metadata.
- An existing S3-compatible object storage bucket for logs, state, activity payloads, and workload output.
- No Redis dependency. The official chart uses Temporal for workflow orchestration and does not consume a Redis service.
Create the PostgreSQL database and S3 bucket first. Keep credentials in Custom configuration; do not commit them to source control.
Deployment
From Cluster → Environment → Ready-made app, choose Airbyte and complete environment, public access, and resources. PostgreSQL and S3 settings are not collected at create time.
After the app is created, open it and edit Custom configuration (the same editor used for values such as the Redis password). Replace the placeholders for database host, user, password, S3 region, bucket, and access keys, then save so the app deploys. For MinIO or another S3-compatible provider, also set storage.endpoint.
Helm does not start until those credentials are real. Installing against the CHANGE_ME / example-host placeholders makes the bootloader wait for a database that does not exist until Helm times out, which leaves the release stuck so a later save cannot update the workloads. If a previous attempt timed out, saving real credentials recovers that stuck release and then applies the new values.
A later upgrade can also fail with post-upgrade hooks failed: timed out waiting for the condition. That is the chart's bundled airbyte-minio-create-bucket hook, which starts when storage type is MinIO even if you already have an external bucket. Xooshe disables that hook and removes leftover hook objects, then upgrades again. Save the app once more after a stuck pending install so recovery can run.
After you save real credentials, verify that the Airbyte URL responds and that the application reaches a healthy state. The first deploy runs a bootloader hook that can take several minutes before server, worker, and Temporal appear. The server JVM then needs a few more minutes to listen on port 8001; until it does, workload-launcher may restart. Give the server at least 1 CPU and 1.5 GiB so the liveness probe does not kill it mid-boot. The PostgreSQL and object-storage services remain separate from the Airbyte release and must be backed up and managed independently.
The install seeds the connector catalog that ships with the Airbyte image. It does not call connectors.airbyte.com at boot (that fetch often returns 403 from restricted networks). After the app is up, you can still add custom connectors from the Airbyte UI.
The UI is served by airbyte/server on port 8001. Airbyte stopped publishing airbyte/webapp in 1.8, so that component is not deployed.
Platform pods (server, worker, Temporal, bootloader, and job sidecars) and connector images used for syncs are pulled from hub.hamdocker.ir using the same image path as Docker Hub (hub.hamdocker.ir/airbyte/server, hub.hamdocker.ir/temporalio/auto-setup, hub.hamdocker.ir/airbyte/source-postgres, and so on). Those tags must exist on that registry. If the registry is private, add a Docker registry secret in the app namespace labeled with registry-url for hub.hamdocker.ir.
Outbound proxy
If connectors or the platform need the public internet through a VLESS/VMess server, open the Airbyte app → general → Outbound proxy. That adds an Xray sidecar to the server, worker, cron, and workload-launcher instances (and to connector job pods when the Airbyte chart honors global.jobs.kube.extraContainers). See Outbound proxy.
Temporal and the bootloader hook do not get the sidecar. In-cluster PostgreSQL and object storage stay on NO_PROXY.