ADMN
Sign inGet started
Node API + React

Preview environments for Node + React

The classic two-service JS app — an Express, Fastify or NestJS API and a Vite-built React SPA over Postgres — gets a real, full-stack environment for every pull request. Both apps built, the database migrated and seeded, Redis and a worker running, behind one HTTPS URL.

Start building See how it works
  • ✓ Express / Fastify / Nest
  • ✓ Vite React build
  • ✓ Seeded Postgres + Redis
Why it's painful today

A Node + React PR is two builds, a DB and a worker

To review a branch you have to install and build both apps, run the migrations and seed the database, point the SPA at the right API URL with CORS to match, and bring up a worker on Redis. That is a lot of fiddly wiring to reproduce by hand for every pull request.

The SPA points at the wrong API

A reviewer builds the React app with a stale VITE_API_URL, or hits CORS errors because the API never allow-listed the preview host. The frontend looks broken when only the wiring is.

Migrations drift on shared staging

Two open PRs, one Postgres database. A prisma migrate from one branch reshapes the schema the other depends on, and the seed data no longer matches either.

The worker isn't there

Locally the BullMQ worker is "the other terminal you forgot to start". Jobs queue and never run, so async features look dead in review for no real reason.

One environment, fully wired

What every Node + React preview includes

Each branch boots a complete stack on its own VPS — both apps built from your own commands, the database and Redis provisioned, the SPA and API wired to each other.

✓
Node API, your frameworkExpress, Fastify, Koa, Hono or NestJS — npm ci, TypeScript compiled, booted from one start command.
✓
Vite React buildnpm run build emits the hashed dist bundle — production assets, not a dev server.
✓
Monorepo or two servicesWorkspaces, Turborepo or Nx, or two deploys side by side — your topology, wired together.
✓
Isolated PostgresPer environment, with Prisma / Knex / Drizzle migrate + your seed script on boot. MySQL optional.
✓
Redis + BullMQ workerA queue worker process and scheduler running on Redis, same as production.
✓
HTTPS URL + env wiringVITE_API_URL and CORS set automatically — same-origin or two services.
The build, automated

Exactly the steps you'd run by hand

You declare the install, build, migrate and start commands once. We run them in a clean container on every push — no bespoke CI YAML, no SSH.

# on every push to the branch
npm ci
npm run build                        # api (tsc) + web (vite) workspaces
npx prisma migrate deploy && npx prisma db seed   # isolated DB, real data
node dist/server.js                  # API serves built SPA + /api
✓ ready https://acme-billing-v2.admn.cloud
How it works

From branch to shareable URL in three steps

  1. 01

    Connect the repo

    Point ADMN at your Node + React repo (or two repos), declare your install, build, migrate and start commands and a database template — once.

  2. 02

    Pick a branch

    Choose any branch or PR. We provision a dedicated VPS, build both apps, migrate and seed Postgres, start Redis and the BullMQ worker, and wire the SPA to the API.

  3. 03

    Share the URL

    A real HTTPS environment for QA, design review or a client demo. Renew the lease to keep it, or let it expire and tear down clean.

Questions

Node + React preview environments, answered

Monorepo or two separate services?

Either. If your API and React app live in one monorepo (npm/pnpm/yarn workspaces, Turborepo or Nx), we install once and build both packages. If they are two repos or two deploys, we provision them side by side on the same environment and wire them together. You declare the build commands; the topology is yours.

Which database — and do migrations and seeds run?

Postgres is the default; MySQL is a one-line swap. Each environment gets its own isolated database, and we run your migration tool on boot — `prisma migrate deploy`, a Knex `migrate:latest`, or `drizzle-kit migrate` — followed by your seed script. The preview opens on realistic data, and tear-down drops the database with it. (Need MongoDB instead? See our MERN page.)

How does the React SPA find the API?

Two supported patterns. Served same-origin, your API serves the built SPA (the `dist` folder) and relative `/api` calls just work — no CORS. Served as two services, we inject the API origin as a build-time `VITE_API_URL` and set the matching CORS allow-list on the API to the environment’s own HTTPS host, so the SPA always talks to the right backend.

Does the TypeScript build step run?

Yes. The API is compiled with `tsc` (or your bundler — esbuild, tsup, swc) and the React app is built with Vite, both in a clean container on every push. We run the actual production build, so type errors and broken bundles surface in the preview rather than after merge.

Can I run a BullMQ worker and the scheduler?

Yes. Redis is provisioned alongside the database, so a BullMQ worker process and repeatable/cron jobs run in the same environment as the API. Background jobs, queues and scheduled tasks behave the way they do in production instead of being stubbed out.

Express, Fastify or NestJS — does the framework matter?

No. The page targets a Node HTTP server, not a specific framework, so Express, Fastify, Koa, Hono or NestJS all work the same way: install, build, migrate, then start your entry point (e.g. `node dist/server.js` or `nest start`). If it boots from a single command, it runs here.

Ship your next Node + React PR with a live URL

Connect GitHub and get a full-stack preview environment for every branch — both apps built, the database migrated and seeded, the worker running, then destroyed without a trace.

Start buildingSee pricing