starred/hoppscotch

Fork 0

mirror of https://github.com/hoppscotch/hoppscotch.git synced 2026-04-26 01:06:00 +03:00

[GH-ISSUE #4700] [bug]: Frontend GraphQL and Backend API calls not using .env URL values with AIO Deployment #1751

New issue

Open

opened 2026-03-16 21:36:54 +03:00 by kerem · 3 comments

kerem commented

2026-03-16 21:36:54 +03:00

Owner

Originally created by @Jordan-Eckowitz on GitHub (Jan 27, 2025).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/4700

Is there an existing issue for this?

I have searched the existing issues

Current behavior

I have configured my Hoppscotsch environment to use the AIO (all-in-one) approach. I have used docker compose to start Hoppscotsch and a local Postgres DB.

My HOPP_AIO_ALTERNATE_PORT=80 and my docker compose is forwarding everything from port 80 to 3000 in my local environment (referenced below).

The .env file frontend config has been updated to use the AIO sub-path approach. Even though I have updated VITE_BACKEND_GQL_URL and VITE_BACKEND_API_URL values it looks like the frontend is still using the default localhost:3170 URL (see screenshot below for network calls to fetch graphql data on load as well as the logout operation).

Is there something I'm missing?

# .env 

#-----------------------Frontend Config------------------------------#

# Base URLs
VITE_BASE_URL=http://localhost:3000
VITE_SHORTCODE_BASE_URL=http://localhost:3000
VITE_ADMIN_URL=http://localhost:3000/admin

# Backend URLs
VITE_BACKEND_GQL_URL=http://localhost:3000/backend/graphql
VITE_BACKEND_WS_URL=wss://localhost:3000/backend/graphql
VITE_BACKEND_API_URL=http://localhost:3000/backend/v1

# Terms Of Service And Privacy Policy Links (Optional)
VITE_APP_TOS_LINK=https://docs.hoppscotch.io/support/terms
VITE_APP_PRIVACY_POLICY_LINK=https://docs.hoppscotch.io/support/privacy

# Set to `true` for subpath based access
ENABLE_SUBPATH_BASED_ACCESS=true

# docker-compose.yml

services:
  hoppscotch:
    container_name: HOPPSCOTCH
    image: hoppscotch/hoppscotch:latest
    ports:
      - "3000:80"
    depends_on:
      - postgres
    env_file:
      - .env
    restart: unless-stopped

  postgres:
    container_name: POSTGRES_HS
    image: public.ecr.aws/docker/library/postgres:15.5-alpine
    ports:
      - "5432:5432"
    user: postgres
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: testpass
      POSTGRES_DB: hoppscotch
    healthcheck:
      test:
        [
          "CMD-SHELL",
          "sh -c 'pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}'",
        ]
      interval: 5s
      timeout: 5s
      retries: 10
    volumes:
      - hoppscotchData:/var/lib/postgresql/data

volumes:
  hoppscotchData:

Steps to reproduce

provided above.

Environment

Production

Version

Local

Originally created by @Jordan-Eckowitz on GitHub (Jan 27, 2025). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/4700 ### Is there an existing issue for this? - [x] I have searched the existing issues ### Current behavior I have configured my Hoppscotsch environment to use the AIO (all-in-one) approach. I have used docker compose to start Hoppscotsch and a local Postgres DB. My `HOPP_AIO_ALTERNATE_PORT=80` and my docker compose is forwarding everything from port `80` to `3000` in my local environment (referenced below). The `.env` file frontend config has been updated to use the AIO sub-path approach. Even though I have updated `VITE_BACKEND_GQL_URL` and `VITE_BACKEND_API_URL` values it looks like the frontend is still using the default `localhost:3170` URL (see screenshot below for network calls to fetch graphql data on load as well as the logout operation). Is there something I'm missing? <img width="1728" alt="Image" src="https://github.com/user-attachments/assets/4f227ae5-8dfd-4e86-a97b-b05100bf6a39" /> ```.env # .env #-----------------------Frontend Config------------------------------# # Base URLs VITE_BASE_URL=http://localhost:3000 VITE_SHORTCODE_BASE_URL=http://localhost:3000 VITE_ADMIN_URL=http://localhost:3000/admin # Backend URLs VITE_BACKEND_GQL_URL=http://localhost:3000/backend/graphql VITE_BACKEND_WS_URL=wss://localhost:3000/backend/graphql VITE_BACKEND_API_URL=http://localhost:3000/backend/v1 # Terms Of Service And Privacy Policy Links (Optional) VITE_APP_TOS_LINK=https://docs.hoppscotch.io/support/terms VITE_APP_PRIVACY_POLICY_LINK=https://docs.hoppscotch.io/support/privacy # Set to `true` for subpath based access ENABLE_SUBPATH_BASED_ACCESS=true ``` ```yml # docker-compose.yml services: hoppscotch: container_name: HOPPSCOTCH image: hoppscotch/hoppscotch:latest ports: - "3000:80" depends_on: - postgres env_file: - .env restart: unless-stopped postgres: container_name: POSTGRES_HS image: public.ecr.aws/docker/library/postgres:15.5-alpine ports: - "5432:5432" user: postgres environment: POSTGRES_USER: postgres POSTGRES_PASSWORD: testpass POSTGRES_DB: hoppscotch healthcheck: test: [ "CMD-SHELL", "sh -c 'pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}'", ] interval: 5s timeout: 5s retries: 10 volumes: - hoppscotchData:/var/lib/postgresql/data volumes: hoppscotchData: ``` ### Steps to reproduce provided above. ### Environment Production ### Version Local

kerem added the

bug

need testing

labels

2026-03-16 21:36:54 +03:00

kerem commented

2026-03-16 21:37:05 +03:00

Author

Owner

@Jordan-Eckowitz commented on GitHub (Jan 28, 2025):

I've discovered that if I Open up developer tools and do a Hard Refresh then it pulls through the correct URL. But, if I refresh the page the usual way, or open the client in a new tab, then its back to the same issue.

Also, I've tried deploying the client and I'm seeing the exact same problem.

@Jordan-Eckowitz commented on GitHub (Jan 28, 2025): I've discovered that if I Open up developer tools and do a `Hard Refresh` then it pulls through the correct URL. But, if I refresh the page the usual way, or open the client in a new tab, then its back to the same issue. Also, I've tried deploying the client and I'm seeing the exact same problem.

kerem commented

2026-03-16 21:37:10 +03:00

Author

Owner

@BrianLakstins commented on GitHub (Feb 7, 2025):

I'm seeing the same behavior with the same fix (hard refresh uses environment variables) using docker compose with 3 containers and images 2025.1.1 and Firefox browser.

Tried in Edge browser and it worked fine.

I tried clearing cookies, cache, and localStorage on Firefox, but it still kept trying to access the backend as http://localhost:3170 when first loading.

@BrianLakstins commented on GitHub (Feb 7, 2025): I'm seeing the same behavior with the same fix (hard refresh uses environment variables) using docker compose with 3 containers and images 2025.1.1 and Firefox browser. Tried in Edge browser and it worked fine. I tried clearing cookies, cache, and localStorage on Firefox, but it still kept trying to access the backend as http://localhost:3170 when first loading.

kerem commented

2026-03-16 21:37:15 +03:00

Author

Owner

@L3o-pold commented on GitHub (Apr 15, 2025):

It's the cache worker, you can clear it on Chrome using devtools > Application > Right clic on Cache Storage > Delete

@L3o-pold commented on GitHub (Apr 15, 2025): It's the cache worker, you can clear it on Chrome using devtools > Application > Right clic on Cache Storage > Delete

kerem referenced this issue

2026-03-17 01:10:34 +03:00

[PR #1941] [MERGED] duplicate request in collections. #3572