I keep hearing whispers and stories that it is possible to run Airbyte on AWS ECS. However I have been digging into it and from the source code I can see that Kubernetes is tightly coupled into the code. Am I missing something? Some kind of ENV VARs to disable the use of kubernetes? For example, the Bootloader requires you to query a kubernetes secret but this is not possible if you are using ECS.

Based on the available documentation, your observation appears to be correct. Airbyte is built to be deployed into a Kubernetes cluster, and the documentation does not mention AWS ECS (Elastic Container Service) as a supported deployment target. The official documentation explicitly states: > "Airbyte is built to be deployed into a Kubernetes cluster." [Deploying Airbyte] The supported deployment options mentioned in the docs are: • Amazon EKS (Elastic Kubernetes Service) on EC2 • Google Kubernetes Engine (GKE) • Azure Kubernetes Service (AKS) • Single-node setups (e.g., EC2 VM with Kubernetes installed, local Docker Desktop with Kubernetes enabled) [Infrastructure Prerequisites] Notably, the docs also explicitly state that EKS on Fargate is not supported, which further reinforces that AWS ECS (which shares a similar serverless container model) is not a supported path. Regarding the Bootloader issue you mentioned — a GitHub issue confirms that the Bootloader does interact with Kubernetes secrets (specifically

airbyte-auth-secrets

), which is consistent with your finding that Kubernetes is tightly coupled into the codebase. [GitHub Issue] The knowledge sources do not contain any information about ENV VARs or configuration options to disable Kubernetes usage or run Airbyte on ECS. Based on the available evidence, AWS ECS does not appear to be a supported or documented deployment target for Airbyte, and the whispers you've heard are not backed by official documentation. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai I understand that ECS is not supported, but why is it said that it IS possible?

The knowledge sources I have access to do not contain any information suggesting that running Airbyte on AWS ECS is possible or supported. The documentation consistently points to Kubernetes-based deployments (EKS, GKE, AKS) as the supported options. I'm not able to explain why some people claim ECS is possible, as that claim is not backed by anything in the available documentation. It's possible those claims come from community experiments, outdated information, or misunderstandings — but I cannot confirm or deny that based on the sources available to me. If you're looking for an authoritative answer, I'd recommend checking the Airbyte GitHub Discussions or reaching out to Airbyte support directly, as they would be better positioned to clarify whether any unofficial ECS path exists. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai is the workload-launcher a critical component of airbyte 2.0.0 setup? i am getting the following error

Operation: [list] for kind: [Pod] with name: [null] in namespace: [default] failed.

because the workload launcher is expecting me to run on kubernetes. based on the airbyte 2.0.0 codebase, is it possible to kick off a job such as check_connection without the workload launcher?

Based on the available knowledge sources, yes — the workload launcher is a critical component of Airbyte's architecture, including version 2.0.0. Here's what the documentation says about the role of each relevant component: • Worker [

airbyte-worker

]: Reads from task queues and executes connection scheduling/sequencing logic, making calls to the Workload API. • Workload API [

airbyte-workload-api-server

]: The HTTP interface for enqueuing workloads — the discrete pods that run connector operations. • Launcher [

airbyte-workload-launcher

]: Consumes events from the Workload API and interfaces with Kubernetes to launch workloads. [Architecture Overview] All connector operations — including

CHECK

,

DISCOVER

,

SPEC

,

READ

, and

WRITE

— are run as workloads (Kubernetes pods). This means a

check_connection

operation would also go through the workload launcher. [Workloads & Jobs] The error you're seeing (

Operation: [list] for kind: [Pod] with name: [null] in namespace: [default] failed

) is consistent with this — the workload launcher is trying to interact with Kubernetes and failing because it's not running in a Kubernetes environment. The knowledge sources do not contain any information about a way to bypass or disable the workload launcher to run jobs like

check_connection

without it. The architecture is explicitly designed so that all connector operations go through the workload launcher → Kubernetes pod path. There is no documented alternative execution path. This is consistent with the earlier discussion: Airbyte 2.0 is tightly coupled to Kubernetes, and there are no documented ENV VARs or configuration options to run it outside of that environment. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@Makar Emeliyanov check out abctl: https://docs.airbyte.com/platform/deploying-airbyte/abctl

abctl is only for local dev work not productionising though. I am in the process of launching Airbyte in a production environment.