I suspect it's because I'm wrapping the code to fetch an env inside a function instead of using process.env.[variable] directly.

This is what the wrapper function looks like:

export function fetchenv(name: string) {
  const val = process.env[name];
  if ((val === undefined) || (val === null)) {
    throw Error(`'${name}' env var not found`);
  }

  return val;
}

I'm using it just to ensure that the variable is present. process.env returns undefined when the variable is not found but I wanted it to raise the error instead so I wrapped it in a check.

I'm not sure if this is the problem but this is my guess

I had this same issue when trying to validate envs with zod lol.

from what I understand from that experience, even though the client exposed variables are marked with NEXT_PUBLIC_ the server and client cannot both read from the same function (or object in my case with zod) containing environment variables.

I don't know what the actual cause is, but, that's what I gathered from my experience with zod and envs, it was a pain to get right just for some typesafety

I'm literally doing this just for the sake of typesafety lol. Otherwise the lib will itself so the same thing and raise an error but yeah...
As much as I understand it, the nextjs builder reads for the process.env.[variable] and replaces it with the actual value at build time. So cause I'm wrapping it inside a function, it obviously cannot know the variables to replace without actually interpreting and executing the code..

I'll try to hard code the variables without using a function if that works