Conrad Nuxt

Config, state and memory

runtimeConfig versus app.config versus module-generated templates, where secrets belong, cross-request state pollution and useState on the server, and the memory leaks Vue does not clean up for you.

Runtime config App config State management

From the "Accessing build values during runtime" and "Memory leaks" parts of your Nuxt note.

Know

runtimeConfig: per-environment values set at start-up with NUXT_… variables; private keys stay on the server, public goes to the browser in the payload.
app.config: public, build-time settings (theme, UI defaults), reactive and changeable with updateAppConfig, merged across layers, not settable from environment variables.
addTemplate: a module generates a file in .nuxt at build time from the consumer's options, for example the imports for the enabled locales in Nuxt i18n.
Cross-request state: a module-level ref is shared by every request on the server, leaking data between users and memory; useState and Pinia live on the per-request Nuxt app and travel in the payload.
Leaks Vue does not clean up: timers, window/document listeners, third-party instances; clear them in onUnmounted, register them in onMounted so they never run during SSR.

Exercise

Put a module-level ref counter in a composable, increment it in a page, and load the page from two browsers against nuxt build && node .output/server/index.mjs; watch the value leak, then fix it with useState.
Add a NUXT_PUBLIC_API_BASE and a private NUXT_PAYMENT_KEY, and confirm in the page source which one is visible.

Be able to say

Be able to say· What is the difference between runtimeConfig and app.config?

"runtimeConfig is for values that differ per environment, set by environment variables when the server starts, so one build runs everywhere; private values stay on the server and only public reaches the browser. app.config is for public settings that belong to the build, like theme tokens and UI defaults: bundled, reactive, mergeable across layers, but not set from the environment. Secrets only ever go in private runtimeConfig."

Be able to say· How can state leak between users in a server-rendered app?

"Anything at module level on the server lives as long as the process and is shared by every request. A ref declared at the top of a composable file would hold one user's data when the next user's page renders. In Nuxt, per-user state goes through useState or Pinia, which live on the Nuxt app instance created for each request and are serialised into the payload, so each request starts clean and the client starts with the same values."

Your notes

Open in Notes

Nothing yet. Notes filed here show up on this page and the section overview.

Rendering and hydration

What happens from a request to an interactive Nuxt page, what the payload carries, why plain $fetch in setup causes double requests, hydration mismatches and how to find them, SSR trade-offs with per-route rendering, and tree-shaking.

Modules, plugins and layers

Module versus plugin, what a module can do with @nuxt/kit, build-time, app and Nitro hooks, an observability module with a provider option, layers and their override order, and when a platform ships a layer or a module.