Preview environments for the MERN stack
MongoDB, Express, React and Node — every pull request gets the whole stack on its own managed VPS: a real isolated Mongo seeded from your script, the Express API and React app built and wired, JWT auth working on a live HTTPS URL. Up in minutes, torn down clean.
- ✓ Isolated MongoDB
- ✓ Seeded from a script
- ✓ JWT on a real URL
A MERN PR isn't one app — it's a database, an API and an SPA
To actually review a MERN branch you need a Mongo with the right documents in it, the Express API running against that data, the React bundle built and pointed at the API, and auth that issues tokens for the URL you're looking at. Reproducing all four by hand for every pull request is exactly the chore nobody wants.
Mongo has no data
A fresh database is empty collections. Without seeded users and documents there's nothing to click through, and everyone seeds their local Mongo differently.
API and SPA drift apart
The React build points at localhost, or the API base is stale, so the deployed frontend talks to the wrong server — or nothing at all.
Auth breaks off-localhost
JWTs and cookies that work on localhost:3000 fall over on a shared box with no HTTPS or a mismatched domain. Login is the first thing to break.
Every letter of the stack, provisioned per branch
Four parts, one environment on a single VPS — the database, the API, the frontend and the runtime, wired together and served behind one HTTPS URL.
MongoDB
A real, isolated MongoDB per environment — not a shared cluster. The connection string is injected as MONGO_URI and the whole database is dropped on tear-down.
Express
Your Express API boots under the real Node runtime with its env wired — MONGO_URI, JWT_SECRET and the rest — so routes, middleware and auth behave like production.
React
The React app is built with Vite or CRA, its API base pointed at the environment, and served by Express or as its own service — production assets, not a dev server.
Node
One Node runtime ties it together, plus a background worker and scheduler, with Redis available for sessions, queues and cache when you need it.
A seeded Mongo, not migrations
There are no SQL migrations to run on a MERN stack — so instead of migrate we run your seed script against a fresh, isolated MongoDB on first boot. Realistic documents, every preview.
MONGO_URIWe generate the connection string and inject it, so mongoose.connect(process.env.MONGO_URI) just works.node seed.js or npm run seed; we run it on boot to insert users, an admin login and sample data.Exactly the steps you'd run by hand
You declare the install, build, seed 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 # install API + client deps npm run build # Vite/CRA → built React bundle npm run seed # node seed.js → seed the isolated Mongo node server.js # Express connects via MONGO_URI ✓ ready https://acme-dashboard-v3.admn.cloud
From branch to shareable URL in three steps
- 01
Connect the repo
Point ADMN at your MERN repository, declare your build and seed commands, and add MongoDB as the environment’s database — once.
- 02
Pick a branch
Choose any branch or PR. We provision a VPS and an isolated Mongo, build the React app, wire
MONGO_URIand run your seed script. - 03
Share the URL
A live HTTPS environment with working auth for QA, design or a client demo. Renew the lease to keep it, or let it expire and tear down clean.
MERN preview environments, answered
Do I get a real, isolated MongoDB for each environment?
Yes — Mongo is a first-class supported database, not a stub. Every preview gets its own dedicated MongoDB instance, fully isolated from every other branch and from production. We generate the connection string and inject it as MONGO_URI so your app connects to its own data, and the whole database is dropped when the environment tears down.
There are no SQL migrations — how is the database seeded?
With a seed script instead of migrations. You declare a command like `node seed.js` or `npm run seed`, and we run it on first boot against the fresh MONGO_URI. It inserts the documents your reviewers need — users, an admin login, sample records — so the preview opens on realistic data rather than empty collections. Re-provisioning re-seeds from scratch.
Does Mongoose connect automatically?
Your code connects exactly as it does locally — `mongoose.connect(process.env.MONGO_URI)`. Because we set MONGO_URI in the environment before the Express process starts, your existing connection code and Mongoose models work unchanged. No driver swap, no per-environment config in your repo.
How does the React app reach the Express API?
However your project is wired. For a monorepo where Express serves the built React bundle, everything is same-origin and the SPA just calls /api. For two separate services we set the frontend’s API base (e.g. VITE_API_URL) to the API service’s URL and apply CORS, or you keep a dev-style proxy. Either way the wiring is rendered per environment so links resolve against that preview’s own URLs.
Does JWT / session auth work on the preview URL?
Yes. Each environment runs on its own HTTPS URL on admn.cloud, and your JWT secret and auth env vars are injected per environment. Because tokens are signed and verified by the same Express app and cookies are issued for that environment’s real domain over HTTPS, login, protected routes and refresh flows behave exactly like production.
Can I run it as one service or as two?
Both. Ship a single Node service that serves the API and the built React SPA together, or run the Express API and the React frontend as two services that we provision side by side and wire to each other. You declare the build and start commands; we run them in clean containers on the same VPS.
Ship your next MERN PR with a live URL
Connect GitHub and get the whole stack per branch — an isolated Mongo seeded from your script, the API and SPA built and wired, then destroyed without a trace.