Deno

Confirm your Deno version

• Why this matters: @nextrush/adapter-deno targets Deno's stable Deno.serve() surface.

deno --version
# needs to read deno 2.x.x or higher

If Deno isn't installed yet, follow the install instructions before continuing.

Install NextRush and the Deno adapter

• Why this matters: like Bun, the nextrush meta-package does not bundle a runtime adapter — you add @nextrush/adapter-deno alongside it.

Do: Deno resolves npm packages directly with the npm: specifier — no separate lockfile step needed for a quick script:

import { createApp, createRouter } from 'npm:nextrush';
import { listen } from 'npm:@nextrush/adapter-deno';

Or pin the same imports in deno.json so every file in the project resolves them the same way:

{
  "imports": {
    "nextrush": "npm:nextrush",
    "@nextrush/adapter-deno": "npm:@nextrush/adapter-deno"
  }
}

Behind the scenes:

• createApp and createRouter still come from nextrush — runtime-independent
• listen, serve, and createHandler come from @nextrush/adapter-deno — the meta-package's listen is wired to @nextrush/adapter-node specifically
• Once imports are in deno.json, every file can write plain import { createApp } from 'nextrush' — the import map resolves the npm: specifier

Run a hello-world server

Create server.ts:

import { createApp, createRouter } from 'nextrush';
import { listen } from '@nextrush/adapter-deno';

const app = createApp();
const router = createRouter();

router.get('/', (ctx) => {
  ctx.json({ runtime: 'deno', status: 'ok' });
});

app.route('/', router);
await listen(app, 8080);

Run it — Deno requires an explicit network permission:

deno run --allow-net server.ts

✅Expected result — curl http://localhost:8080/ returns {"runtime": "deno", "status": "ok"}

Behind the scenes:

• listen(app, 8080) from @nextrush/adapter-deno calls Deno.serve() directly
• Each request goes to NextRush's router through the same Context API Node and Bun use
• ctx.runtime reads 'deno' because the adapter, not your handler, decides that value

Why Deno's permissions matter

Your server is now running. Before moving on, it's worth understanding what Deno's permission model changes — and what stays the same.

Same: the Context API, createApp, createRouter, route registration, and middleware all behave identically to Node and Bun. Nothing in your route handler is Deno-specific.

Different: the --allow-* flags are a property of the Deno process, not something @nextrush/adapter-deno adds or works around. The adapter has no permission-checking code — it calls Deno.serve() the same way your own code would, and Deno's runtime enforces the sandbox before the adapter ever runs. A missing permission fails at the OS/runtime boundary, not inside NextRush.

One adapter-level behavior: @nextrush/adapter-deno adds its own request timeout (Promise.race-based, since Deno.serve() has no built-in per-request timeout) — defaults to 30 seconds, matching Node and Bun.