A secure, standards-based server runtime.
V8-based ECMAScript runtime for the server. WinterTC-compliant, capability secured.
import { serve } from "runtime:http";
const server = serve({ port: 8080 }, (req) => {
return new Response("👋 Hello from ESRun!");
});
const { hostname, port } = await server.addr;
console.log(`listening on http://${hostname}:${port}`);
Benchmarks
Why ES-Runtime?
Store
Embedded SQLite plus first-party Postgres, MySQL/MariaDB, MongoDB (beta), Redis, and Valkey.
Develop
Tests with DOM parity, real-browser runs, watch, HMR, plugins.
Run on
A Rust core around V8, scripted in JavaScript and TypeScript.
Built-in Utils
SMTP mail, archive handling, password-grade hashing, two-factor codes, cookies, CSRF tokens, and webhooks.
Choosing a runtime? How esrun compares to Node.js, Bun and Deno →
State without infrastructure
Durable workers: addressable state that outlives the process.
One call at a time, per worker
Calls to one worker queue and run in order, so two customers cannot both take the last item. No lock to take, no row to contend for.
Answered once it is on disk
A result is released only after the writes behind it have committed. A crash is a call that never returned, never one that returned a lie.
Timers that outlive the process
An alarm is stored beside the state and runs after a restart: retries, abandoned carts, a nightly roll-up, without a scheduler service.
Nothing else to run
State lives in embedded SQLite, one file per worker, under the same read and write grants as everything else. No Redis, no queue, no database server.
Killed with SIGKILL under load, the example shop loses no order it acknowledged.
Benchmarks
Plaintext hello-world over loopback, driven by oha at 100 connections — best of three runs. Elysia is measured on the esdev bundle every runtime serves (esrun is ESM-only), and Node serves both frameworks through the same @hono/node-server glue, so the delta is route handling, not the adapter. How it is measured →
Deny by default
A run reaches what the command line named, and nothing else.
Eleven capabilities: read, write, imports, net, listen, env, run, signals, workers, diagnostics, diagnostics-detail. The gate is the op, not the import.
Two binaries.
esrun runs your service and nothing else — no watcher, no debugger port, no transform. That narrowness is what a capability flag is worth.
esdev pays for it on your machine: same runtime, same flags, plus the toolchain to get there.
In esdev, not in production
TypeScript & JSX CommonJS (converted by esdev) Bundler Test runner Watch mode Debugger Permission discovery
Not goals at all
Node.js compatibility CommonJS at runtime Package installer Linter / formatter FFI Native addons Remote module imports SharedWorker / data: worker URLs
Ship a runtime you can trust.
Start building
Install both binaries with one command, and run your first module. Standards-based, fast, ESM-only.
Ship it locked down
Nothing is granted unless the command line says so. Build the deploy line that states exactly what your service may touch.