Opt out env vars to be embedded at build time

[denexapp]

Hi.

I stumbled upon this issue. We do use a hosting system that accepts a docker image and then deploys it to multiple environments. Each environment has different set of environment variables, they can not be evaluated at build time.

So in order to prevent env var to be embedded at build time, we can use force-dynamic. But the issue is, that I use env var deep in the tree in some server components, but force-dynamic can be defined at route segment level only.

So I need to manually track if a page/layout directly or indirectly uses some server components that uses environment variable, and if so, I should add force-dynamic. That's not convenient to say the least.

Another point is that while env vars are not available at build time, they are available at runtime. And in my case they do remain static.

So I'd like to see a way to specify at what time an env var should be evaluated: at build time, at startup time or at every time it's accessed. Kinda similar to fetch's no-store and force-cache.

Similar but not the same issue: #48989

[omarelshiltawi]

let me know if this helps https://chat.elapse.ai/conversation/a133377b-0464-49a1-bbf6-1e00e7949f97

[icyJoseph]

This is always been a bit scary. If you include say (even in Pages dir):

export default function Home() {
  return <p>{process.env.SECRET_LEAK}</p>;
}

Then if this page is pre-rendered, and you make a request with a non-JS client, you see:

And even though, hydration would remove it, it is in the initial HTML anyway.

One way I handle this is to have a get-config function, which is async.

On the get-config function module I "load" from the process.env file into an object, and the get-config function resolves to that object when called.

So that in the "pages" directory you'd not be able to inline this into the JSX. You'd necessarily have to have useState + useEffect promise coupling.

Now in Server Components... you can await that promise and leak anyway... This is but a draft of an initial attack on this problem:

const getEnv = async () => {
  try {
    await fetch("getting-secrets", { cache: "no-cache" });
  } catch (e) {
    return process.env.APP_SECRET;
  }
};

export default async function Home() {
  const secret = await getEnv();
  return (
    <main>
      Hello {secret}
    </main>
  );
}

I think this one would do the trick... but oh it is getting complicado...

[denexapp]

Whoa, that's an interesting trick. So you use real fetch to notify Next that this route segment is dynamic, but this fetch always crashes, and you handle it. And this fetch can be invoked deep in the tree

Async shouldn't be a problem here cause server component rerenders on the server, which requires network delay anyway

[icyJoseph]

Wish they had made a fetch derivate, rather than patch/extend fetch. Or maybe expose a function that would take in a function as parameter, and mark that as dynamic data.

So that anyone who reads it automatically opts the entire segment into dynamic rendering. Sorta like headers or cookies functions.

That ugly fetch hack could be abstracted away into a module and then you could also poison it by adding the server-only directive, but I digress.

It's not so trivial to hide away sensitive/secret things fully, in a "fool" proof way.

[denexapp]

I did some testings, the fetch hack doesn't seem to work, at least in the latest version of Next.js 13.4.19.

But I've found an another solution: calling cookies function from next/headers does the trick. It opts out a route segment from being prerendered at build time, doesn't crash the build and can be called from children functions or components, no force-dynamic required.

I made a utility function for our monorepo.

[denexapp]

Edit: while playing with cookies I noticed that it must not be wrapped in try block in order to not fail during the build. The same logic may apply to fetch. But I use cookies anyway because I have no idea how to access fetch of Next.js in a library.

[theoephraim]

I've run into this problem as well, and think a good solution would be if you could just provide a schema for your config where you can specify if an env var should be treated as "static" (bundled at build time) or "dynamic" (always read at boot time). Then the framework should just do the right thing. This would also decouple the concept of something being secret/public/sensitive with being static/bundled as it currently is using a prefix like NEXT_PUBLIC_.

Security also gets pretty dicey (as @icyJoseph showed above) as in these hybrid rendering setups as it can be hard to reason about where your code will run or what will get bundled. Again I think the solution there is specifying in a schema which items are sensitive, and then let the tooling do the right thing and protect you from making a mistake.

After hacking together mediocre solutions so many times, I finally decided to build something more general that tries to solve all my config-related problems. I may be biased since I built it, but I really think it does.

Here is a quick intro with some examples and screenshots.

Internally the Next.js integration uses a webpack plugin to inject code replacements based on your schema, and additional code that prevents accidental leaks. Accessing a "dynamic" config item also calls next's headers() function to force that page into dynamic mode. Lot going on under the hood to make it all work...

Please give it a whirl and let me know what you think!

[nicholas-johnson-techxcel]

Can this please stop executing my code at build time? All of my checks for null env vars stop the build. And I most certainly do not want it embedding secrets in my docker container.