A request for /.env shouldn't render your React app

Melissa Ashford — Tue, 22 Sep 2026 01:17:49 +0000

A request for /.env doesn't need a React tree. In the latest release, vite-ssr-boost can reject it before your request hook runs.

The document guard is on by default. The SSR concurrency limit isn't.

Your hook might not run

The default document methods are GET, HEAD and POST. Other methods get 405 with an Allow header before onRequest, HTML loading or route loaders. If your hook handles CORS preflights, include OPTIONS in requestGuard.methods alongside the methods you still need. That array replaces the defaults.

Allowing a method doesn't bypass the other checks. For allowed methods, oversized targets get 414 and malformed paths get 400. With the default rules, GET requests for /.env or /random.php get a plain 404 without rendering. An unmatched /missing.xml does too; a matched resource route such as /sitemap.xml can pass.

requestGuard: false disables the new guard and its missing-page handling. This is document-handler behavior, not protection for every request reaching your server.

Choose what a missing page does

For an unmatched document such as /missing, notFound defaults to render: the existing router/render path. spa serves a client shell with 404; detected bots still take the render path under the default bot policy. A custom Response gives you a static 404 without the render pipeline.

A catch-all route counts as a match. To apply a missing-page mode there, return 'notFound' from requestGuard.decide.

cached buffers a router 404 and reuses it while the entry is retained. Concurrent misses for the same key share a render. Hits skip onRequest and the render pipeline, including loaders and admission. Don't depend on those hooks running for every missing page.

The default key is shared across missing paths, including the first rendered URL and hydration data. Cold renders use GET without the original body, with Cookie and Authorization removed before the request hook. The URL, other headers and application state can still affect the result. Keep private state out of shared HTML; choose keys for public variations such as locale. If the page depends on a session, keep ordinary rendering instead.

A configured CSP nonce disables this cache and falls back to ordinary rendering. Failed renders and non-404 results aren't retained. Overloads and server failures keep their error status; a request-hook bypass keeps its own response. The default private, no-store header on 404 documents can be overridden by document header rules. This HTML cache is separate from browser or CDN caching.

Limit renders, not every bit of server work

Admission is opt-in and handler-local, not a cluster-wide cap.

Set a positive safe integer in admission.maxConcurrency, or a valid SSR_MAX_CONCURRENCY. The environment value wins and is read at handler/entry creation. No limit is enabled by default.

A slot is taken after request initialization and the SSR/SPA decision, before route loaders. At capacity the default response is 503 with Retry-After and private, no-store. There is no admission queue. The rejected request's loaders don't run, but onRequest and HTML loading have already happened.

With admission.overload: 'spa', requests that reach a full admission controller get a 200 shell for humans and 503 for detected bots. That isn't the missing-page SPA mode, whose shell uses 404. A custom overload Response is sent as 503.

On normal streamed completion, the slot stays occupied until the final Fetch response stream is consumed, not merely until React produces a shell. This doesn't mean the last byte has reached the browser. Aborts and errors can release it earlier; redirects and bodyless responses have their own release paths. Ordinary SPA shells and cached 404 hits don't occupy a slot.

Before deploying, test a preflight that must reach your hook. Check that missing URLs don't share private data. For admission, keep one response stream open and send another SSR request at capacity.

Configuration reference, guard and 404 tests, admission tests.

We deleted Vite from our production server

Melissa Ashford — Mon, 21 Sep 2026 16:59:28 +0000

vite-ssr-boost is an SSR framework built on Vite. Its production server used to start this way: load Vite, resolve vite.config, build the full CLI command tree, then serve the first request. None of that is needed to serve HTML.

In 8.4.x we cut it out. The numbers below are our own runs on a pinned template, M3 Pro, installed through npm.

What the production start used to do:

load Vite and evaluate vite.config
build the whole Commander command tree just to parse the flags of start
spin up the source analysis services that only dev mode uses

What it does now:

ssr-boost build writes a versioned build/server/ssr-boost.json with the resolved serving settings. Production reads that file and never evaluates the Vite config.
ssr-boost start parses its flags with Node's own parser. Every other command loads on demand, keyboard shortcuts load only when there is a TTY.
An import hook watches the serving path. It rejects vite, rolldown, rollup, commander, diff, parse5, semver, json5 and the babel packages, and it also rejects our own dev-only code: the cli commands, the build, manifest and route parsing services, the plugins. That is the part that keeps it honest. The hook catches accidental imports before they reach production.

What it bought:

cold start 354 ms to 249 ms. A plain Express server with renderToPipeableStream is 171 ms on the same machine.
RSS 142 MiB to 100 MiB. Same plain Express baseline: 69 MiB.

Then the per-request path. React's native Web stream on React 19.2+, the production shell cached instead of rebuilt, boundary scanning only while data frames can still arrive, a plain state script for routes without router data, static dispatch by built prefixes so there is no filesystem lookup per HTML request, the header queued at shell readiness, compression flushed before drain.

One more part, the one I would copy even if you skip everything else. Acceptance measures a plain Express baseline in the same run and fails the build if cold start goes past 2x that baseline. RSS has its own ceiling in the same file. So if a later change drags the start path back toward Vite, CI fails on a number instead of on someone's memory.

We also keep a public benchmark repo that runs five SSR frameworks weekly in CI and stores the raw json for every cell: https://github.com/Lomray-Software/ssr-benchmarks. Read it yourself, our claims here are about our own before and after, not about anyone else's framework.

If you run SSR on Vite, go look at what your production process loads before it answers anything. Count the modules, or run start under --cpu-prof.

We were loading a build tool in production. It cost about 100 ms and 40 MiB per process.

Code: https://github.com/Lomray-Software/vite-ssr-boost
Docs: https://lomray-software.github.io/vite-ssr-boost/
The PRs with the full detail: https://github.com/Lomray-Software/vite-ssr-boost/pull/53, https://github.com/Lomray-Software/vite-ssr-boost/pull/54, https://github.com/Lomray-Software/vite-ssr-boost/pull/55

DEV Community: Melissa Ashford

A request for /.env shouldn't render your React app

Your hook might not run

Choose what a missing page does

Limit renders, not every bit of server work

We deleted Vite from our production server