https://linen.dev logo
Join Slack
Powered by
<@U04S8PLJWMT> We want to upgrade our self-hosted ...
# replication-ask-ai
i
@kapa.ai We want to upgrade our self-hosted Airbyte from version 2.0.1 to 2.1.0. what recommened approach to migrate the existing connection to the new upgraded instance of Airbyte. Is there a step-by-step guideance?
k
Upgrading Self-Hosted Airbyte from 2.0.1 to 2.1.0 Good news: since you're already on 2.0.1, upgrading to 2.1.0 is a relatively straightforward Helm upgrade — you don't need to migrate connections to a new instance. Your existing connections, sources, and destinations are stored in the database and will carry over automatically. > Note: Airbyte 2.1 is marked as experimental. If stability is your primary concern, you may want to wait for a more stable release. Also, Helm chart V1 is no longer supported in 2.1.0 — you must be on Helm chart V2. [Airbyte 2.1 Release] Step-by-Step Upgrade Guide 1. Back Up Your Database (Recommended) Before upgrading, back up Airbyte's Postgres database (especially if you're not using an external database).
Copy code
# Find your database pod
kubectl get pods --all-namespaces | grep db

# Run pg_dump inside the pod
kubectl exec -n airbyte -it airbyte-db-0 -- bash -c "pg_dump -U airbyte db-airbyte > /tmp/airbyte_backup.sql"

# Copy the backup locally
kubectl cp airbyte/airbyte-db-0:/tmp/airbyte_backup.sql ./airbyte_backup.sql
[Helm chart V2 upgrade] 2. Ensure You're on Helm Chart V2 Helm chart V1 is not supported in Airbyte 2.1.0. Since you're on 2.0.1, you should already be on Helm chart V2. If not, follow the Helm chart V2 migration guide first. [Airbyte 2.1 Release] 3. Update the Helm Repo
Copy code
helm repo update
This pulls the latest Helm chart versions. [Enterprise Implementation Guide] 4. Run the Helm Upgrade
Copy code
helm upgrade airbyte airbyte/airbyte \
  --namespace airbyte \
  --values ./values.yaml \
  --version 2.1.x   # Replace with the exact Helm chart version for 2.1.0
Check the Airbyte ArtifactHub or release notes for the exact Helm chart version corresponding to Airbyte 2.1.0. [Upgrading Airbyte] 5. Review Notable Changes in 2.1.0 Be aware of these changes that may require action: [Airbyte 2.1 Release] • Authentication enabled by default for new deployments. If you need unauthenticated access, explicitly disable it in 
values.yaml
. • Management endpoints moved to port 8085: If you have custom health checks or monitoring targeting the application port, update them to use port 8085. • 
AIRBYTE_ROLE
environment variable removed: Remove any references to this in custom configs or scripts. • Redis image updated to 
bitnamilegacy/redis
— no action needed if using default chart values. 6. Manage Connector Updates Post-Upgrade After upgrading, Airbyte will automatically upgrade connectors that are not in use. Connectors in use will not be automatically upgraded to avoid disruption. You can manually update connectors from the Workspace settings > Sources/Destinations page. [Managing Connector Updates] Your existing connections will be preserved through the upgrade as long as the database is intact. The upgrade process does not require recreating connections. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
i
@kapa.ai i am using abtcl and an external database wil i have a problem
k
Upgrading with abctl and an External Database Based on the knowledge sources, here's what you need to know: abctl Version Requirement The most important thing to check is your abctl version. Upgrading to Airbyte 2.0 required abctl 0.30.2 or later, and Helm chart V2 (required for 2.1.0) is used by default starting with abctl 0.30.0. [abctl 0.30.2 required] Verify and upgrade abctl if needed:
Copy code
# Check your current version
abctl version

# Upgrade abctl (e.g., via curl)
curl -LsfS https://get.airbyte.com | bash -
[Upgrading abctl] Using an External Database Using an external database is actually the safer scenario for upgrades. Since your data lives outside the cluster, you don't need to worry about losing connection data during the upgrade. Your 
values.yaml
should already have the external DB configured like this:
Copy code
postgresql:
  enabled: false

