To have an

abctl

(Airbyte 2.0) instance authenticate against an external/private Docker registry, you configure the Kubernetes cluster Airbyte runs on to use your registry credentials. There are two main patterns in the docs: --- ## 1. Global custom image registry (Helm / values.yaml) If you want Airbyte to pull all platform and connector images from a specific registry: 1. Create a Kubernetes secret with your Docker config:

bash    kubectl create secret generic regcred \      --from-file=.dockerconfigjson=<path/to/.docker/config.json> \      --type=<http://kubernetes.io/dockerconfigjson|kubernetes.io/dockerconfigjson>

2. Reference that secret and registry in Airbyte’s `values.yaml`:

yaml    global:      image:        registry: <http://ghcr.io/NAMESPACE|ghcr.io/NAMESPACE>      imagePullSecrets:        - name: regcred

This tells the cluster (including the

abctl

-managed Airbyte) to use

<http://ghcr.io/NAMESPACE|ghcr.io/NAMESPACE>

and authenticate with

regcred

when pulling images. [[Custom registry step 1](https://docs.airbyte.com/platform/2.0/deploying-airbyte/integrations/custom-image-registries#step-1-customize-airbyte-to-use-your-image-registry); [Enterprise custom registry](https://docs.airbyte.com/platform/2.0/enterprise-setup/implementation-guide#configure-a-custom-image-registry)] > Note: Custom Docker connectors that specify a fully qualified domain name (e.g. `example.com/airbyte/my-connector`) will bypass this global registry setting and pull directly from the FQDN. [[Custom registry](https://docs.airbyte.com/platform/2.0/deploying-airbyte/integrations/custom-image-registries#custom-connectors-using-fully-qualified-domain-names)] --- ## 2. Authenticate worker pods to a private registry (Kubernetes env var) If you only need Airbyte workers to pull connector images from a private registry: 1. Create a Kubernetes

Secret

with your registry credentials (same as above, or as per Kubernetes docs). [[Docker requirements 2.0](https://docs.airbyte.com/platform/2.0/operator-guides/using-custom-connectors#3-adhere-to-airbytes-docker-image-requirements)] 2. Set the

JOB_KUBE_MAIN_CONTAINER_IMAGE_PULL_SECRET

environment variable on the

airbyte-worker

pod to the name of that Secret: > “Set the

JOB_KUBE_MAIN_CONTAINER_IMAGE_PULL_SECRET

environment variable on the

airbyte-worker

pod. The value must be the name of your previously created Kubernetes Secret.” [[Docker requirements 2.0](https://docs.airbyte.com/platform/2.0/operator-guides/using-custom-connectors#3-adhere-to-airbytes-docker-image-requirements)] This makes the worker use that secret when pulling connector images from your external registry. --- The docs do not show an

abctl

-specific flag or command to inject these settings automatically; you need to apply the Kubernetes secret and configuration (values.yaml or env var) to the cluster where your

abctl

instance is running.

The knowledge sources don’t explain 502 / upstream timeout causes in detail, but they do point to where to look and what to double‑check. Since you already loaded the image into kind:

bash kind load docker-image span/airbyte-source-bitbucket:dev -n airbyte-abctl

the next likely issues are: 1. Image name / tag mismatch in the UI Make sure the connector in Airbyte is actually using `span/airbyte-source-bitbucket:dev`: - Go to

<http://localhost:8000/>

- Workspace settings → Sources - Edit your custom connector (or add a new Docker connector) - Set: - Full image name:

span/airbyte-source-bitbucket

- Tag:

dev

- Save and retry. [[Use custom connector](https://docs.airbyte.com/platform/2.0/operator-guides/using-custom-connectors#4-use-your-custom-docker-connector-in-airbyte)] 2. Connector image not reachable from worker / kind For `abctl`/kind, loading the image is the right step; if you see errors like “image not found” in logs, it usually means the image wasn’t properly loaded. The docs say that if you see errors about the image, it’s likely not loaded correctly and you should re‑run:

bash    kind load docker-image span/airbyte-source-bitbucket:dev -n airbyte-abctl

[[Kind loading 2.0](https://docs.airbyte.com/platform/2.0/operator-guides/using-custom-connectors#loading-connector-docker-containers-into-kind)] 3. Check worker / job pod logs (not just server logs) The 502 is often coming from the UI/server proxying to the worker job. To see what’s actually failing: - Export kubeconfig for the

abctl

cluster:

bash      kind export kubeconfig -n airbyte-abctl

- List pods:

bash      kubectl get pods -n airbyte-abctl

- Look for: -

airbyte-abctl-worker-...

(main worker) - Any short‑lived job pods created when you click “Set up” / “Get spec” - Get logs, for example:

bash      kubectl logs -n airbyte-abctl airbyte-abctl-worker-XXXX      kubectl logs -n airbyte-abctl <job-pod-name>

The docs explicitly recommend using

kubectl

against the

airbyte-abctl

namespace to debug pods and logs. [[Developing locally 2.0](https://docs.airbyte.com/platform/2.0/contributing-to-airbyte/developing-locally#using-abctl-for-airbyte-development)] 4. Connector spec caching (if you changed the spec) If you’re iterating on the connector and changed its spec, Airbyte may still be using a cached spec. To refresh: - Go to Workspace settings → Sources - Edit the connector - Keep the tag (e.g.

dev

) and click Change to force a spec refresh. [[Connector spec cache](https://docs.airbyte.com/platform/2.0/contributing-to-airbyte/developing-locally#connector-specification-caching)] --- If after checking the image name/tag and looking at the worker/job pod logs you still only see a 502 with no useful error, the knowledge sources don’t provide more specific 502 troubleshooting steps. In that case, the next step would be to inspect those pod logs for Python/Java stack traces or connector‑level errors and share them (e.g. in the Airbyte forum) for further analysis.