A development server belongs on a laptop – not on the internet. Yet a surprising number of sites run live in dev mode because someone started npm run dev instead of a real build. That's not a cosmetic problem; it's an open door. Here's how to spot it – on your own site too.
Why it happens
When vibe coding, the instructions often end at „start the dev server, done". That very command then ends up in the deploy or container start – instead of next build + next start, or vite build + serving statically. The site looks identical but behaves completely differently.
How to spot it from the outside
- An open hot-module-reload WebSocket (e.g. to
/_next/webpack-hmror a Vite client). - Source maps are reachable – the full, unminified source is exposed.
- Verbose error pages with stack traces, file paths and framework internals instead of a lean error message.
- Tell-tale headers or dev-only endpoints that don't exist in a production build.
Why it's dangerous
Open source maps and stack traces reveal structure, libraries used and often paths to sensitive endpoints to attackers – half the recon is done for them. On top of that come missing optimisations: the dev server is slow, can't handle load and sometimes disables security defaults.
How to deploy correctly
Always produce a real production build and serve that: for Next.js next build followed by next start (or a static export), for Vite vite build and the dist/ folder via a real web server. Set NODE_ENV=production. When in doubt, scan from the outside.
Check in 10 seconds
The Vibe Check recognises a live dev server by exactly these signals and tells you immediately whether your site runs in the wrong mode.
Scan your site in 10 seconds →