global:
  database:
    secretName: "airbyte-config-secrets"
    host: "your-db-hostname"
    port: "5432"
    name: "your_db_name"
    userSecretKey: "database-user"
    passwordSecretKey: "database-password"
Upgrade Command Once abctl is up to date, simply run:
Copy code
abctl local install --values values.yaml
This will upgrade your existing installation to the latest version. [Upgrading with abctl] In summary, as long as your abctl is on version 0.30.2 or later and your 
values.yaml
correctly points to your external database, you should not encounter problems upgrading from 2.0.1 to 2.1.0. It's still good practice to take a database backup before any upgrade. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
i
abctl version version: v0.30.3
@kapa.ai abctl version version: v0.30.3
k
Great news! You're running abctl v0.30.3, which meets the minimum requirement of v0.30.2 for Airbyte 2.0+ and already uses Helm chart V2 by default. [abctl 0.30.2 required] You should be good to proceed with the upgrade. Simply run:
Copy code
abctl local install --values values.yaml
Since you're using an external database, your connection data is safe and will persist through the upgrade. [Upgrading with abctl] Just make sure to review the notable changes in 2.1.0 mentioned earlier (auth enabled by default, port 8085 for management endpoints, 
AIRBYTE_ROLE
removed) to see if any apply to your setup. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
i
@kapa.ai getting this ERROR Timed out waiting for ingress ERROR Unable to install Airbyte locally ERROR browser liveness check failed: context deadline exceeded
k
Ingress Timeout Error During abctl Upgrade This is a known issue with abctl deployments. The error typically occurs because pods take longer to become ready than the default timeout allows, especially on cloud VMs or resource-constrained machines. [abctl reliability issues] Common Causes & Fixes 1. Simply Retry the Install Sometimes a retry is all that's needed, as the cluster may already be partially up:
Copy code
abctl local install --values values.yaml
Some users have reported success just by running the install command a second time. [install stuck issue] 2. Check if Pods Are Actually Running The timeout may be a false failure — the cluster could still be healthy. Check pod status:
Copy code
kubectl get pods -n airbyte-abctl
Look for pods in 
ImagePullBackOff
, 
CrashLoopBackOff
, or 
Pending
state, which would indicate a real problem. [abctl reliability issues] 3. Check for Resource Constraints abctl has no preflight resource checks, so the timeout can happen silently if your machine is under-resourced. Airbyte recommends at minimum: • 8GB RAM • 20GB disk Verify your available resources before retrying. [abctl reliability issues] 4. Check for Network/Image Pull Issues If you're behind a corporate proxy or experiencing Docker Hub rate limiting, image pulls can silently fail and cause timeouts. You can exec into the Kind container to investigate:
Copy code
docker exec -it airbyte-abctl-control-plane bash
curl https://ifconfig.io  # verify outbound connectivity
If rate-limited, retry with Docker credentials:
Copy code
abctl local install --values values.yaml \
  --docker-username YOUR_USERNAME \
  --docker-password YOUR_PASSWORD
