https://linen.dev logo
Join Slack
Powered by
restart airbyte local machine
# replication-ask-ai
r
restart airbyte local machine
k
To restart a local Airbyte installation managed with 
abctl
(without losing data), you can restart the underlying Kubernetes deployments:
Copy code
bash abctl local deployments --restart
This restarts the Airbyte components while keeping your data intact. [[abctl local](https://docs.airbyte.com/platform/2.0/deploying-airbyte/abctl#install-and-manage-local-airbyte-instances)] If instead you want to stop Airbyte and later start it again: - Stop (uninstall but keep data):
Copy code
bash abctl local uninstall
- Start again (reinstall using existing data):
Copy code
bash abctl local install
[[abctl manage](https://docs.airbyte.com/platform/2.0/deploying-airbyte/abctl#install-and-manage-local-airbyte-instances)] If you meant a full reset (wipe all data and start fresh), use:
Copy code
bash abctl local uninstall --persisted rm -rf ~/.airbyte/ abctl local install
This deletes all existing configuration and state. [[Reset dev env](https://docs.airbyte.com/platform/2.0/contributing-to-airbyte/developing-locally#resetting-the-airbyte-developer-environment)]
r
ERROR --restart: expected string value but got "EOL" (<EOL>)
@kapa.ai ERROR --restart: expected string value but got "EOL" (<EOL>)
k
A message from kapa.ai
That error suggests the 
--restart
flag is being used without the required string argument (the deployment name). According to the 
abctl
reference, 
--restart
expects a value, e.g. 
webapp
or 
server
, not just the flag alone. [[abctl reference](https://docs.airbyte.com/platform/deploying-airbyte/abctl#reference)] Use:
Copy code
bash abctl local deployments --restart webapp
or another specific deployment name instead of:
Copy code
bash abctl local deployments --restart
If you’re unsure which deployments exist, first run:
Copy code
bash abctl local deployments
r
@kapa.ai unable to restart airbyte deployment: unable to patch deployment webapp: Patch "https://127.0.0.1:36451/apis/apps/v1/namespaces/airbyte-abctl/deployments/webapp": EOF
k
A message from kapa.ai
The knowledge sources don’t mention this specific 
EOF
error when running:
Copy code
bash abctl local deployments --restart webapp # or similar
So I can’t give a confirmed root cause. However, there are two documented, supported ways to “restart” a local 
abctl
Airbyte that you can try instead of patching the deployment directly: ### 1. Use 
abctl
to restart deployments 
abctl
exposes a restart mechanism via the 
deployments
subcommand; you must pass the deployment name as a string:
Copy code
bash # List deployments first abctl local deployments  # Then restart a specific one, e.g. webapp or worker abctl local deployments --restart webapp
--restart
requires a value; calling it without a value will fail with a flag error. [[abctl reference](https://docs.airbyte.com/platform/deploying-airbyte/abctl#reference)] If 
webapp
keeps failing, try restarting the core services that are known to fix some UI/API issues:
Copy code
bash kubectl -n airbyte-abctl rollout restart deployment airbyte-abctl-worker kubectl -n airbyte-abctl rollout restart deployment airbyte-abctl-workload-api-server  kubectl -n airbyte-abctl rollout status deployment airbyte-abctl-worker kubectl -n airbyte-abctl rollout status deployment airbyte-abctl-workload-api-server
This sequence has resolved 502 / “Airbyte is temporarily unavailable” issues for other users. [[502 fix](https://github.com/airbytehq/airbyte/issues/66692)] ### 2. “Soft restart” by reinstalling with 
abctl
If restarts keep failing, you can effectively restart the whole local instance without losing data:
Copy code
bash # Stop Airbyte but keep data abctl local uninstall  # Start it again using the existing data abctl local install
[[abctl local](https://docs.airbyte.com/platform/deploying-airbyte/abctl#install-and-manage-local-airbyte-instances)] If none of these work and the 
EOF
persists, the knowledge sources don’t provide further guidance; in that case, capturing the full 
abctl
logs and opening a GitHub issue or discussion would be the next step.
r
@kapa.ai when I use 
abctl local deployments
I got error: Unable to list deployments
k
A message from kapa.ai
The documentation describes 
abctl local deployments
and 
abctl local deployments --restart ...
but does not mention an error like “Unable to list deployments,” so I can’t say exactly why this is happening from the docs alone. [[abctl reference](https://docs.airbyte.com/platform/deploying-airbyte/abctl#reference)] Given what is documented, here are the supported ways to check and manage your local deployment that don’t rely on 
abctl local deployments
working: 1. Verify the cluster and Helm chart are healthy Run:
Copy code
bash    abctl local status
This should confirm that the 
airbyte-abctl
cluster and Helm charts are present and deployed, and show how to access Airbyte (e.g. `http://localhost:8000`). [[Install/manage local](https://docs.airbyte.com/platform/deploying-airbyte/abctl#install-and-manage-local-airbyte-instances)] 2. Use 
kubectl
directly to inspect deployments Since 
abctl
installs Airbyte into a 
kind
cluster, you can use standard Kubernetes tooling:
Copy code
bash    kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig -n airbyte-abctl get deployments
Or list pods:
Copy code
bash    kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig -n airbyte-abctl get pods
This is the documented way to interact with the underlying cluster when using 
abctl
. [[abctl FAQ](https://docs.airbyte.com/platform/deploying-airbyte/troubleshoot-deploy#faq)] 3. “Restart” Airbyte by reinstalling (without losing data) If you mainly want to restart the instance and 
abctl local deployments
is failing, you can:
Copy code
bash    # Stop Airbyte but keep data    abctl local uninstall     # Start it again using existing data    abctl local install
This is the supported flow for stopping and starting a local instance while preserving data. [[Install/manage local](https://docs.airbyte.com/platform/deploying-airbyte/abctl#install-and-manage-local-airbyte-instances)] Because the docs don’t cover the exact “Unable to list deployments” error, if 
abctl local status
and 
kubectl
both work but 
abctl local deployments
still fails, the next step would be to share the full error output in an issue or discussion on the 
abctl
/ Airbyte GitHub for further debugging.
r
@kapa.ai ERROR Failed to initialize 'local' command ERROR unable to initialize local command: error communicating with kubernetes: unable to fetch kubernetes server version: Get "https://127.0.0.1:36451/version": EOF
k
A message from kapa.ai
The error you’re seeing matches a documented 
abctl
“connection refused/EOF” class of issues when it cannot talk to the local Kubernetes (kind) cluster. [[Connection refused](https://docs.airbyte.com/platform/deploying-airbyte/troubleshoot-deploy#connection-refused)] Because 
abctl
can’t fetch the Kubernetes server version at 
<https://127.0.0.1:36451/version>
, the local cluster is effectively broken or gone. The supported way to recover is to uninstall the local instance and reinstall it. To restart/fix your local Airbyte (keeping data): 1. Uninstall (stop Airbyte, keep data):
Copy code
bash    abctl local uninstall
2. Reinstall (start again using existing data):
Copy code
bash    abctl local install
[[Install/manage local](https://docs.airbyte.com/platform/deploying-airbyte/abctl#install-and-manage-local-airbyte-instances)] If the problem persists, you can do a full reset (this deletes all data):
Copy code
bash abctl local uninstall --persisted rm -rf ~/.airbyte/abctl abctl local install
[[Install/manage local](https://docs.airbyte.com/platform/deploying-airbyte/abctl#install-and-manage-local-airbyte-instances)] If even after a fresh 
abctl local install
you still get the same EOF error, the knowledge sources don’t provide further steps; in that case, capturing the full 
abctl
output and opening an issue on the Airbyte GitHub would be necessary.
r
@kapa.ai error when I tried abctl local install:
Copy code
ERROR   Timed out waiting for ingress
  ERROR   Unable to install Airbyte locally
  ERROR   browser liveness check failed: context deadline exceeded
k
A message from kapa.ai
This error matches a known class of 
abctl
install issues where ingress or the webapp doesn’t become reachable within the timeout. The knowledge sources don’t give a step‑by‑step fix for this exact message, but they do document closely related ingress/timeout problems and general 
abctl
troubleshooting. Here are the supported steps you can take: 1. Retry the install Some ingress/image issues are transient (e.g., Docker Hub or image publishing hiccups). In similar cases, maintainers have advised simply retrying:
Copy code
bash    abctl local install
[[abctl install issue](https://github.com/airbytehq/airbyte/issues/48720)] 2. Check for generic “timed out waiting for the condition” The docs list a generic Helm timeout error:
Copy code
text    unable to install airbyte chart: unable to install helm: failed pre-install:    1 error occurred: * timed out waiting for the condition
This indicates the install is stuck waiting on Kubernetes resources (often ingress or jobs) to become ready. [[Troubleshoot abctl](https://docs.airbyte.com/platform/deploying-airbyte/troubleshoot-deploy#time-out-waiting-for-the-condition)] In that situation, the documented recovery is to uninstall and reinstall:
Copy code
bash    abctl local uninstall    abctl local install
[[Install/manage local](https://docs.airbyte.com/platform/deploying-airbyte/abctl#install-and-manage-local-airbyte-instances)] 3. If it keeps failing, do a clean reset (will delete data) If repeated installs still fail at the ingress/browser liveness step, you can fully reset the local 
abctl
environment:
Copy code
bash    abctl local uninstall --persisted    rm -rf ~/.airbyte/abctl    abctl local install
This removes all 
abctl
state and forces a fresh cluster and install. [[Install/manage local](https://docs.airbyte.com/platform/deploying-airbyte/abctl#install-and-manage-local-airbyte-instances)] 4. Known ingress‑related issues There is an open issue where installs get stuck on 
nginx/ingress-nginx
with long timeouts. Users report that: - Being behind a corporate proxy can cause ingress install to hang. - In some cases, simply uninstalling and reinstalling Airbyte with 
abctl local uninstall
then 
abctl local install
eventually succeeded. [[Ingress stuck](https://github.com/airbytehq/airbyte/issues/56386)] The knowledge sources don’t provide a definitive fix beyond these workarounds. --- If, after a full reset and fresh 
abctl local install
, you still get 
Timed out waiting for ingress
/ 
browser liveness check failed
, the docs and issues provided don’t contain more specific remediation steps. In that case, capturing the full 
abctl
output with 
--verbose
and opening a GitHub issue (referencing this error) would be the next recommended action.
r
@kapa.ai getting this error to access airbyte: 503 Service Temporarily Unavailable
k
A message from kapa.ai
A 503 when accessing Airbyte after a local 
abctl
install is usually caused by the ingress pointing to the wrong service or the backend not being ready. From the knowledge sources, there is a known issue where 
abctl
creates an ingress that targets 
airbyte-abctl-airbyte-webapp-svc
, but that service does not exist; the correct target should be 
airbyte-abctl-airbyte-server-svc
. This misconfiguration leads to HTTP 503 errors until the ingress is fixed. [[Ingress target bug](https://github.com/airbytehq/airbyte/issues/65539)] To check and fix this: 1. Inspect the ingress
Copy code
bash    kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig -n airbyte-abctl describe ingress ingress-abctl
If you see a backend like 
airbyte-abctl-airbyte-webapp-svc
, that’s likely the problem. [[Ingress target bug](https://github.com/airbytehq/airbyte/issues/65539)] 2. Edit the ingress to point to the server service Change the backend service name from 
airbyte-abctl-airbyte-webapp-svc
to:
Copy code
text    airbyte-abctl-airbyte-server-svc
and keep the appropriate port (usually 80). After saving, try accessing Airbyte again. [[Ingress target bug](https://github.com/airbytehq/airbyte/issues/65539)] 3. If things are still broken, restart or reinstall You can “soft restart” the local instance (keeping data):
Copy code
bash    abctl local uninstall    abctl local install
[[abctl local](https://docs.airbyte.com/platform/deploying-airbyte/abctl#install-and-manage-local-airbyte-instances)] If after correcting the ingress target and reinstalling you still get 503s, the knowledge sources don’t provide more specific guidance; in that case, capturing 
kubectl describe ingress
and 
kubectl get pods -n airbyte-abctl
output and opening a GitHub issue would be the next step.
r
i'm not using a publick URL, I used to access airbyte via the IP where the airbyte is installed...is that impact?
@kapa.ai i'm not using a publick URL, I used to access airbyte via the IP where the airbyte is installed...is that impact?
k
A message from kapa.ai
Accessing Airbyte via the IP itself is fine in principle, but there are a couple of caveats with 
abctl
and ingress. 1. Older 
abctl
versions rejected IPs as hosts There was a known issue where ingress hosts had to be DNS names and could not be IPs (
must be a DNS name, not an IP address
). This was fixed in 
abctl >= 0.15.0
, which added default support for exposing IPs. [[Troubleshoot abctl](https://docs.airbyte.com/platform/deploying-airbyte/troubleshoot-deploy#not-able-to-ingress-direct-ip-addresses)] If you’re on a recent 
abctl
, using an IP as the host should not by itself break access. 2. Ingress still needs to be configured correctly Even when using an IP, the ingress must: - Point to the correct backend service (for recent versions, 
*-airbyte-server-svc
, not 
*-airbyte-webapp-svc
). A mis‑targeted ingress is a known cause of 503s. [[Ingress 1.8 example](https://docs.airbyte.com/platform/1.8/deploying-airbyte/integrations/ingress); [Ingress target bug](https://github.com/airbytehq/airbyte/issues/65539)] - Use a host that matches how you’re accessing it (IP or DNS name), depending on your ingress controller configuration. 3. abctl may already provide an ingress for you For 
abctl
deployments, a nginx ingress is automatically provided; you don’t need to create another one, but you may need to adjust its host or backend if you changed how you access Airbyte. [[Ingress 1.8](https://docs.airbyte.com/platform/1.8/deploying-airbyte/integrations/ingress); [Ingress 2.0](https://docs.airbyte.com/platform/2.0/deploying-airbyte/integrations/ingress)] Given the docs, using the IP instead of a public URL is supported on recent 
abctl
and should not by itself cause 503s; the more likely issue is the ingress backend (e.g., pointing to 
*-webapp-svc
instead of 
*-server-svc
) or a mis‑matched host in the ingress rule. [[Ingress target bug](https://github.com/airbytehq/airbyte/issues/65539); [Not able to ingress IP](https://docs.airbyte.com/platform/deploying-airbyte/troubleshoot-deploy#not-able-to-ingress-direct-ip-addresses)]
r
@kapa.ai how I update abctl version?
k
A message from kapa.ai
You can upgrade 
abctl
in several ways, depending on how you installed it. ### 1. If you installed with Homebrew (macOS/Linux)
Copy code
bash brew upgrade abctl abctl version
[[Deploying abctl](https://docs.airbyte.com/platform/deploying-airbyte/abctl#install-abctl); [Upgrade 2.0](https://docs.airbyte.com/platform/2.0/operator-guides/upgrading-airbyte)] ### 2. If you installed with 
curl
(macOS/Linux)
Copy code
bash curl -LsfS <https://get.airbyte.com> | bash - abctl version
[[Deploying abctl](https://docs.airbyte.com/platform/deploying-airbyte/abctl#install-abctl); [Upgrade abctl](https://docs.airbyte.com/platform/operator-guides/upgrading-airbyte#upgrading-airbyte-deployed-with-abctl)] ### 3. If you installed with 
go install
Copy code
bash go install <http://github.com/airbytehq/abctl@latest|github.com/airbytehq/abctl@latest> abctl version
[[Deploying abctl](https://docs.airbyte.com/platform/deploying-airbyte/abctl#install-abctl); [Upgrade abctl](https://docs.airbyte.com/platform/operator-guides/upgrading-airbyte#upgrading-airbyte-deployed-with-abctl)] ### 4. If you downloaded from GitHub (Linux/Windows) Download the latest release from GitHub and replace the existing binary: - Linux:
Copy code
bash   uname -m   # check arch: x86_64 -> linux-amd64, aarch64 -> linux-arm64   # download latest tar.gz from:   # <https://github.com/airbytehq/abctl/releases/latest>   tar -xvzf {name-of-file-downloaded.linux-*.tar.gz}   chmod +x abctl/abctl   sudo mv abctl /usr/local/bin   abctl version
- Windows: 1. Download the latest 
windows-amd64
or 
windows-arm64
zip from https://github.com/airbytehq/abctl/releases/latest 2. Extract it over your existing 
abctl
installation directory. 3. Open a new terminal and run:
Copy code
powershell      abctl version
[[Deploying abctl](https://docs.airbyte.com/platform/deploying-airbyte/abctl#install-abctl); [Upgrade abctl](https://docs.airbyte.com/platform/operator-guides/upgrading-airbyte#upgrading-airbyte-deployed-with-abctl)]
r
abctl local install : especific airbyte version
@kapa.ai abctl local install : especific airbyte version
k
A message from kapa.ai
You can pin the Airbyte version indirectly by choosing the Helm chart version that 
abctl
uses. From the GitHub issue, 
abctl
supports a 
--chart-version
flag on 
local install
, and specific chart versions map to specific Airbyte app versions. For example:
Copy code
bash abctl local install --chart-version 1.9.1
This installs Airbyte 2.0.1, because Helm chart 
1.9.1
corresponds to Airbyte app version 
2.0.1
. [[Helm mapping](https://github.com/airbytehq/airbyte/issues/68136)] The knowledge sources do not document a separate 
--airbyte-version
flag for `abctl local install`; only 
--chart-version
is mentioned. So to “specify an Airbyte version” with 
abctl
, you must: 1. Pick the desired Helm chart version. 2. Pass it via 
--chart-version
as above. If you need a different Airbyte version, choose the appropriate chart version that matches it and use that with 
--chart-version
. The exact mapping for all versions is not listed in the provided sources.
2 Views
Open in Slack
PreviousNext
Powered by