.env.
Add .env / .env.example / .gitignore for deeper checks (optional)
The Deployment Readiness Checker scores a Node.js project for production. Paste your package.json to start, then add your .env, .env.example and .gitignore for deeper checks. It detects your framework, gives context-aware advice such as where to add a health-check endpoint, and flags leaked secrets by where they appear — all in your browser, with nothing uploaded and no network calls.
How the score works
The score answers one question — will this deploy and stay up? — so only findings that affect that are counted. Every check is one of three tiers:
- ❌ High — breaks or endangers the deploy: no
startscript, missingengines.node, a committed secret, a.envthat isn't gitignored. - ⚠️ Medium — a conditional real risk: no
buildscript when a compiler/bundler is present, ortypeunset when the package looks like ESM. - ℹ️ Info — hygiene and nice-to-haves (
license,packageManager,private,lint, tidy metadata). Shown as advice, never counted in the score, so tidy metadata can't inflate — or drag down — how deploy-ready you are.
Only High and Medium checks carry points. A category's budget is just the scored checks that actually ran against what you pasted, so anything you skip is not checked, never a zero. Your score is points earned ÷ points available, out of 100, graded A ≥ 90, B ≥ 75, C ≥ 60, D ≥ 45, otherwise F. The full rubric is public:
| Category | Scored checks (points) | Advisory (info, unscored) |
|---|---|---|
| Scripts | start (12, high) · build (6, med — only when a compiler/bundler is present) |
real test, lint |
| Configuration | engines.node (8, high) · name+version (4, high) · type (4, med — only when ESM is detected) · required var set (5, med) |
packageManager, private |
| Security | .gitignore covers .env (10, high) · node_modules (4, med) · no committed secrets (8 each, high) · no shipped placeholders (2, med) · no duplicate/malformed env lines (3, med) |
other .gitignore entries, dev tool in prod deps, dotenv note |
| Documentation | advisory only — unscored | license, repository, description, author, every .env key documented |
| Docker | advisory | deep checks in the Docker Image Optimizer |
| CI | advisory | GitHub Actions inspector planned |
Where each category comes from: Scripts and Configuration are read from your package.json; Security combines your .gitignore, .env/.env.example and dependency signals; Documentation, Docker and CI are advisory — Docker links out to the Docker Image Optimizer for deep analysis. The reasoning behind every check is in the pillar guide, The Node.js Production Readiness Checklist (2026).
Framework-aware health-check advice
After parsing your dependencies the tool identifies your framework and points you at the highest-value fix — usually the health-check endpoint that load balancers and orchestrators poll before routing traffic:
- Express → add a
GET /healthroute that returns 200 OK. - NestJS → use the official
@nestjs/terminusmodule for readiness/liveness endpoints. - Next.js → consider
output: "standalone"for a smaller, self-contained deploy. - Vite → it builds a static bundle that needs a static host or CDN.
Copy-paste code for each framework is in Adding a Health Check Endpoint: Express, NestJS, and Next.js — return 200 when healthy, 503 when a dependency is down.
Why secrets are scored by context, not blanket-flagged
A .env file is supposed to hold real secrets — that is its whole job. A tool that flags every one of them trains you to ignore it. So this checker only escalates a secret-shaped value to high severity where it is genuinely exposable: in a committed .env.example, or in a .env that your pasted .gitignore does not ignore. Paste your .gitignore alongside your .env to get the accurate verdict. For safely sharing logs that contain secrets, use the Log Redactor; for the exact .env syntax rules, see the .env file format guide.
Frequently Asked Questions
Is my package.json or .env sent to a server?
No. All parsing and analysis run entirely in your browser with JavaScript. Nothing you paste — including a real .env file — is ever uploaded or transmitted. This version makes no network calls at all.
What does the Deployment Readiness Checker check?
It inspects your package.json (start/build/test/lint scripts, engines.node, type, packageManager, private, license, repository and other metadata), detects your framework (Express, NestJS, Next.js, Vite) to give context-aware health-check advice, and — when you paste them — analyses your .env / .env.example for secret-shaped values, placeholders, duplicate keys and documentation drift, plus your .gitignore for the entries that matter most before deploying.
How is the deployment score calculated?
Each check belongs to a category (Configuration, Scripts, Security, Documentation, Docker, CI) and carries a fixed point value. A category's budget is the sum of the checks that actually ran, so an input you did not paste is marked "not checked" rather than scored as zero. The overall score is the total points earned divided by the total available across the categories you provided, expressed out of 100 with an A–F grade. The full rubric is published on this page.
Why does a secret in my .env not always fail the check?
A real .env file is supposed to contain secrets — flagging every one would be noise. The tool treats a secret-shaped value as high severity only where it is actually risky: in a committed .env.example, or in a .env that your pasted .gitignore does not ignore. A secret in a properly gitignored .env is reported as an expected, informational note, not a failure.
Does it check whether my dependencies are outdated?
Not in this version. An "are my dependencies outdated or deprecated" check needs live registry data, which would mean a network call. To keep the tool 100% offline and private, that check is deferred. The dependency checks it does run — dev tools left in production dependencies, and a dotenv advisory — are all offline.
Does it validate a Dockerfile?
This checker focuses on your application manifest and configuration. For deep Dockerfile analysis — base-image pinning, multi-stage builds, layer caching, non-root USER, apt/apk cleanup — use the dedicated Docker Image Optimizer, which this tool links to from its Docker category.
What does "engines.node" do and why does it matter?
The engines.node field declares which Node.js versions your app supports. Without it, a host is free to run your code on whatever Node version it defaults to, which is a common cause of "works on my machine, crashes in production" failures. Pinning a range such as >=20 <21 and matching it to your host removes that class of bug.
Why should an application set private: true?
An application is not meant to be published to the npm registry. Setting "private": true makes npm refuse to publish it, so a stray npm publish can't accidentally push your app — and any secrets bundled with it — to the public registry. Libraries you do intend to publish are the exception.
Can I paste only a .env file?
Yes. Every input is independent — paste only a .env (and optionally a .env.example and .gitignore) to run just the environment-variable checks. Categories with no matching input are shown as "not checked" and are excluded from the score, so the result reflects only what you actually provided.
Last updated: August 2026