[install stuck issue] 5. Try a Specific Chart Version If the latest chart version is causing issues, try pinning to a known-good version:
Copy code
abctl local install --values values.yaml --chart-version 1.9.1
[Helm chart broken issue] I'm sorry, but the knowledge sources don't mention a way to increase the ingress timeout directly via an abctl flag in the current version (v0.30.3) — this has been raised as a feature request but appears unresolved. [abctl reliability issues] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
i
@kapa.ai getting this root@airbyte-prod:/home/azureuser/airbyte# kubectl get pods -n airbyte-abctl E0512 111009.482550 92565 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: Get \"http://localhost:8080/api?timeout=32s\": dial tcp 127.0.0.18080 connect: connection refused" E0512 111009.483305 92565 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: Get \"http://localhost:8080/api?timeout=32s\": dial tcp 127.0.0.18080 connect: connection refused" E0512 111009.484833 92565 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: Get \"http://localhost:8080/api?timeout=32s\": dial tcp 127.0.0.18080 connect: connection refused" E0512 111009.485139 92565 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: Get \"http://localhost:8080/api?timeout=32s\": dial tcp 127.0.0.18080 connect: connection refused" E0512 111009.486615 92565 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: Get \"http://localhost:8080/api?timeout=32s\": dial tcp 127.0.0.18080 connect: connection refused" The connection to the server localhost:8080 was refused - did you specify the right host or port?
k
kubectl Connection Refused The error you're seeing is because 
kubectl
is not pointing to the correct kubeconfig for your abctl-managed cluster. By default, 
kubectl
tries to connect to 
localhost:8080
, but abctl uses its own kubeconfig file. [abctl FAQ] Fix: Use the abctl Kubeconfig You need to specify the abctl kubeconfig explicitly:
Copy code
kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig \
  --namespace airbyte-abctl \
  get pods
Optional: Set it Permanently for Your Session To avoid typing 
--kubeconfig
every time, export it as an environment variable:
Copy code
export KUBECONFIG=~/.airbyte/abctl/abctl.kubeconfig
Then you can run kubectl commands normally:
Copy code
kubectl get pods -n airbyte-abctl
Once you can see the pods, share the output here and we can diagnose the ingress timeout issue further. Look out for pods in 
ImagePullBackOff
, 
CrashLoopBackOff
, or 
Pending
state. [abctl FAQ] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
i
airbyte-abctl-bootloader 0/1 Completed 0 5m30s airbyte-abctl-cron-7d458f954b-b2cgn 1/1 Running 0 4m50s airbyte-abctl-manifest-server-66459ffc69-fbqrj 1/1 Running 0 4m50s airbyte-abctl-server-7476b6f9c5-pv658 1/1 Running 0 4m50s airbyte-abctl-temporal-64cf5fdccd-6tn8c 1/1 Running 0 4m50s airbyte-abctl-worker-699b79bbdb-59fhs 1/1 Running 0 4m50s airbyte-abctl-workload-api-server-57dcddcbcb-6qgh5 1/1 Running 0 4m50s airbyte-abctl-workload-launcher-b997d485f-gf68m 1/1 Running 1 (4m29s ago) 4m50s replication-job-9880-attempt-0 0/3 Completed 0 3m58s source-google-sheets-discover-9880-0-nggle 0/2 Completed 0 4m23s
@kapa.ai airbyte-abctl-bootloader 0/1 Completed 0 5m30s airbyte-abctl-cron-7d458f954b-b2cgn 1/1 Running 0 4m50s airbyte-abctl-manifest-server-66459ffc69-fbqrj 1/1 Running 0 4m50s airbyte-abctl-server-7476b6f9c5-pv658 1/1 Running 0 4m50s airbyte-abctl-temporal-64cf5fdccd-6tn8c 1/1 Running 0 4m50s airbyte-abctl-worker-699b79bbdb-59fhs 1/1 Running 0 4m50s airbyte-abctl-workload-api-server-57dcddcbcb-6qgh5 1/1 Running 0 4m50s airbyte-abctl-workload-launcher-b997d485f-gf68m 1/1 Running 1 (4m29s ago) 4m50s replication-job-9880-attempt-0 0/3 Completed 0 3m58s source-google-sheets-discover-9880-0-nggle 0/2 Completed 0 4m23s
k
Good News — Your Pods Look Healthy! All your core Airbyte pods are running correctly: The 
Completed
pods are just finished jobs (sync/discovery), which is also normal. The Ingress Timeout is Likely a False Failure Your cluster is healthy. The 
ERROR: Timed out waiting for ingress
is most likely the 1-minute ingress verification timeout in abctl being too short for your Azure VM. [abctl reliability issues] Try These Steps 1. Check if Airbyte is actually accessible:
Copy code
curl -I http://localhost:8000
2. Check the ingress status:
Copy code
kubectl get ingress -n airbyte-abctl \
  --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig
