Deployed strapi admin panel trying to hit localhost:1337

System Information
  • Strapi Version: 3.6.2
  • Operating System: Ubuntu 18.04.5 LTS
  • Database: Postgres
  • Node Version: 12.18.3
  • NPM Version: 7.20.0
  • Yarn Version: 1.22.5

Hi! I’ve started seeing a strange issue recently in my deployed strapi instance. I have it deployed on https://xyz.com, say. When I open my admin panel in the browser, it tries to hit http://localhost:1337/admin/init instead of trying to hit https://xyz.com/admin/init. This ends up with my admin panel being stuck in a “loading” state, and me getting a CORS error for trying to hit http://localhost:1337.

My setup
I’ve got my instance deployed on an AWS EC2 instance, with pm2 managing the process. nginx routes requests to https, with certbot for the ssl. My strapi.conf:

server {
   # Listen HTTP
   listen 80;
   server_name www.xyz.com xyz.com;

   # Redirect HTTP to HTTPS
   return 301 https://$host$request_uri;
}

server {
   # Listen HTTPS
   listen [::]:443 ssl ipv6only=on; # managed by Certbot
   listen 443 ssl;
   server_name www.xyz.com xyz.com;
   underscores_in_headers on;

   # SSL config
   ssl_certificate /etc/letsencrypt/live/xyz.com/fullchain.pem; # managed by Certbot
   ssl_certificate_key /etc/letsencrypt/live/xyz.com/privkey.pem; # managed by Certbot
   include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
   ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

   # Proxy Config
   location / {
   rewrite ^/?(.*)$ /$1 break;
       proxy_pass http://strapi;
       proxy_http_version 1.1;
       proxy_set_header X-Forwarded-Host $host;
       proxy_set_header X-Forwarded-Server $host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_set_header Host $http_host;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "Upgrade";
       proxy_pass_request_headers on;
   }
}

config/server.js:

module.exports = ({ env }) => ({
  host: env("HOST", "0.0.0.0"),
  port: env.int("PORT", 1337),
  url: env("PUBLIC_URL", "http://localhost:1337"),
  admin: {
    auth: {
      secret: env("ADMIN_JWT_SECRET", "default-secret-here"),
    },
  },
});

My pm2 ecosystem.config.js:

module.exports = {
  apps: [
    {
      name: 'my-project',
      cwd: '/home/ubuntu/my-project',
      script: 'yarn',
      args: 'start',
      interpreter: '/bin/bash',
   ...
      env: {
        NODE_ENV: 'staging',
        ...
	    PUBLIC_URL: 'https://xyz.com',
       ...
      },
    }
  ],
};

Things I’ve tried:

  1. Access by static IP instead of .xyz Domain Names | Join Generation XYZ - same result. Rules out nginx misconfig.
  2. Updating strapi to 3.6.5 - same result
  3. Delete .cache, node_modules, run yarn build --clean and run the server again - same result

I suspect there’s something up with the PUBLIC_URL being passed to the admin panel. I peeked at the admin panel code a bit, it seems like it’s getting the base url value from strapi.backendURL - any ideas where this is pulled from? Or any other ideas to try out?

Update: I’ve tried creating a separate server.js for the env that I’m running on where I’m setting the fallback url for PUBLIC_URL explicitly as well, and rebuilt the admin panel. No help.

config/env/staging/server.js:

module.exports = ({ env }) => ({
  host: env("HOST", "0.0.0.0"),
  port: env.int("PORT", 1337),
  url: env("PUBLIC_URL", "https://xyz.com"),
  admin: {
    auth: {
      secret: env("ADMIN_JWT_SECRET", "default-secret-here"),
    },
  },
});

Also confirmed that this is being correctly set, logging process.env.PUBLIC_URL gives me https://xyz.com

Are you also passing the NODE_ENV to the build command as well?

1 Like

Bingo! Not sure how my system was working for so long without it but adding NODE_ENV to the build command fixes it. Thanks!

2 Likes

I’m not sure either :smiley:

The build process reads that server.js (and depending on the NODE_ENV will attempt to read ./config/env/$NODE_ENV/server.js) it parses the url and admin.url to statically build them into the admin.

Glad you got it working!

So it is impossible to reuse the same Docker image in development, staging and production. That’s a bummer. I will have to rebuild the Docker image for every environment just for the PUBLIC_URL variable?

Yes exactly

You are kidding? This goes against the whole reason to use container images…

So if you have 20 customers, which 3 environments each. Per release you need to build 60!! images.

*edit: there is a way to avoid this to some degree. If we don’t do the RUN yarn build and instead do CMD yarn build ; yarn start it will compile at deploy time. This does add compile time and resource usage that is unnecessary.

This should be changed.

I’d recommend then you deploy the admin panel somewhere else, like a static host (vercel is good choice) and just keep your docker containers for running the Strapi backend.

Hello guys, I’m facing the exact same problem described by @amitav13 but I’m running on development mode using https://gitpod.io(remote development server accessible via the browser).

I’m not sure how to apply the solution marked to my own problem. I’m not trying to deploy my app. I’m only trying to customize my admin frontend using npm develop -- --watch-admin.

How do I get this working in my own case?

Add the following like to your “.env” file and rebuild your admin panel using npm/yarn command.

STRAPI_ADMIN_BACKEND_URL= // just add this entry without a value specified.

3 Likes

Sir, do you know if there is any plan to make it right any time soon?
I can’t even imagine why it was done the way it is in the first place.

1 Like

I’m deploying at heroku

I’m getting the same error but with other URL http://localhost:1337/admin/project-type

All my node_envs are setted up in heroku
image

Did anyone solved it???

I have the same issue. I Did not se the env or build using .env can someone help me understand this?

i just added RUN yarn build afert COPY and it worked

My dockerfile:

FROM node:14
# Installing libvips-dev for sharp compatability
RUN apt-get update && apt-get install libvips-dev -y
ARG NODE_ENV=development
ENV NODE_ENV=${NODE_ENV}
WORKDIR /opt/
COPY ./package.json ./
COPY ./yarn.lock ./
ENV PATH /opt/node_modules/.bin:$PATH
RUN yarn config set network-timeout 600000 -g
RUN yarn install
WORKDIR /opt/app
COPY ./ .
RUN yarn build
EXPOSE 1337
CMD ["yarn", "develop"]
2 Likes

I have the exact same issue not using docker. All i did want change the path in config/admin.js url: ‘/MASTVR’, There is no reason for it to call admin path. I did add this as well STRAPI_ADMIN_BACKEND_URL=

@DMehaffy @amitav13

Deployed strapi admin panel trying to hit localhost:1337
Got the same error, even though I tried set NODE_ENV=production&&npm run build command

Invalid: http://localhost:1337/admin/project-type
Expected: http://20.79.89.216:1337/admin/project-type

[image]

I am also getting this issue

In the .env file i have my IP address set and also [ STRAPI_ADMIN_BACKEND_URL= ]
In my server.js file i have:
host: env(‘HOST’, ‘X.X.X.X’),
With my IP substituted in

Even after running a rebuild with npm/yarn it will still point the admin page to localhost

You shouldn’t be using set for env vars in Windows 10/11 this was for CMD which no longer exists. In powershell you should be using $env like: $env:NODE_ENV="production" npm run build

you need to set the url not the host