ADMN
Sign inGet started
Full-stack Nuxt 3

Preview environments for full-stack Nuxt

Your Nuxt app isn't just a frontend — Nitro is the backend too. Every pull request gets the whole thing on a managed VPS: server/api routes running, SSR rendering against a real seeded database, Redis alongside — built with nuxt build and served as a Node process behind its own HTTPS URL.

Start building See how it works
  • ✓ Nitro server routes
  • ✓ Seeded Postgres / MySQL
  • ✓ SSR against the DB
Why a frontend-only preview falls short

A full-stack Nuxt app is not a static site

Tools that "preview Nuxt" usually deploy a static frontend and stop there. But when Nitro is your backend, a meaningful preview needs the server built, a real database migrated and seeded, and SSR that actually queries it. Anything less reviews half the app.

server/api never runs

A static deploy ships the pages but not the Nitro server, so your defineEventHandler routes are dead — mutations 404 and SSR data fetches fail.

No database to render against

Without an isolated, migrated database, SSR has nothing real to fetch. Reviewers see skeletons, errors, or production data leaking into a branch.

Shared envs collide

One staging database for every open PR means a Drizzle or Prisma migration on one branch silently breaks the next. Nobody trusts what they're testing.

Nitro is the whole app

What every full-stack Nuxt preview includes

One nuxt build, one Nitro process, one origin — frontend, backend and backing services wired together on a dedicated VPS per branch.

✓
Nitro server (the backend)node .output/server/index.mjs runs server/api/* and SSR in one process — no separate API host.
✓
SSR that hits the DBServer-side useFetch/$fetch resolve to local handlers querying this environment's database.
✓
runtimeConfig per envPublic values exposed to the client, private secrets kept server-only — injected per environment.
✓
Isolated databasePostgres, MySQL or MongoDB, migrated with Drizzle/Prisma and seeded on first boot.
✓
Redis + Nitro storageBacks Nitro cache and storage drivers, sessions and any worker or scheduled task.
✓
HTTPS URL + modulesA real certificate on admn.cloud, your Nuxt modules installed, app URL wired automatically.
The build, automated

Build the server, migrate the DB, run Nitro

You declare the install, migrate and build steps once. We run them in a clean container on every push, then launch the Nitro output as a real Node server — no bespoke CI YAML, no SSH.

# on every push to the branch
npm ci
npx drizzle-kit migrate && npm run db:seed   # isolated DB, real rows
nuxt build                                    # → .output/ (Node/Nitro server)
node .output/server/index.mjs                 # server/api + SSR, one process
✓ ready https://acme-dashboard-pr-204.admn.cloud
How it works

From branch to live full-stack URL in three steps

  1. 01

    Connect the repo

    Point ADMN at your Nuxt repository and declare your install, migrate/seed and build commands plus a database template — once.

  2. 02

    Pick a branch

    Choose any branch or PR. We provision a dedicated VPS, migrate and seed the database, run nuxt build, and start the Nitro server.

  3. 03

    Share the URL

    A real full-stack HTTPS environment — server routes, SSR and database — for QA or demos. Renew the lease, or let it expire and tear down clean.

Questions

Full-stack Nuxt preview environments, answered

Are my Nitro server routes (server/api) the backend in a preview?

Yes — that is the whole point. There is no separate API service to stand up. The Node/Nitro output that `nuxt build` produces is run as a long-lived server with `node .output/server/index.mjs`, so every `server/api/*` handler and `defineEventHandler` runs exactly as it does in production. SSR pages, server routes and the rendered frontend are all served from the one Nitro process on the one HTTPS origin.

Is the database migrated and seeded with Drizzle or Prisma?

Each environment gets its own isolated database — Postgres, MySQL or MongoDB — and we run your migration step before the server starts: `drizzle-kit migrate` (or `prisma migrate deploy` / `prisma db push`) followed by your seed script. So the preview boots on a real schema with realistic rows, not an empty database. The database is dropped when the environment tears down, so no migration ever leaks into a shared box.

Does server-side rendering actually fetch from the in-environment database?

Yes. When Nuxt renders a page on the server, your `useFetch`/`$fetch` calls hit the local `server/api` handlers in the same process, which query that environment’s own database over localhost. The data you see in the preview is genuinely server-rendered against the seeded DB for that branch — not a static export and not pointed at production.

How are runtimeConfig secrets handled per environment?

Your project env template is rendered per environment. Public values land in `runtimeConfig.public` (exposed to the client), while private keys stay server-only in `runtimeConfig`, injected as env vars the Nitro process reads at boot. Database and Redis credentials point at that environment’s own services, and the public site URL is set to the generated HTTPS address.

Does auth (nuxt-auth-utils / sidebase) work with per-environment callback URLs?

It does. Because every environment has its own stable HTTPS URL on admn.cloud, we set the app URL and any OAuth callback/base env vars to match it, so session cookies and provider redirects resolve correctly. Add that URL to your provider’s allowed callbacks (or use a wildcard) and login works in the preview just like production.

Where does the database live and what happens when the PR closes?

The database runs on the same dedicated VPS as the Nitro server for that branch — isolated from every other environment. When the lease expires or the PR merges, the whole box is torn down: server, database and Redis go with it. Nothing lingers, and you never pay for an environment you forgot to clean up.

Preview your whole Nuxt app, server and all

Connect GitHub and get a full-stack Nuxt environment for every branch — Nitro built, database migrated and seeded, SSR live — then destroyed without a trace.

Start buildingSee pricing