Deno
The Deno adapter wraps Deno.serve — the stable, modern entry point that replaced the old Deno.serveHttp. Graceful shutdown uses an AbortController, which is the pattern Deno itself recommends.
When to choose Deno
- You want a web-standard runtime with TypeScript built in and no transpile step.
- You deploy to Deno Deploy, or to a container running the official Deno image.
- You like Deno's permissions model and don't need the full npm ecosystem.
Scaffold
The deno-basic template ships a Deno-native server with a deno.json import map, watch-mode dev, and deno test.
Install
@daloyjs/core is published to npm. Deno can consume it directly via the npm:specifier — this is the same pattern used by the official deno-basic scaffolder template.
Minimal server
Run it
Deploy to Deno Deploy
Deno Deploy reads the entry script directly. Point your project at src/server.ts; the same file you run locally is what runs in production.
Dockerfile
Gotchas
- Don't use
Deno.serveHttp— it's deprecated. The DaloyJS adapter usesDeno.serveexclusively. - On Deno Deploy you don't get
SIGTERM; the platform manages shutdown. TheAbortControllerwiring above is for self-hosted Deno only. - Use
--allow-net(and others) explicitly — Deno's default-deny permissions are the point.
See also
- Adapters overview
- Netlify Edge Functions — also Deno-based.