Configure Nuxt, keep secrets in runtimeConfig and .env, then build for a Node server or generate a fully static site.
Why: nuxt.config.ts is the single place to configure your app — add modules, set global options, and register settings. Note: defineNuxtConfig gives you type hints for every option.
// nuxt.config.ts
export default defineNuxtConfig({
devtools: { enabled: true },
modules: ['@nuxt/image'],
})Why: keep secrets and settings in runtimeConfig. Top-level keys are private (server only); keys under public are sent to the browser. Note: leave the values empty here and fill them from .env (next topic).
// nuxt.config.ts
export default defineNuxtConfig({
runtimeConfig: {
apiSecret: '', // private — server only
public: {
siteUrl: '', // safe to expose to the browser
},
},
})Why: .env (git-ignored) fills runtimeConfig at startup — a NUXT_ prefix maps to private keys and NUXT_PUBLIC_ to public ones. Read the values with useRuntimeConfig(). Note: only call the private part on the server.
# .env (do not commit this file)
NUXT_API_SECRET=super-secret
NUXT_PUBLIC_SITE_URL=https://example.com<script setup lang="ts">
const config = useRuntimeConfig()
// config.public.siteUrl is available everywhere
// config.apiSecret is only readable on the server
</script>Why: deploying means running the production build. "build" produces a Node server in .output; "preview" runs it locally so you can check it before shipping. Most hosts run build for you.
$ pnpm build$ pnpm previewWhy: if your site needs no server, generate it as plain HTML/CSS/JS and host it anywhere (S3, GitHub Pages, any static host). Run nuxi generate; the output lands in .output/public. Note: server-only features won’t work in this mode.
$ pnpm generateProduces a fully static site in .output/public — upload that folder.