3. Check ingress controller pods:
Copy code
kubectl get pods -n ingress-nginx \
  --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig
If 
curl http://localhost:8000
returns a response, your upgrade was actually successful despite the timeout error. The ingress timeout is a known false-negative on cloud VMs like Azure. [abctl reliability issues] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
i
@kapa.ai its strange but i get failures duting isntallation ERROR Timed out waiting for ingress ERROR Unable to install Airbyte locally ERROR browser liveness check failed: context deadline exceeded root@airbyte-prod:/home/azureuser/airbyte# ^C root@airbyte-prod:/home/azureuser/airbyte# abctl local credentials INFO Using Kubernetes provider: Provider: kind Kubeconfig: /root/.airbyte/abctl/abctl.kubeconfig Context: kind-airbyte-abctl ERROR Unable to determine organization email ERROR unable to determine organization email: failed to get organization: unable to fetch token: unable to send token request: Post "http://localhost:80/api/v1/applications/token": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
k
Installation Failing Despite Healthy Pods The issue is clear now — even though your pods are running, the ingress is not responding on 
localhost:80/8000
. This is why both the installation timeout and 
abctl local credentials
are failing with 
context deadline exceeded
. 1. Check the Ingress Controller
Copy code
kubectl get pods -n ingress-nginx \
  --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig
If the ingress-nginx pods are missing or not running, that's your problem. 2. Check the Ingress Resource
Copy code
kubectl get ingress -n airbyte-abctl \
  --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig
3. Check if Port 80/8000 is Reachable
Copy code
curl -v http://localhost:8000
curl -v http://localhost:80
4. Check for Port Conflicts on Your Azure VM On Azure VMs, port 80 is often blocked by the OS firewall or already in use:
Copy code
# Check what's using port 80
sudo ss -tlnp | grep ':80'
sudo ss -tlnp | grep ':8000'
5. Try Reinstalling As reported by other users, a clean reinstall sometimes resolves ingress issues: [install stuck issue]
Copy code
abctl local uninstall
abctl local install --values values.yaml
I'm sorry, but the knowledge sources don't contain enough detail about this specific Azure VM ingress failure scenario to give a definitive fix. The root cause is most likely either: • The ingress-nginx pods failed to start (check step 1 above) • A port conflict or firewall rule on your Azure VM blocking port 80 [abctl reliability issues] Please share the output of steps 1 and 3 so we can narrow it down further. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
i
@kapa.ai runnung this command sudo abctl local install --values ./values.yaml --no-browser --insecure-cookies --port 80
k
Fixing Your abctl Install Command There are a couple of issues with your command: 1. Remove http:// from the --host flag The 
--host
flag expects a fully qualified domain name only, not a URL with a protocol prefix. [EC2 with abctl] 2. Port 80 + --insecure-cookies Since you're running over HTTP (port 80), 
--insecure-cookies
is correct to include. [abctl reference] Corrected Command
Copy code
sudo abctl local install \
  --values ./values.yaml \
  --no-browser \
  --insecure-cookies \
  --host airbyte.welcomd.com \
  --port 80
Additional Things to Verify 1. Make sure port 80 is open on your Azure VM's Network Security Group (NSG) — inbound traffic on port 80 must be allowed. 2. Make sure port 80 is not already in use on the VM:
Copy code
sudo ss -tlnp | grep ':80'
3. Ensure your DNS record for 
airbyte.welcomd.com
points to your Azure VM's public IP. > ⚠️ Running Airbyte over plain HTTP exposes your password in clear text. Airbyte strongly recommends securing your instance with TLS. [EC2 with abctl] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
i
@kapa.ai i have cloudflare in front and i allow 80 to cloudflares ips
k
Cloudflare Proxy in Front of abctl The knowledge sources do not contain enough information about configuring abctl specifically with Cloudflare as a reverse proxy to give a fully confident answer. However, based on what is documented, here's what's relevant: Potential Issue: abctl Ingress Verification When abctl installs, it performs a liveness check against the ingress after installation. If Cloudflare is proxying traffic, abctl's internal check to 
localhost:80
may still fail because: • The ingress verification checks 
localhost
directly, not your domain • Cloudflare sits between the public domain and your VM This could explain why you're seeing:
Copy code
ERROR   Timed out waiting for ingress
ERROR   browser liveness check failed: context deadline exceeded
What to Try 1. Verify local ingress is working directly on the VM:
Copy code
curl -v http://localhost:80
2. Check if the ingress-nginx pods are running:
Copy code
kubectl get pods -n ingress-nginx \
  --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig
