starred/hoppscotch

Fork 0

mirror of https://github.com/hoppscotch/hoppscotch.git synced 2026-04-25 08:45:58 +03:00

[GH-ISSUE #5924] [bug]: AIO self hosted cannot connect to backend, gateway error and using localhost incorrectly #2327

New issue

Open

opened 2026-03-16 23:58:20 +03:00 by kerem · 7 comments

kerem commented

2026-03-16 23:58:20 +03:00

Owner

Originally created by @rogersmj on GitHub (Mar 2, 2026).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5924

Is there an existing issue for this?

I have searched existing issues and this bug hasn't been reported yet

Platform

Web App

Browser

Chrome

Operating System

Other (specify in additional info)

Bug Description

I have deployed Hoppscotch AIO from a Docker image to Google Cloud Run (Google containerized app service). The front end loads, but the backend cannot connect. When attempting to visit /admin, it appears it is trying to access the correct route, but I get a "gateway error":

When I load the front end, it's trying to access "localhost:3170" even though that's nowhere in my .env:

My .env looks like this (real domain and other sensitive info redacted):

DATABASE_URL=**redacted**
HOPP_AIO_ALTERNATE_PORT=5000 # Initially had this at 80, tried setting up an alternate ingress. Made no difference
DATA_ENCRYPTION_KEY=**redacted**

WHITELISTED_ORIGINS=https://hoppscotch.mydomain.com,https://hoppscotch.mydomain.com/admin,https://hoppscotch.mydomain.com/backend/v1,https://hoppscotch.mydomain.com/backend/graphql
VITE_BASE_URL=https://hoppscotch.mydomain.com
VITE_SHORTCODE_BASE_URL=https://hoppscotch.mydomain.com
VITE_ADMIN_URL=https://hoppscotch.mydomain.com/admin
VITE_BACKEND_GQL_URL=https://hoppscotch.mydomain.com/backend/graphql
VITE_BACKEND_WS_URL=wss://hoppscotch.mydomain.com/backend/graphql
VITE_BACKEND_API_URL=https://hoppscotch.mydomain.com/backend/v1
VITE_APP_TOS_LINK=https://docs.hoppscotch.io/support/terms
VITE_APP_PRIVACY_POLICY_LINK=https://docs.hoppscotch.io/support/privacy
ENABLE_SUBPATH_BASED_ACCESS=true
VITE_ALLOWED_AUTH_PROVIDERS=GOOGLE,GITHUB,EMAIL

One part of my issue looks the same as #4926, but the fix there (adding /backend in the internal service URLs) did not work for me.

Note: I've already run the migrations successfully on the Postgres database I setup for Hoppscotch.

Deployment Type

Self-hosted (on-prem deployment)

Version

2026.2.0

Originally created by @rogersmj on GitHub (Mar 2, 2026). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5924 ### Is there an existing issue for this? - [x] I have searched existing issues and this bug hasn't been reported yet ### Platform Web App ### Browser Chrome ### Operating System Other (specify in additional info) ### Bug Description I have deployed Hoppscotch AIO from a Docker image to Google Cloud Run (Google containerized app service). The front end loads, but the backend cannot connect. When attempting to visit `/admin`, it appears it is trying to access the correct route, but I get a "gateway error": <img width="2520" height="1792" alt="Image" src="https://github.com/user-attachments/assets/4cb5fb2e-9411-47e5-8e23-1f8ba090047f" /> When I load the front end, it's trying to access "localhost:3170" even though that's nowhere in my .env: <img width="2662" height="1448" alt="Image" src="https://github.com/user-attachments/assets/d9b1e6c3-ab6b-4820-b94a-c4b65b441b84" /> My .env looks like this (real domain and other sensitive info redacted): ``` DATABASE_URL=**redacted** HOPP_AIO_ALTERNATE_PORT=5000 # Initially had this at 80, tried setting up an alternate ingress. Made no difference DATA_ENCRYPTION_KEY=**redacted** WHITELISTED_ORIGINS=https://hoppscotch.mydomain.com,https://hoppscotch.mydomain.com/admin,https://hoppscotch.mydomain.com/backend/v1,https://hoppscotch.mydomain.com/backend/graphql VITE_BASE_URL=https://hoppscotch.mydomain.com VITE_SHORTCODE_BASE_URL=https://hoppscotch.mydomain.com VITE_ADMIN_URL=https://hoppscotch.mydomain.com/admin VITE_BACKEND_GQL_URL=https://hoppscotch.mydomain.com/backend/graphql VITE_BACKEND_WS_URL=wss://hoppscotch.mydomain.com/backend/graphql VITE_BACKEND_API_URL=https://hoppscotch.mydomain.com/backend/v1 VITE_APP_TOS_LINK=https://docs.hoppscotch.io/support/terms VITE_APP_PRIVACY_POLICY_LINK=https://docs.hoppscotch.io/support/privacy ENABLE_SUBPATH_BASED_ACCESS=true VITE_ALLOWED_AUTH_PROVIDERS=GOOGLE,GITHUB,EMAIL ``` One part of my issue looks the same as #4926, but the fix there (adding `/backend` in the internal service URLs) did not work for me. Note: I've already run the migrations successfully on the Postgres database I setup for Hoppscotch. Possibly related: https://github.com/hoppscotch/hoppscotch/issues/4926 https://github.com/hoppscotch/hoppscotch/issues/3435 ### Deployment Type Self-hosted (on-prem deployment) ### Version 2026.2.0

kerem added the

bug

need testing

labels

2026-03-16 23:58:20 +03:00

kerem commented

2026-03-16 23:58:32 +03:00

Author

Owner

@luongquochai commented on GitHub (Mar 3, 2026):

I guess something wrong in your setup, this is my setup on GC

Domains

  - VITE_BASE_URL=https://app.domain.io
  - VITE_ADMIN_URL=https://admin.domain.io
  - VITE_BACKEND_GQL_URL=https://api.domain.io/graphql
  - VITE_BACKEND_WS_URL=wss://api.domain.io/graphql
  - VITE_BACKEND_API_URL=https://api.domain.io/v1

Security (CORS)

WHITELISTED_ORIGINS=http://localhost:3170,http://localhost:3000,http://localhost:3100,https://app.domain.io,https://admin.domain.io,https://api.domain.io,https://proxy.domain.io

@luongquochai commented on GitHub (Mar 3, 2026): I guess something wrong in your setup, this is my setup on GC ### Domains - VITE_BASE_URL=https://app.domain.io - VITE_ADMIN_URL=https://admin.domain.io - VITE_BACKEND_GQL_URL=https://api.domain.io/graphql - VITE_BACKEND_WS_URL=wss://api.domain.io/graphql - VITE_BACKEND_API_URL=https://api.domain.io/v1 ### Security (CORS) ```bash WHITELISTED_ORIGINS=http://localhost:3170,http://localhost:3000,http://localhost:3100,https://app.domain.io,https://admin.domain.io,https://api.domain.io,https://proxy.domain.io ```

kerem commented

2026-03-16 23:58:37 +03:00

Author

Owner

@rogersmj commented on GitHub (Mar 3, 2026):

@luongquochai Are you using the AIO image, or the three separate Hoppscotch docker images?

It looks like you've setup your backend with a different subdomain, api.domain.io versus having everything on one domain and adding backend, e.g. app.domain.io/backend/... like the docs discuss for AIO, so I'm guessing you're using the three separate containers? How did you do that in GC, what does your domain mapping/DNS look like?

@rogersmj commented on GitHub (Mar 3, 2026): @luongquochai Are you using the AIO image, or the three separate Hoppscotch docker images? It looks like you've setup your backend with a different subdomain, `api.domain.io` versus having everything on one domain and adding `backend`, e.g. `app.domain.io/backend/...` like the docs discuss for AIO, so I'm guessing you're using the three separate containers? How did you do that in GC, what does your domain mapping/DNS look like?

kerem commented

2026-03-16 23:58:42 +03:00

Author

Owner

@luongquochai commented on GitHub (Mar 4, 2026):

@rogersmj
I'm using the AIO image with a multiport setup and subdomain-based routing. My setup uses separate subdomains:

app.domain.io for the main app (port 3000)

admin.domain.io for admin panel (port 3100)

api.domain.io for backend API (port 3170)

In Google Cloud, I'm using a reverse proxy/load balancer layer that routes each subdomain to the corresponding port on the AIO container. All subdomains point to the same external IP."

Notes:

Subpath vs Multiport: AIO has 2 modes:

Subpath access (one domain with paths: /, /admin, /backend) → aio-subpath-access.Caddyfile

Multiport setup (3 separate ports) → aio-multiport-setup.Caddyfile
You are using multiport mode, so ENABLE_SUBPATH_BASED_ACCESS=false is correct.

HTTPS: You need SSL certificates for all 3 subdomains. The reverse proxy layer will handle SSL termination.
CORS: WHITELISTED_ORIGINS must include all 3 of your subdomains.

@luongquochai commented on GitHub (Mar 4, 2026): @rogersmj I'm using the AIO image with a multiport setup and subdomain-based routing. My setup uses separate subdomains: > - app.domain.io for the main app (port 3000) > - admin.domain.io for admin panel (port 3100) > - api.domain.io for backend API (port 3170) > > In Google Cloud, I'm using a reverse proxy/load balancer layer that routes each subdomain to the corresponding port on the AIO container. All subdomains point to the same external IP." **Notes:** - Subpath vs Multiport: AIO has 2 modes: > - Subpath access (one domain with paths: /, /admin, /backend) → aio-subpath-access.Caddyfile > - Multiport setup (3 separate ports) → aio-multiport-setup.Caddyfile You are using multiport mode, so **ENABLE_SUBPATH_BASED_ACCESS=false** is correct. - HTTPS: You need SSL certificates for all 3 subdomains. The reverse proxy layer will handle SSL termination. - CORS: WHITELISTED_ORIGINS must include all 3 of your subdomains.

kerem commented

2026-03-16 23:58:47 +03:00

Author

Owner

@rogersmj commented on GitHub (Mar 4, 2026):

@luongquochai Thanks. But what GC product are you running this on? Google Cloud Run? Or do you have a VM on GCE (Compute Engine)?

As I said, I'm trying to get this working on Google Cloud Run because I want it to be able to go to sleep and not bill me when we're not using it...but Google Cloud Run only supports a single ingress port per service. Hence whey the AIO with subpath access should be perfect for me, but it won't work.

@rogersmj commented on GitHub (Mar 4, 2026): @luongquochai Thanks. But what GC product are you running this on? Google Cloud Run? Or do you have a VM on GCE (Compute Engine)? As I said, I'm trying to get this working on Google Cloud Run because I want it to be able to go to sleep and not bill me when we're not using it...but Google Cloud Run only supports a single ingress port per service. Hence whey the AIO with subpath access should be perfect for me, but it won't work.

kerem commented

2026-03-16 23:58:52 +03:00

Author

Owner

@luongquochai commented on GitHub (Mar 11, 2026):

@rogersmj I'm using VM on GCE. You can try researching with GC.

@luongquochai commented on GitHub (Mar 11, 2026): @rogersmj I'm using VM on GCE. You can try researching with GC.

kerem commented

2026-03-16 23:58:57 +03:00

Author

Owner

@rogersmj commented on GitHub (Mar 11, 2026):

@luongquochai Thanks, but that doesn't help me. I'm not trying to run it on a VM. The point of this is to get it running on Google Cloud Run (their containerized hosting service) so it can "go to sleep" and not cost money when we're not using it.

@rogersmj commented on GitHub (Mar 11, 2026): @luongquochai Thanks, but that doesn't help me. I'm not trying to run it on a VM. The point of this is to get it running on Google Cloud Run (their containerized hosting service) so it can "go to sleep" and not cost money when we're not using it.

kerem commented

2026-03-16 23:59:02 +03:00

Author

Owner

@luongquochai commented on GitHub (Mar 12, 2026):

Maybe I'll try Google Cloud Run next week, @rogersmj . We can exchange ideas if we haven't managed to do it yet 😎

@luongquochai commented on GitHub (Mar 12, 2026): Maybe I'll try Google Cloud Run next week, @rogersmj . We can exchange ideas if we haven't managed to do it yet 😎

kerem referenced this issue

2026-03-17 01:19:35 +03:00

[PR #2327] [CLOSED] chore(deps-dev): bump jest from 27.5.1 to 28.1.0 #3738