Standalone output does not load runtimeConfig from environment variables

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
  Platform: darwin
  Arch: x64
  Version: Darwin Kernel Version 21.4.0: Fri Mar 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64
Binaries:
  Node: 18.2.0
  npm: 8.9.0
  Yarn: 1.22.18
  pnpm: 7.3.0
Relevant packages:
  next: 12.2.0
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0

What browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

Docker with node .next/standalone/server.js

Describe the Bug

When running the standalone server using node .next/standalone/server.js the server does not load any of the runtimeConfig values from the environment variables, hardcoded values do work. It does get loaded when running the server using next start.

Setting those environment variables during build time does show them when running the server, but that kind of beats the point of using the runtimeConfig and might make for really confusing interactions (it took me for a run).

Expected Behavior

That running node .next/standalone/server.js will load the runtimeConfig variables that are set using an environment variable during runtime.

Link to reproduction

https://github.com/blurrah/next-runtime-standalone-bug

To Reproduce

• Build the server using yarn build
• Run the server using TEST_VALUE=test node .next/standalone/server.js
• You will just see a dash returned on the homepage

When running the server using TEST_VALUE=test yarn start it will work properly and return test - test.

Using TEST_VALUE=test yarn build -> node .next/standalone/server.js also returns test - test.

[ShadiBlitz]

@ijjk Thanks. But what is the approach to be able to read environment variables dynamically at runtime from a docker container for a standalone build (that can be read by the client too…) ?

[durdo]

I ran into this and would like to understand where we stand on it:

1. Shouldn’t this behavior be documented in the output: "standalone" section of the docs?
2. Is there a plan to fix this behavior for future releases?
3. Is there and custom server I can use as an example to solve this?