3. Use 
--no-browser
to skip the browser check (which you're already doing ✅) > ⚠️ I'm sorry, but the knowledge sources don't explicitly cover Cloudflare proxy configurations with abctl. For this specific setup, I'd recommend reaching out on the Airbyte Community Slack where others may have configured the same Cloudflare + abctl combination. [abctl reliability issues] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
i
@kapa.ai root@airbyte-prod:/home/azureuser/airbyte# curl -v http://localhost:80 * Host localhost:80 was resolved. * IPv6: ::1 * IPv4: 127.0.0.1 * Trying [:1]80... * connect to ::1 port 80 from ::1 port 41978 failed: Connection refused * Trying 127.0.0.1:80...
k
Port 80 is Not Listening — Ingress is the Problem The 
curl
output confirms that nothing is listening on port 80 on your VM. This is why abctl's liveness check is failing. The ingress-nginx controller is either not running or not bound to port 80. Step 1: Check Ingress-Nginx Pods
Copy code
kubectl get pods -n ingress-nginx \
  --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig
Share the output — if pods are in 
CrashLoopBackOff
, 
Pending
, or 
ImagePullBackOff
, that's your root cause. [install stuck issue] Step 2: Check Ingress-Nginx Logs
Copy code
kubectl logs -n ingress-nginx \
  --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig \
  -l app.kubernetes.io/name=ingress-nginx
Step 3: Check the Ingress Resource
Copy code
kubectl describe ingress -n airbyte-abctl \
  --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig
Look for any errors like 
service not found
or misconfigured backends. [ingress misconfiguration issue] Step 4: Try a Clean Reinstall If the ingress-nginx pods are broken, a clean reinstall may fix it: [install stuck issue]
Copy code
abctl local uninstall
sudo abctl local install \
  --values ./values.yaml \
  --no-browser \
  --insecure-cookies \
  --host airbyte.welcomd.com \
  --port 80
Please share the output of Step 1 first — the pod status of 
ingress-nginx
will tell us exactly what's going wrong. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
i
@kapa.ai ingress-nginx-controller-6597574fdc-jnzfc 1/1 Running 0 13m
k
Ingress-Nginx is Running — Check Port Binding The ingress-nginx controller pod is healthy, but it's not bound to port 80 on the host. This is a common issue with 
kind
clusters (which abctl uses) on cloud VMs — the kind cluster runs inside Docker and port mapping may not be configured correctly. Step 1: Check What Ports Kind Has Mapped
Copy code
docker ps | grep airbyte-abctl-control-plane
Look for port mappings like 
0.0.0.0:80->80/tcp
. If port 80 is not listed, that's your problem. Step 2: Check the Ingress-Nginx Service
Copy code
kubectl get svc -n ingress-nginx \
  --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig
Look at the 
EXTERNAL-IP
and 
PORT(S)
columns. If the service shows 
<pending>
for 
EXTERNAL-IP
, the load balancer is not getting an IP assigned. Step 3: Check the Ingress Resource
Copy code
kubectl describe ingress -n airbyte-abctl \
  --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig
This will show if the ingress is pointing to the correct backend service. A known bug in abctl v0.30.1 caused ingress to incorrectly point to 
airbyte-abctl-airbyte-webapp-svc
instead of 
airbyte-abctl-airbyte-server-svc
. [ingress misconfiguration issue] Please share the output of Steps 1 and 2 — the Docker port mapping is most likely the root cause here. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
i
@kapa.ai 42772789c0db kindest/node:v1.32.2 "/usr/local/bin/entr…" 18 minutes ago Up 18 minutes 0.0.0.0:80->80/tcp, 127.0.0.1:34409->6443/tcp airbyte-abctl-control-plane ingress-nginx-controller NodePort 10.96.20.184 <none> 8030253/TCP,44331606/TCP 14m ingress-nginx-controller-admission ClusterIP 10.96.32.47 <none> 443/TCP 14m ingress-nginx-controller-admission ClusterIP 10.96.32.47 <none> 443/TCP 14m root@airbyte-prod:/home/azureuser/airbyte# kubectl describe ingress -n airbyte-abctl \ --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig Name: ingress-abctl Labels: <none> Namespace: airbyte-abctl Address: 10.96.20.184 Ingress Class: nginx Default backend: <default> Rules: Host Path Backends ---- ---- -------- airbyte.welcomd.com /api/v1/connector_builder airbyte-abctl-airbyte-connector-builder-server-svc:http (<error: services "airbyte-abctl-airbyte-connector-builder-server-svc" not found>) / airbyte-abctl-airbyte-server-svc:http (10.244.0.11:8001) localhost /api/v1/connector_builder airbyte-abctl-airbyte-connector-builder-server-svc:http (<error: services "airbyte-abctl-airbyte-connector-builder-server-svc" not found>) / airbyte-abctl-airbyte-server-svc:http (10.244.0.11:8001) host.docker.internal /api/v1/connector_builder airbyte-abctl-airbyte-connector-builder-server-svc:http (<error: services "airbyte-abctl-airbyte-connector-builder-server-svc" not found>) / airbyte-abctl-airbyte-server-svc:http (10.244.0.11:8001) Annotations: <none> Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Sync 13m (x2 over 13m) nginx-ingress-controller Scheduled for sync
k
Two Issues Found Issue 1: Missing Connector Builder Service (Non-Critical) The ingress is referencing 
airbyte-abctl-airbyte-connector-builder-server-svc
which doesn't exist. This is a known issue caused by running abctl in 
--low-resource-mode
. If you're not using low-resource mode, this may resolve itself. [connector builder service missing] Issue 2: Ingress-Nginx Running as NodePort (Root Cause ✅) This is your main problem. The ingress-nginx service is running as 
NodePort
instead of being bound directly to the host port:
Copy code
ingress-nginx-controller   NodePort   10.96.20.184   <none>   80:30253/TCP
Even though Docker maps 
0.0.0.0:80->80/tcp
, the ingress controller is listening on 
NodePort 30253
inside the cluster, not on port 80. So traffic hitting port 80 on the host never reaches nginx. Fix: Check if You're Using --low-resource-mode First, verify your install command doesn't include `--low-resource-mode`:
Copy code
sudo abctl local install \
  --values ./values.yaml \
  --no-browser \
  --insecure-cookies \
  --host airbyte.welcomd.com \
  --port 80
Try a Clean Reinstall A clean reinstall should correctly configure the ingress-nginx service: [install stuck issue]
Copy code
# Uninstall first
abctl local uninstall

# Reinstall
sudo abctl local install \
  --values ./values.yaml \
  --no-browser \
  --insecure-cookies \
  --host airbyte.welcomd.com \
  --port 80
Verify After Reinstall After reinstalling, confirm nginx is correctly bound:
Copy code
# Should show LoadBalancer or correct port binding, not NodePort
kubectl get svc -n ingress-nginx \
  --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig

# Confirm port 80 is responding
curl -v http://localhost:80
> ⚠️ I'm sorry, but the knowledge sources don't explicitly explain why abctl is deploying ingress-nginx as 
NodePort
on your Azure VM. If the clean reinstall doesn't fix it, I'd recommend raising this on the Airbyte Community Slack as it may be an Azure-specific abctl issue. [abctl reliability issues] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
7 Views
Open in Slack
PreviousNext
Powered by