Does NODE_ENV affect build environment or only for runtime environment

Questions and Answers
1
System Information
  • Strapi Version: 3.6.2

Hi everyone,

I have a very simple question. Does the NODE_ENV affect in any way the strapi build command or is it strictly a runtime setting?

Thank you

2

Both, specifically in the build it takes into account the optional url and admin.url keys from the server.js and depending on if you have any ./config/env/${NODE_ENV}/server.js files.

3

Hmmm does that mean if I am running the build in a container I would need to build the container per environment?

I was thinking of building the container once and then at runtime (during docker run) I would set the correct NODE_ENV to dev, staging for example

4

Effectively yes because the build is static and it’s react CSR meaning the “address” to the Strapi backend needs to be compiled into the static generated files, after the admin is built then the Strapi backend is just acting as basically a webserver that is serving those static files.

The client side loads the files and makes requests using the compiled URL and it needs to know the backend address to do that.

1 Like
5

I don’t understand. Even if Strapi is a CSR you would probably be using relative URLs and the full URL is decided at runtime depending on the server serving those static files, in this case it is Strapi.

I can also imagine that the files in /config/env/${NODE_ENV}/server.js can also be selected on server start at runtime depending on $NODE_ENV.

The only thing that comes to my mind is whether you want to produce different containers that contain minified and/or obfuscated admin panel vs. non-minified with debug symbols for dev environments.

What am I missing?

6

I guess what you mentioned is related to Deployment but in my case the admin panel and the frontend are on the same server.

It is always listening on 0.0.0.0

7

This is the problem, it’s not using relative URLs. The frontend needs to know how to make API requests to the backend as the frontend code is executed by the users browser, thus that browser is making API calls.

We can’t change the absolute URL during runtime because nothing modifies the admin build during runtime (the entire admin is compiled at build time and during runtime we are just serving the static assets)

The only thing the backend understands is that anything point at /admin means it needs to load the static files and serve them. What you are describing would be fine if we were using something like Next.js for the admin (SSR) but it won’t work with just normal React (CSR).

Now if your docker container only ran the backend and you had some kind of CI/CD to build the admin and deploy it to a static location (Say AWS-S3 + Cloudfront) then you could easily get away with only building one container and swapping the vars out at runtime since the docker container wouldn’t be serving the admin panel. The vars needed to build the admin would be injected during the build process in CI/CD and deployed.

Assuming you had 3 environments:

  • CI/CD builds and deploys 3 static admin builds for Prod, Stag, Dev to S3 => Cloudfront acts as the public proxy/cache for the Admin
  • One docker container built and stored in a registry (private most likely) that could be auto-scaled and deployed to any environment.
1 Like
8

To use a very poor analogy would be:

We need to write the address of an event into a letter before we send it so the person knows where to go before the event instead of giving everyone the address when the event starts.

(this doesn’t quite the point across for SSR but it breaks down the logic of how CSR works).

We can’t modify that address once we have written the letter and tossed it in the mail, nor can we give relative directions like “turn left when you see this giant rock, then an immediate right”.

1 Like