TECHDEV · Flagship · Open-source tool

runverdict

Measure your app across the JavaScript runtimes installed on your machine and get an upgrade verdict with reasons — not a headline benchmark measured on someone else's app on someone else's machine.

View on GitHub →Read the article →

TypeScript · CLI · MIT · Node 20+ · Zero runtime dependencies · No account, no network beyond localhost, no data leaves the machine. It never downloads a runtime.

The problem it answers

Node 26 entered Active LTS on 2026-10-28. Teams on Node 20 and older run a runtime with no security fixes. Teams on Node 22 and 24 must plan a move. Teams choosing between Node and Bun have only headline benchmarks. No headline tool answers, for your app on your machine: does it load on the target runtime, how fast is it there, and should you upgrade — with reasons, not a headline.

runverdict measures only runtimes already installed and reports the rest as not-installed. It never downloads a runtime.

What it measures, per runtime

Measurement	How
Version and EOL status	From a built-in schedule table (Node only; see below)
Load check	The entry is spawned; a failure records the stderr tail verbatim — which is what names a broken native addon or a missing module
Startup timing	Median of 5 spawns, spawn to first stdout line
HTTP workload	Built-in `http` client only: requests/second, p50/p95 latency, and peak RSS, using the same workload, in the same order, on the same machine for every runtime

The repository ships a zero-dependency sample app with /health and /json endpoints (examples/sample-app.js). It listens on process.env.PORT.

Verdicts

Verdict	Rule	Exit code
BLOCKED	The target runtime fails the load check, or no runtime produced a measurement. Reasons name the failing runtime and its stderr tail.	1
UPGRADE-READY	The current runtime is EOL or Maintenance, the target runtime loads, and its req/s is not worse than the current runtime's by more than 10%.	0
STAY	Otherwise, with reasons and numbers. A measured regression beyond 10% is a reason to stay, stated with both numbers.	0

Definitions: the current runtime is the first runtime in --runtimes order with a measurement; the target is the best-performing other measured runtime, if any. With a single measured runtime there is no target to compare against, so the verdict is STAY. Exit code 1 also applies when no usable runtime measurement exists; exit code 2 is a usage error. The JSON manifest carries runtime versions, EOL statuses, every measured number, run counts, the verdict with reasons, and the machine note: "single-machine measurement, not a general claim".

Built-in Node EOL schedule

Node major	Status	EOL
20	EOL	2026-04-30
22	Maintenance	2027-04-30
24	Maintenance	2028-04-30
26	Active LTS	2029-04-30

An unknown Node major is reported as UNKNOWN, never guessed. Bun has no LTS/EOL schedule: runverdict reports the Bun version only and never invents an EOL date for Bun. Deno is explicitly out of scope in v1: it is not detected, and passing --runtimes deno is an error, not a silent omission.

Use it

# Install in 3 steps (requires Node >= 20), then link the binary once for local use
git clone https://github.com/techdevfun/runverdict
cd runverdict
npm install
npm link

# Runnable example
runverdict runtimes
runverdict measure --entry examples/sample-app.js --url /json --runtimes node,bun --duration 5 --connections 20 --json out.json
runverdict --version

Commands copied exactly from the runverdict README (package.json v0.1.0). --duration defaults to 10 seconds and --connections defaults to 20. The README does not state an npm registry install, so none is claimed here: installation is the clone + npm install + npm link flow above. A verbatim transcript of a real demo run on the build machine is in examples/demo-transcript.txt in the repository; re-running the commands produces new numbers, because the numbers are measurements.

Measured numbers (README: method, not fixed figures)

The README gives no fixed benchmark numbers — and none are claimed here. Every number on a run is a measurement from that run, on that machine, for that app and workload.
Startup timing is the median of 5 spawns, spawn to first stdout line.
The HTTP workload reports requests/second, p50/p95 latency, and peak RSS, with the same workload, in the same order, on the same machine for every runtime.
The verdict threshold is 10%: a target within 10% of the current runtime's req/s can be UPGRADE-READY (when the other conditions hold); a measured regression beyond 10% is a reason to STAY, stated with both numbers.
Defaults: --duration 10 seconds, --connections 20.

What this is NOT — and where rivals beat us

It does not profile. For flame graphs and event-loop diagnosis, clinic.js beats us. It does not do statistical outlier modeling; hyperfine beats us. It does not offer HTTP load options; autocannon beats us. This tool does the upgrade decision, which none of them do.
A load check proves the entry loads, not full compatibility. A passing load check is not a guarantee the app behaves identically on another runtime.
Numbers are this machine's. A faster runtime here is not a claim about any other machine, app, or workload.

Roadmap (README): additional report formats for the JSON manifest; a documented evaluation of a third runtime inventory entry, only if it can be measured with the same load, startup, and workload checks; longer, configurable workload shapes, without changing the deterministic verdict rules.

Source + README on GitHub → · Report an issue → · ask@techdev.fun

Limits

It never downloads runtimes, never touches the network beyond localhost, and never reads files outside the app directory except the runtime binaries.
It never downloads a runtime: it measures only runtimes already installed and reports the rest as not-installed.
Deno is explicitly out of scope in v1 (see the EOL section above).

License

MIT. See LICENSE in the repository.

Have a say

Vote for this tool, suggest a feature, or discuss it with other operators on the community board.