A Nuxt project with a server/ directory is a full application: routes, middleware, database access, sessions, background tasks and a deployable server, all in one repository and one type system. Fullstack interviews for Nuxt roles test whether you treat that server as a real backend: validated inputs, a data layer, authorisation, caching, operations. The module-author sections explain Nitro from the inside; this section is about building with it.

Know

• Nitro is the server engine: it compiles server/ into a standalone, platform-agnostic server (.output/server) using h3 as the HTTP layer, with presets for Node, Cloudflare Workers, Vercel, Netlify, AWS Lambda, Deno, Bun and static hosting. Nuxt 4 runs Nitro 2 with h3 v1 APIs; Nitro 3 and h3 v2 (web-standard Request/Response) arrive with Nuxt 5 Nuxt 5 , and nuxt/server (from 4.6) is the runtime-agnostic import surface that survives that change.
• One type system, one deploy: the handler's return type reaches the page through $fetch; schemas in shared/ validate on both sides; one build produces the client and the server. That is the productivity argument for fullstack Nuxt.
• When Nitro is enough: a product's own API, a backend-for-frontend aggregating third-party services, auth and sessions, webhooks, scheduled tasks, file handling; anything a typical Node service does. When to separate: long-running or CPU-heavy work, a different language or team owning the domain, very high throughput independent of the frontend, or compliance boundaries. Even then, Nitro remains the BFF in front.
• The server is a different runtime: no window, module scope is process scope (shared across requests), connections are pooled and long-lived, secrets come from runtimeConfig, and edge presets restrict Node APIs. Cross-request state pollution and unbounded caches are the classic bugs (memory leaks).
• Operations are part of the job: health checks, structured logs with request ids, error monitoring, migrations, zero-downtime deploys, and knowing the cost and limits of the chosen preset.

How the pages fit

How it works

The shape of a well-built Nitro backend inside a Nuxt project:

server/
├── api/                 thin handlers: validate -> authorise -> call a service -> shape the response
│   ├── products/[id].get.ts
│   └── orders.post.ts
├── routes/              non-/api routes: sitemap.xml, webhooks, redirects, health
├── middleware/          per-request: request id, session -> event.context.user
├── plugins/             startup: db pool, error reporting, scheduled task registration, hooks
├── utils/               auto-imported: useDb(), requireRole(), assertRateLimit(), services/*
├── tasks/               Nitro tasks (cron / on-demand): cleanup, digests, reindex
├── db/                  schema.ts, migrations/ (Drizzle)
└── tsconfig.json        server project reference
shared/
├── schemas/             zod: one definition for client and server
└── types/               DTOs

import { createOrderSchema } from '#shared/schemas/order'

export default defineEventHandler(async (event) => {
  const { user } = await requireUserSession(event)                    // who
  const input = await readValidatedBody(event, createOrderSchema.parse) // what, validated
  const order = await createOrder(useDb(), { userId: user.id, ...input }) // service: the business rule lives here, testable without HTTP
  setResponseStatus(event, 201)
  setResponseHeader(event, 'location', `/api/orders/${order.id}`)
  return toOrderDto(order)                                             // never the raw row
})

Exercise

Be able to say