@kapa.ai hi, I have deployed airbyte-webapp with helm chart v2, but I'm getting this error:

2025-12-09 13:30:26.147 CET
2025/12/09 12:30:26 [notice] 1#1: signal 29 (SIGIO) received
2025-12-09 13:30:26.147 CET
2025/12/09 12:30:26 [notice] 1#1: signal 17 (SIGCHLD) received from 35
2025-12-09 13:30:26.147 CET
2025/12/09 12:30:26 [notice] 1#1: worker process 35 exited with code 0
2025-12-09 13:30:26.147 CET
2025/12/09 12:30:26 [notice] 1#1: signal 29 (SIGIO) received
2025-12-09 13:30:26.155 CET
2025/12/09 12:30:26 [notice] 1#1: signal 17 (SIGCHLD) received from 37
2025-12-09 13:30:26.155 CET
2025/12/09 12:30:26 [notice] 1#1: worker process 37 exited with code 0
2025-12-09 13:30:26.155 CET
2025/12/09 12:30:26 [notice] 1#1: exit

Airbyte 2.x no longer requires (or ships) a separate

airbyte-webapp

component: the web UI is bundled into the

airbyte-server

image and served on port

8001

by default. [[Multiple issues](https://github.com/airbytehq/airbyte/issues/68134); [Missing WEBAPP_URL](https://github.com/airbytehq/airbyte/issues/68659)] Because of that, the Helm v2 chart is generally expected to have

webapp

disabled. Users migrating to v2 who hit webapp-related issues have resolved them by turning it off, not by debugging the webapp pod itself. [[Missing WEBAPP_URL](https://github.com/airbytehq/airbyte/issues/68659); [Helm 1.8.0 webapp](https://github.com/airbytehq/airbyte/issues/65096)] Given the logs you shared, the pod is just exiting cleanly; the chart/architecture change is the more important point. Recommended next step In your

values.yaml

for the v2 chart, disable the webapp and use the server’s built‑in UI instead:

yaml webapp:   enabled: false

Then redeploy the chart and access the UI via the

airbyte-server

service (port 8001 by default). If you still see issues after disabling

webapp

, the knowledge sources don’t provide more specific guidance on that exact log pattern, so you may need to share your

values.yaml

and pod descriptions in GitHub or the forum for deeper debugging.