Next.js from a DevOps perspective

[cadavre]

To begin with – I’m not a frontend developer, and I’ve never written a single line of code in Next.js. This time, I’m speaking from a DevOps perspective.

On a daily basis, I work with Kubernetes and/or Docker + Compose. And I must say – I’ve rarely had such a confusing experience when trying to deploy and operate a modern web framework as I’ve had with Next.js.

I’m sharing this not as a rant, but in hopes of sparking a productive discussion about how Next.js could be made more friendly for containerized, production-grade environments.

1. Runtime Configuration

In Node.js projects, configuration typically comes from process.env, which works fine for server-side logic.
However, frontend code in the browser doesn’t have access to those variables. Instead, you’re expected to expose them by prefixing with NEXT_PUBLIC_. The issue?

By default, environment variables are only available on the server. To expose an environment variable to the browser, it must be prefixed with NEXT_PUBLIC_. However, these public environment variables will be inlined into the JavaScript bundle during next build.

This effectively bakes environment variables into the build output, making runtime configuration nearly impossible.

Most modern CI/CD pipelines assume that you build an image once and reuse it across multiple environments by changing runtime variables. In Next.js, however, this isn’t really possible unless you rebuild the app for every environment – which defeats the purpose of immutable builds and slows deployments.

The alternative — building during deployment – is also not great, as production servers shouldn’t be doing CPU-intensive builds just to inject config.

Has anyone found a clean pattern or official recommendation from the Next.js team to handle this scenario? What I'm using currently is a solution found somewhere on Reddit with "BAKED_NEXT_PUBLIC_" vars that are replaced with sed on runtime launch. This is not good.

2. Having a Backend for Frontend

A production-built React SPA can easily run in an nginx container using ~32 MB of memory.
By contrast, a Next.js app (even for mostly static content) requires a full Node.js runtime, easily consuming 512 MB or more.

That might be fine for some use cases, but it feels like an architectural mismatch for simpler frontends — especially when the benefits of SSR or “server actions” aren’t strictly required. This tight coupling between backend and frontend layers makes operations heavier and removes flexibility. Caches like Varnish or even plain nginx reverse proxies allow for clearer separation of concerns – something that’s harder to achieve in Next.js (but maybe easier out-of-the-box).

So, is Next.js meant only for apps that truly need server-side rendering, or is there a recommended way to deploy it more like a traditional frontend app?

3. Logging

Logging should help you understand what went wrong – not just confirm that something did.

Here’s a real-world example I encountered recently:

frontend-1  | [auth][error] TypeError: fetch failed
frontend-1  |     at node:internal/deps/undici/undici:13510:13
frontend-1  |     at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
frontend-1  |     at async nb (/app/.next/server/app/api/auth/[...nextauth]/route.js:368:49451)
...

What does fetch failed even mean here? Which URL failed? What context or request triggered this?
The stack trace references deeply optimized internal code – none of which is helpful for diagnosing the issue.

I get that this is partly due to bundling and optimization, but perhaps there’s a way for Next.js to preserve clearer, source-mapped logs (especially for production server)?

---

Final Thoughts

I completely understand that Next.js is flexible and allows deep customization. Still, some sensible defaults for DevOps workflows – such as runtime configuration, lightweight deployments, and readable server logs – would make a huge difference.

This post may stem from my limited experience with Next.js, but I wanted to share the operational challenges I’ve faced and hear how others are handling them. Maybe I’m missing a better approach – and if so, I’d love to learn from you.

[PieterDePauw]

"You’re absolutely right"

[marcomele]

For runtime configurations, this is our current setup:

• .env.development for development env
• .env.<dev|staging|prod> for deployed envs
• .env.production contains only env-agnostic properties if they're strictly required at build time

We build in standalone mode, then in the container we run using something like

dotenvx run --env-file=.env.<dev|staging|prod> -- node server.js

Then, in the _app.tsx getInitialProps, if it's a server-side run, we add an env object to the pageProps where we add everything in the server's env that starts with NEXT_PUBLIC_. In the browser, we access env from the page props.

Of course this only works with SSR. Some optimizations can be made to only add the env to the page props on the first page load and skip it for navigation.

[icyJoseph]

Regarding that fetch failed error message. I do believe this is addressed, at least partially, by #60274 right?

It is a bit annoying but Node.js' printouts for fetch errors, can sometimes... end up being cryptic, like:

> fetch("http://localhost:3000/abc")
Promise {
  <pending>,
  [Symbol(async_id_symbol)]: 454,
  [Symbol(trigger_async_id_symbol)]: 434
}
> Uncaught [TypeError: fetch failed] {
  [cause]: AggregateError [ECONNREFUSED]: 
      at internalConnectMultiple (node:net:1122:18)
      at afterConnectMultiple (node:net:1689:7)
      at TCPConnectWrap.callbackTrampoline (node:internal/async_hooks:130:17) {
    code: 'ECONNREFUSED',
    [errors]: [ [Error], [Error] ]
  }
}

[icyJoseph]

Your runtime configuration point is valid, though I feel like, that's one of those things that the community did back then, so Next.js just adopted it, in order to lower barrier of entry, through familiarity. And this is something you can still see in other tooling.

• https://create-react-app.dev/docs/adding-custom-environment-variables/
• https://vite.dev/guide/env-and-mode

I think though, that RSC can change this. This is just an idea I have, but we can combine a couple of things

• connection API
• Static shell rendering with PPR/Cache Components
• Server Client boundary, or taint them to avoid Server Client boundary crossing

import { experimental_taintUniqueValue } from 'react';
import { connection } fro 'next/server'

async function getEndpointConfig(){
   // do not pre-render the sub-tree using this, wait for runtime connection
   await connection()

   // read value
   const value = process.env.ENDPOINT_CONFIG
   // assert its presence
   if(!value) throw new Error("yada yada")
   // taint it IF needed, but then you won't be able to pass it to the client
   // experimental_taintUniqueValue(
   //   'Do not pass this value to the client.',
   //   process, // lifetime - while process is in scope (always) taint this value
   //   process.env.ENDPOINT_CONFIG
   // );

   return value
}

This way you can isolate reading this env vars, and not have them be baked in. You can do this already today, but with Next 16, you'd also be able to have a static shell around the content that uses an env var, and have that defer to the runtime.

There's likely some omissions and I am being too optimistic about it, but this could be the way to "solve" this point once and for all.