codexmachina
Framework

Every verified stack that runs on Nuxt 4.

Nuxt 4 (framework mode): full-stack Vue SSR: client under app/ (Vite), server under server/ (Nitro), API as server/api/*.post.ts Nitro route handlers.

240 verified stacks240 greenLast updated 2026-08-23How we verify →

240 verified stacks

Showing 12 across 12 app types. Every stack page links its neighbours along each axis, so any combination is a click or two from here.

AI WrapperMySQL 8 · Supabase Auth
Blog / CMSPostgres (Neon) · Better Auth
Booking / schedulingMySQL 8 · Clerk
CRMMySQL 8 · Better Auth · Resend
E-commerce storeMySQL 8 · Better Auth
Fintech ledgerPostgres (Neon) · Better Auth
Fitness trackerMySQL 8 · Supabase Auth · Resend
Forum / communityPostgres (Neon) · Better Auth
Helpdesk / supportMySQL 8 · Better Auth · Resend
IoT telemetryMySQL 8 · Better Auth
Job boardMySQL 8 · Better Auth
LMS (learning platform)MySQL 8 · Supabase Auth · Resend

What Nuxt 4 gives you

Nuxt 4 in framework mode is the one stack here with two roots. Client code lives under app/ and is what `@/` points at (Vite, Vue single-file components); server code lives under server/ and is run by Nitro, Nuxt's server engine. The database layer is server-side, so initCode writes server/lib/db.ts and the schema, record modules and webhooks land under server/db/ and server/api/ — server modules reach each other through Nuxt's `~~` rootDir alias (`~~/server/lib/db`, `~~/server/db/schema`), never through `@/`. That split earns its keep with secrets: the Resend send client belongs to ~~/server/lib/email, and nothing under app/ can import it by accident. The API layer is Nitro rather than a React-shaped route file.

server/api/webhooks/polar.post.ts is a POST endpoint; auth mounts as the catch-all server/api/auth/[...all].ts, which adapts the H3 event with toWebRequest(event) and hands the resulting web Request to the auth library's framework-agnostic handler. Nuxt auto-imports defineEventHandler and its siblings at runtime, but the emitted server files import them from h3 explicitly — one deliberate idiom trade so every handler type-checks under standalone tsc. Session gating is a Nitro server middleware at server/middleware/auth.ts. It fires on every SSR render and every API request, filters on pathname prefixes (/dashboard, /settings), performs the real auth.api.getSession() lookup, and answers with sendRedirect(event, "/sign-in", 302). Because Nitro sits in front of both the rendered page and the endpoints, that is a genuine security boundary rather than a cheap pre-render bounce.

On the client, Vue does its own thing: the auth binding exposes signIn/signUp/useSession as Vue refs, screens are .vue components under app/pages/ (sign-in.vue, dashboard/[id].vue), chrome lives in app/components/ and app/layouts/, and SPA-side guards are app/middleware/*.ts. The design system is shadcn-vue on reka-ui — a real re-port, not the React components wearing new names — and it is checked with vue-tsc, since plain tsc cannot parse an SFC.

Built for

Expose an API endpoint

A Nitro route handler under server/api/ — the file suffix carries the verb (webhooks/polar.post.ts is POST). The body is defineEventHandler, imported explicitly from h3 so the file type-checks outside Nuxt's auto-import context.

Gate SSR and API traffic in one place

server/middleware/auth.ts runs before every render and every endpoint: it matches the guarded pathname prefixes, calls auth.api.getSession with the headers from toWebRequest(event), and sendRedirects anonymous requests to /sign-in.

Reach the database from server code

import { db } from "~~/server/lib/db" and the tables from "~~/server/db/schema". `@/` is the client root (app/) and does not resolve into the Nitro tree, which is exactly why the DB layer cannot leak into a browser bundle.

Mount the auth provider's endpoints

server/api/auth/[...all].ts — a Nitro catch-all that returns auth.handler(toWebRequest(event)). The `[...all]` param absorbs every /api/auth/* sub-path the auth library routes internally, so there is one file for the whole surface.

Render a signed-in page

Vue SFCs under app/pages/ with app/layouts/dashboard.vue for the shell, reading session state from the Vue auth client (useSession as a ref) that the auth fragment writes to lib/auth-client.ts.

Why Nuxt 4, specifically

note

Client/server split: the DB client, Drizzle schema, records, and webhooks are server-side (server/). The `@/` alias is the client root (app/); server code reaches shared modules via Nuxt's `~~` rootDir alias (e.g. `~~/server/db/schema`).

note

The API layer is Nitro, Nuxt's server engine: endpoints are server/api/*.post.ts route handlers, and auth mounts as a Nitro catch-all that delegates to the auth library's framework-agnostic web handler.

note

Nuxt auto-imports components and composables at runtime, but the emitted server code imports h3 helpers (defineEventHandler, toWebRequest) EXPLICITLY — the one deliberate idiom trade so the handlers type-check under standalone tsc instead of relying on the auto-import magic.

note

Session gating runs in a Nitro server middleware (server/middleware/), which fires on every SSR and API request — the true security boundary, and a real server-side session check rather than a cookie-existence peek.

What Nuxt 4 pulls in

bun add nuxt vue