[bug]: Deskop-App: cannot connecto to own instance - "Verification error: Key validation failed: HTTP request failed: error decoding response body"

[schroedermatthias]

Is there an existing issue for this?

• [x] I have searched the existing issues

Current behavior

Situation / Configuration:

• Desktop App Version: 25.2.0 (20250304.072649)
• Backend Version: 2025.2.0
• Backend Orchestrator: Kubernetes
• Single containers (frontend, backend, admin)

I’m unable to use the new feature to connect my own instance. The error message states:

“Verification error: Key validation failed: HTTP request failed: error decoding response body”

Due to a lack of documentation, I configured my Ingress so that the path /desktop-app-server/ implicitly points to the frontend container (see ingress.yaml below). However, the server responds with HTML and I guess my client expects JSON. It is very frustrating to guess / reverse engineer the internal routing configuration the AIO image does.

Relevant Configuration Settings:

WHITELISTED_ORIGINS=https://hoppscotch.redacted.de,app://hoppscotch_redacted_de
ENABLE_SUBPATH_BASED_ACCESS=true

My kubernetes ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hoppscotch
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - hoppscotch.redacted.de
      secretName: hoppscotch.redacted.de
  rules:
    - host: hoppscotch.redacted.de
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: hoppscotch-frontend
                port:
                  number: 80
          - path: /graphql
            pathType: Prefix
            backend:
              service:
                name: hoppscotch-backend
                port:
                  number: 80
          - path: /v1/
            pathType: Prefix
            backend:
              service:
                name: hoppscotch-backend
                port:
                  number: 80
          - path: /admin
            pathType: Prefix
            backend:
              service:
                name: hoppscotch-admin
                port:
                  number: 80

In general I think that a project like this should be though cloud-native from the beginning with proper documentation about a Kubernetes deployment. I think having 3 images seperating concerns is already a good approach, an AIO container image with all processes inside one container is not.

I think this project which I really like would hughely profit from a Helm chart to ease deployments in the cloud.

Best, Matthias

Steps to reproduce

Operate hoppscotch in Kubernetes ;-)

Environment

Production

Version

Self-Hosted

[liyasthomas]

Hi @schroedermatthias can you checked out our helm-charts repo?

[liyasthomas]

Here are few more pointers to help you:

• Have you enabled subpath based access?
• Have you updated the WHITELISTED_ORIGINS environment variables?

[schroedermatthias]

@liyasthomas thanks for pointing me to the Helm Chart. As I can see, it's pretty new, the last time I checked it did not exist :)

[schroedermatthias]

Here are few more pointers to help you:

