assume my deployment is air gapped and can't pull from docker hub. What are all the images I need mirror into my environment to make sure custom connector builder can work

To ensure that the custom connector builder can work in an air-gapped environment where you can't pull from Docker Hub, you'll need to mirror several images into your private registry. Based on the information provided, here are the key steps and images you'll need: 1. Set up a private Docker registry as described in [Uploading Docker-based custom connectors](https://docs.airbyte.com/operator-guides/using-custom-connectors#1-create-a-private-docker-registry). 2. Mirror the following essential Airbyte images to your private registry: - airbyte/connector-builder-server - airbyte/webapp - airbyte/cron - airbyte/temporal - airbyte/db - temporalio/web These images are mentioned in the [Debugging Docker Containers](https://docs.airbyte.com/connector-development/debugging-docker#connecting-the-debugger-to-a-worker-spawned-container) documentation. 3. You'll also need to mirror any base images used for building custom connectors, such as: - airbyte/integration-base-java 4. For Kubernetes deployments, ensure that your cluster can authenticate and pull images from your private registry. You may need to create a Kubernetes Secret with your registry credentials and set the

JOB_KUBE_MAIN_CONTAINER_IMAGE_PULL_SECRET

environment variable on the

airbyte-worker

pod, as described in the [Kubernetes Airbyte deployments](https://docs.airbyte.com/operator-guides/using-custom-connectors#for-kubernetes-airbyte-deployments) section. 5. Build your custom connector images locally and push them to your private registry. 6. Configure Airbyte to use your custom connectors from the private registry by following the steps in [Use your custom Docker connector in Airbyte](https://docs.airbyte.com/operator-guides/using-custom-connectors#4-use-your-custom-docker-connector-in-airbyte). Remember to update your deployment configuration to use the mirrored images from your private registry instead of pulling from Docker Hub. For more detailed troubleshooting information, refer to the [Troubleshooting abctl](https://docs.airbyte.com/deploying-airbyte/troubleshoot-deploy#using-custom-connectors) documentation.

@kapa.ai what about

airbyte/source-declarative-manifest

and

airbyte/connector-sidecar

Based on the provided knowledge sources, I can offer some information about

airbyte/source-declarative-manifest

, but I don't have enough specific information about

airbyte/connector-sidecar

. Let me share what I know: 1. `airbyte/source-declarative-manifest`: This is an image used for manifest-only connectors in Airbyte. According to the [Airbyte connectors QA checks](https://docs.airbyte.com/contributing-to-airbyte/resources/qa-checks#manifest-only-connectors-must-use-source-declarative-manifest-as-their-base-image), manifest-only connectors must use

airbyte/source-declarative-manifest

as their base image. The

source-declarative-manifest

image is used in the context of building and running declarative sources. It's part of Airbyte's infrastructure for handling connectors defined using YAML manifests [How to add custom source to PyAirbyte using the no-code builder](https://airbyte.com/tutorials/how-to-add-custom-source-to-pyairbyte-using-the-no-code-builder). There have been issues related to version mismatches between the

airbyte-cdk

package and the manifest version used in

source-declarative-manifest

. For example, in a [reported issue](https://github.com/airbytehq/airbyte/issues/45398), there was a problem where the manifest version (4.6.2) was greater than the

airbyte-cdk

package version (4.3.0) in the

source-declarative-manifest

image. 2. `airbyte/connector-sidecar`: While this image is mentioned in one of the knowledge sources, there isn't enough specific information provided to explain its purpose or functionality in detail. It appears to be related to Airbyte's workload management, but I cannot make any definitive statements about its role or usage based on the given information. For the most up-to-date and accurate information about these images and their roles in Airbyte's architecture, I recommend checking the official Airbyte documentation or reaching out to Airbyte's support channels.