I'm not sure about the flickering in the example you posted, but having env variables available in a statically rendered page that gets rendered on the server seems like expected behavior.

That doesn't mean your environment variables are exposed to the client. It means you can build a webpage like <div>{process.env.MONGODB_URI}</div> and NextJS will compile that on the server and then serve it as a static web page

Actually I was able to reproduce the flickering thing like this

import ClientComponent from "./clientComponent"

export default async function Page() {
  return <ClientComponent />;
}

'use client'

export default function ClientComponent() {
  return <div>{process.env.MONGODB_URI}</div>;
}

but that doesn't mean all of the environment variables get sent to the client, the environment variable was expanded out into the component on the server

It even mentions it in the hydration error, that it did not expect the server html to contain the text

Now when I change my env variable from MONGODB_URI to NEXT_PUBLIC_MONGODB_URI I no longer get the hydration error because it is available to be used on the client.

But still, all of my env variables are not getting shipped down to the client

It's okay to use environment variables on the server (we use them to connect to databases). Just don't put your private env variables into divs and render them otherwise the client will see them

if you add import "server-only"; to the top of your utils file then you can ensure it's only ever called on the server. it'll error at build time if that's not the case.

you can also scan the build output of .vercel/output with a tool like https://github.com/trufflesecurity/trufflehog to detect any secrets in the output. I wrote a blog post about how to do this in GitHub Actions at https://blog.arcjet.com/secret-scanning-and-next-js-builds/

@Komondor @davidmytton thank you for the detailed responses!

and I will check out the blog post :)