Using AIO for my desktop application, and it seems like there's a chronic problem with AIO.

[turkcankeskin]

Hello,

I am trying to deploy the Hoppscotch Desktop application to my local Kubernetes environment using Helm in order to add an instance, but the environment fails to start. The backend cannot pass the readiness probe at /backend/ping, and the logs do not provide sufficient detail for troubleshooting.

deploymentMode: aio
aio:
  ingress:
    enabled: true
    hostname: hoppscotch.xxxx.test
    tls: true
    selfSigned: false
    ingressClassName: nginx
    annotations:
      nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
      cert-manager.io/cluster-issuer: xxx-ca-issuer

postgresql:
  enabled: false

externalDatabase:
  host: "xxxx"
  port: 5000
  user: "hoppscotch_test"
  database: "hoppscotch_test"
  password: "ChangeMe1!"

Logs:

npm notice
npm notice New minor version of npm available! 11.6.4 -> 11.7.0
npm notice Changelog: https://github.com/npm/cli/releases/tag/v11.7.0
npm notice To update run: npm install -g npm@11.7.0
npm notice
Webapp Server | 2026/01/15 15:00:59 Initializing Hoppscotch Web Static Server
Webapp Server | 2026/01/15 15:00:59 Using default port: 3200
Webapp Server | 2026/01/15 15:00:59 Running in production mode, using frontend path: /site/selfhost-web
Webapp Server | 2026/01/15 15:00:59 Generated and saved signing key to: /data/webapp-server/signing.key
Webapp Server | 2026/01/15 15:00:59 Verifying key: Iv5X2Tj9TaH8AYlFHtJ0i6hHB//V/7ANY/ct/1bXLgo=
App/Admin Dashboard Caddy | {"level":"info","ts":1768489259.6936328,"msg":"maxprocs: Updating GOMAXPROCS=1: using minimum allowed GOMAXPROCS"}
App/Admin Dashboard Caddy | {"level":"info","ts":1768489259.6939259,"msg":"GOMEMLIMIT is updated","package":"github.com/KimMachineGun/automemlimit/memlimit","GOMEMLIMIT":181193932,"previous":9223372036854775807}
App/Admin Dashboard Caddy | {"level":"info","ts":1768489259.6939955,"msg":"using config from file","file":"/etc/caddy/aio-subpath-access.Caddyfile"}
App/Admin Dashboard Caddy | {"level":"info","ts":1768489259.7916598,"msg":"adapted config to JSON","adapter":"caddyfile"}
App/Admin Dashboard Caddy | {"level":"warn","ts":1768489259.7916906,"msg":"Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/aio-subpath-access.Caddyfile","line":2}
App/Admin Dashboard Caddy | {"level":"warn","ts":1768489259.7920842,"logger":"admin","msg":"admin endpoint disabled"}
App/Admin Dashboard Caddy | {"level":"warn","ts":1768489259.7922025,"logger":"http.auto_https","msg":"server is listening only on the HTTP port, so no automatic HTTPS will be applied to this server","server_name":"srv0","http_port":80}
App/Admin Dashboard Caddy | {"level":"warn","ts":1768489259.7927725,"logger":"http","msg":"HTTP/2 skipped because it requires TLS","network":"tcp","addr":":80"}
App/Admin Dashboard Caddy | {"level":"warn","ts":1768489259.7927892,"logger":"http","msg":"HTTP/3 skipped because it requires TLS","network":"tcp","addr":":80"}
App/Admin Dashboard Caddy | {"level":"info","ts":1768489259.7927933,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
App/Admin Dashboard Caddy | {"level":"info","ts":1768489259.7928243,"msg":"serving initial configuration"}
App/Admin Dashboard Caddy | {"level":"info","ts":1768489259.7945433,"logger":"tls","msg":"cleaning storage unit","storage":"FileStorage:/root/.local/share/caddy"}
App/Admin Dashboard Caddy | {"level":"info","ts":1768489259.7955627,"logger":"tls","msg":"finished cleaning storage units"}
App/Admin Dashboard Caddy | {"level":"info","ts":1768489259.795601,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc000479400"}
App/Admin Dashboard Caddy | {"level":"error","ts":1768489264.0695384,"logger":"http.log.error","msg":"dial tcp [::1]:8080: connect: connection refused","request":{"remote_ip":"172.29.102.19","remote_port":"57268","client_ip":"172.29.102.19","proto":"HTTP/1.1","method":"GET","host":"10.42.2.134:80","uri":"/backend/ping","headers":{"User-Agent":["kube-probe/1.33"],"Accept":["/"],"Connection":["close"]}},"duration":0.000439538,"status":502,"err_id":"qwhukac6m","err_trace":"reverseproxy.statusError (reverseproxy.go:1390)"}

[jonathanfoster]

@turkcankeskin The readiness probe can fail prematurely on initial startup due to the Hoppscotch container requiring a restart when config changes occur.

Try disabling the readiness probe to see if this is the issue. If so, increase the AIO readiness probe initial delay to accommodate the restart.

I have this delay set to 15 sec for end-to-end test that run on a small local kind cluster. The timing will depend on your specific infrastructure. You may need to tune it a bit.

If that doesn’t work, let me know and we can troubleshoot further.

[turkcankeskin]

Hİ @jonathanfoster,

First of all, thank you for your feedback.

I saw that the backend started up when I set aio.readinessProbe.initialDelaySeconds: 30.

I have another problem. I'm connecting from the desktop app, but it always gets stuck at the "Login to Hoppscotch" step. Is it normal for it to try to go to "ipc://localhost/plugin"?

The console log only shows access_tokens; there are GET and POST requests in the AIO, but no error log.

[turkcankeskin]

Hello again @jonathanfoster ,

I realized immediately after writing the message that since I'm using selfsign local CA, I wanted to check the Interceptors again and that separate Interceptor settings are used for each instance.

Thanks again for your reply, the instance connection via the desktop app was successful.

[jonathanfoster]

Glad that took care of your issue. Readiness probe failures have come up before and I considered bumping the default initial delay, but that would just mask the underlying issue. Long-term we need to figure out how to load the new config without a container restart. This is a concern for the Hoppscotch app, not the charts though. I’ll add an issue to the Hopscotch repo to start the conversation.