* Have you enabled [subpath based access](https://docs.hoppscotch.io/documentation/self-host/community-edition/install-and-build#subpath-based-access)?

* Have you updated the [`WHITELISTED_ORIGINS`](https://docs.hoppscotch.io/documentation/clients/desktop#hoppscotch-self-hosted-edition-for-community) environment variables?

Yes, please see my initial post under "Relevant Configuration Settings:"

[CuriousCorrelation]

Hi @schroedermatthias, thanks for the report, to dive a bit deeper into the implementation details, essentially the prod.Dockerfile exposes port 3200 for webapp-server - this is the server that the new Desktop App uses to fetch the Hoppscotch (web)app contents (and not the frontend server itself, see also docker-compose.yml, and the same mentioned in AIO), which is then proxied by Caddy for subpath access (as oppose to multiport). Perhaps making sure the correct server is exposed might resolve your issue.

[schroedermatthias]

Thanks for elaborating, @CuriousCorrelation! Does this mean, that I'm no longer able to use the dedicated images, as the newly introduced webapp-server is not available separately? Or is this new server also part of the frontend-image and I just need to connect to :3200?

I explored there is port 3000 currently open in the frontend container. Is this the one I need?

Thanks and best regards Matthias

[CuriousCorrelation]

Hi @schroedermatthias, the webapp-server is not part of the frontend image - it's a completely separate component and is not available as a separate published image at this moment

[schroedermatthias]

Hi @CuriousCorrelation Thanks. This actually means, that the newly introduced feature to use a self-hosted backend breaks with the approach to use individual containers outlined here: https://docs.hoppscotch.io/documentation/self-host/community-edition/install-and-build#using-individual-containers-for-the-services-2.

Maybe this information should be added in the docs?

Are there plans to ship an image for the webapp-server? Now I have to use the "fat" image which is not cloud native :-(

Thanks, Matthias

[MC-intel]

It looks like the issue might be caused by the /desktop-app-server/ path pointing to the frontend instead of the backend. Try updating your Kubernetes Ingress configuration to explicitly route /desktop-app-server/ to hoppscotch-backend. Here’s an example:

- path: /desktop-app-server/
  pathType: Prefix
  backend:
    service:
      name: hoppscotch-backend
      port:
        number: 80

This should ensure that requests to the desktop app server reach the correct backend service instead of returning HTML when JSON is expected. Let us know if this helps!

[brunnobb]

/desktop-app-server/ should not be backend or frontend.

i have made it run with and additional container at my compose file

hoppscotch-app:
   image: hoppscotch/hoppscotch:latest
   container_name: hoppscotch-app
   restart: unless-stopped    
   environment:
     ...
     - ENABLE_SUBPATH_BASED_ACCESS=false
   ports:
     - "3200:3200" # Hoppscotch default port for web access for the app
   depends_on:      
     - hoppscotch-backend
     - hoppscotch-admin
     - hoppscotch-frontend

I do use separate containers for backend, frontend, admin, etc.. So this were created at my reverse proxy as hoppscotch-app.myinstance.com

THEN

you need to add the records to WHITELISTED_ORIGINS could be excessive, but i have had a few cors issues (check debugger on local instance.. (just F12)

WHITELISTED_ORIGINS=https://hoppscotch-backend.myinstance.com,https://hoppscotch.myinstance.com,https://hoppscotch-admin.myinstance.com,app://hoppscotch_myinstance_com,http://app.hoppscotch_app_myinstance_com,app://app.hoppscotch_myinstance_com

and on the local hoopscotch.. i needed to use hoppscotch-app.myinstance.com as URL

@liyasthomas is there a way to run only the app server using the default AIO container? it is running everything, but only app is mapped.

[CuriousCorrelation]

Hi @schroedermatthias thanks for bringing this up, I have an update, the webapp server is now part of the frontend container! See the latest Dockerfile for more context.

https://github.com/hoppscotch/hoppscotch/blob/81f2dce531839a1508756a3fa42bf32266b00db8/prod.Dockerfile#L118-L122

https://github.com/hoppscotch/hoppscotch/blob/81f2dce531839a1508756a3fa42bf32266b00db8/prod.Dockerfile#L127-L129

The webapp server is available in the frontend container on port 3200.

Let me know if it resolves your issue.

[CuriousCorrelation]

Hi everyone, closing this issue for better visibility of currently active issues. As mentioned previously, the webapp server is now available in the frontend container on port 3200. Please update your configuration to route accordingly. Feel free to reopen if you continue to experience problems after making these changes. Documentation are also updated to clarify this setup for users deploying with separate containers. Thanks for reporting this!

[ambouh1]

/desktop-app-server/ should not be backend or frontend.

i have made it run with and additional container at my compose file

hoppscotch-app:
   image: hoppscotch/hoppscotch:latest
   container_name: hoppscotch-app
   restart: unless-stopped    
   environment:
     ...
     - ENABLE_SUBPATH_BASED_ACCESS=false
   ports:
     - "3200:3200" # Hoppscotch default port for web access for the app
   depends_on:      
     - hoppscotch-backend
     - hoppscotch-admin
     - hoppscotch-frontend

I do use separate containers for backend, frontend, admin, etc.. So this were created at my reverse proxy as hoppscotch-app.myinstance.com

THEN

you need to add the records to WHITELISTED_ORIGINS could be excessive, but i have had a few cors issues (check debugger on local instance.. (just F12)

WHITELISTED_ORIGINS=https://hoppscotch-backend.myinstance.com,https://hoppscotch.myinstance.com,https://hoppscotch-admin.myinstance.com,app://hoppscotch_myinstance_com,http://app.hoppscotch_app_myinstance_com,app://app.hoppscotch_myinstance_com

and on the local hoopscotch.. i needed to use hoppscotch-app.myinstance.com as URL

@liyasthomas is there a way to run only the app server using the default AIO container? it is running everything, but only app is mapped.

Hello, yes there is, I did install the AIO image on EKS, using argocd: I did create configs with kustomize to patch the main service and add 3 more listning ports on the service to expose all the ports : 3000 frent-end, 3100 admin , and 3170 backen...and I did add 3200 to expose app-server Then using istio, I did configure an NLB on aws and create an ingreass-gateway for each specific port on the service: hopsctoch-frentd-mydomain.com hopsctoch-admin-mydomain.com hopsctoch-backend-mydomain.com hopsctoch-app-mydomain.com

how to patch the service which initially listen only on port 80:

apiVersion: v1 kind: Service metadata: name: hoppscotch namespace: tenants-en-dev1 #my name space...you can call it what ever spec: ports: - name: http-admin port: 81 protocol: TCP targetPort: 3100 - name: http-backend port: 82 protocol: TCP targetPort: 3170 - name: http-webapp port: 83 protocol: TCP targetPort: 3200

definition of ingress: will look like this for every host: for each host define a certificate, a gateway and a virtualhost which will point to a specific host ============== exemple ============ apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: eks-hoppscotch-backend-gateway spec: selector: istio: ingressgateway # use istio default controller servers:

• port: number: 80 name: http protocol: HTTP hosts:
  • "$(AWS_HOPPSCOTCH_BACKEND_URL)" # <--------| External Acessible DNS tls: httpsRedirect: true # sends 301 redirect for http requests
• port: number: 443 name: https protocol: HTTPS hosts:
  • "$(AWS_HOPPSCOTCH_BACKEND_URL)" tls: mode: SIMPLE credentialName: tenants-env-dev-hoppscotch-backend-gateway-eks-certificate-tls

---

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: eks-hoppscotch-backend-gateway-virtualservice labels: # <------------------------------|| From BackEnd Service SELECTOR section app.kubernetes.io/name: hoppscotch-backend spec: hosts:

• "$(AWS_HOPPSCOTCH_BACKEND_URL)" # <--------| External Acessible DNS gateways:
• eks-hoppscotch-backend-gateway # <-------------------| Reference to Gateway created in previous Section For That Application http:
• match:
  • uri: prefix: / route:
  • destination: port: number: 82 # <-----------------------------------|| Actual BackEnd Service Port host: hoppscotch.tenants-env-dev1.svc.cluster.local # corsPolicy: #to avoid som cross origin problems...can be ajusted depending on your environnemnt allowOrigins:
    • exact: "https://hopsctoch-frentd-mydomain.com"
    • exact: "https://hopsctoch-admin-mydomain.com"
    • exact: "https://hopsctoch-backend-mydomain.com"
    • exact: "http://hopsctoch-webapp-mydomain.com"
    • exact: "http://hopsctoch-frentd-mydomain.com"
    • exact: "http://hopsctoch-admin-mydomain.com"
    • exact: "http://hopsctoch-backend-mydomain.com"
    • exact: "http://hopsctoch-webapp-mydomain.com"
    • exact: "https://github.githubassets.com"
    • exact: "https://collector.github.com" allowMethods:
    • POST
    • GET
    • OPTIONS
    • PUT
    • PATCH
    • DELETE allowCredentials: true allowHeaders:
    • "content-type"
    • "Authorization" ==== apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: tenants-env-dev1-hoppscotch-backend-gateway-certificate-tls namespace: istio-system spec: duration: 2160h0m0s # egale 90 jours renewBefore: 24h0m0s # egale 1 jour 2024-01-12 nouveau certificat 1 jours avant l'expiration. secretName: tenants-env-dev1-hoppscotch-backend-gateway-eks-certificate-tls issuerRef: name: aws-cluster-vault-issuer kind: ClusterIssuer # Issuer | ClusterIssuer group: cert-manager.io commonName: $(AWS_HOPPSCOTCH_BACKEND_URL) dnsNames:
• $(AWS_HOPPSCOTCH_BACKEND_URL)

...and so on ..you define the same way for the other hosts and assign the corresponding ports for frentend 80, admin 81 , and web-app 83 (you can assign the port as you like...the important is routing each ingress entry on it s proper path)

But to have the desktop-app working , the host to enter is the one resolving to 3200 port. in the documentation it point to the front end host ....a little bit confusing and it give the key error. Thank you

Also in my case : ENABLE_SUBPATH_BASED_ACCESS is not used (no need with dedicated hosts)