{"id":407,"date":"2026-03-09T18:20:33","date_gmt":"2026-03-09T18:20:33","guid":{"rendered":"https:\/\/blog.rebalai.com\/en\/2026\/03\/09\/deno-20-in-production-2026-migration-from-nodejs-a\/"},"modified":"2026-03-18T22:00:05","modified_gmt":"2026-03-18T22:00:05","slug":"deno-20-in-production-2026-migration-from-nodejs-a","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/en\/2026\/03\/09\/deno-20-in-production-2026-migration-from-nodejs-a\/","title":{"rendered":"Deno 2.0 in Production: Six Months of Migration From Node.js and What Actually Changed"},"content":{"rendered":"

I resisted Deno for years. Partly stubbornness, mostly because the original pitch \u2014 “what if Node but without npm” \u2014 felt like solving the wrong problem when you have a working product and a team that knows the Node ecosystem cold. Then Deno 2.0 dropped in October 2024 with full npm compatibility, and one of my teammates (Priya, our resident runtime nerd) kept saying “no seriously, look at the<\/a> tooling story.” I gave in.<\/p>\n

We’re a three-person backend team running a Node\/TypeScript API that handles event processing for a SaaS product. Not huge \u2014 around 800 req\/s peak, PostgreSQL backend, a handful of third-party integrations. The kind of service that’s boring by design. I started the migration in September 2025 on a non-critical service as a proving ground, then moved one of our production APIs to Deno 2.2.x in January. Here’s what I learned<\/a>.<\/p>\n

What “Node.js Compatible” Means in Practice (It’s Not Magic)<\/h2>\n

The headline feature of Deno 2.0 was npm compatibility via the npm:<\/code> specifier, and it works better than I expected \u2014 with a few important asterisks.<\/p>\n

Most of your npm dependencies just… work. Express, Fastify, zod, axios, date-fns, jose \u2014 all loaded fine. You drop a deno.json<\/code> in the<\/a> root and reference them:<\/p>\n

\/\/ deno.json\n{\n  "imports": {\n    "express": "npm:express@^4.21.0",\n    "@\/": ".\/src\/"\n  },\n  "tasks": {\n    "dev": "deno run --allow-net --allow-read --allow-env src\/main.ts",\n    "test": "deno test --allow-net --allow-env"\n  }\n}\n<\/code><\/pre>\n
No package.json<\/code>. No separate tsconfig.json<\/code>. TypeScript works out of the box \u2014 Deno treats .ts<\/code> files as a first-class citizen, so you skip the whole ts-node<\/code> or tsx<\/code> setup dance. For a greenfield project this feels obvious. Migrating an existing codebase, you carry two setups for a while, which is annoying but manageable.<\/p>\n
Where it gets complicated: native addons. We use a library with some native C++ bindings, and that required --allow-all<\/code> plus some creative workarounds. Deno 2.x can handle a node_modules<\/code> directory being present (you can run deno install<\/code> and it’ll populate one), but native addons are still an edge case that isn’t fully ironed out. I ended up keeping that particular integration on a small Node sidecar. Not ideal, but the blast radius was small.<\/p>\n
Prisma was the other thing. By early 2026 the Deno-Prisma story has improved considerably compared to 2024 \u2014 Prisma 6.x has much better first-class support \u2014 but there were edge cases around the query engine binary that took me an afternoon to debug. The GitHub issue tracker (prisma\/prisma #24218, if you want to go spelunking) has the painful details.<\/p>\n
If your dependency list is mostly pure-JS\/TS packages, the migration is low-friction. If you have native addons or heavy meta-frameworks, scope that work separately before you commit.<\/p>\n
The Tooling Story Is the Real Selling Point<\/h2>\n
I’ve written probably a dozen ESLint configs in my life. Each one slightly different. Each one with at least one person on the team who disagrees with the semicolon rule. Deno ships with a formatter (deno fmt<\/code>) and a linter (deno lint<\/code>) that are opinionated, fast, and require zero configuration. You just run them. No eslint.config.js<\/code>, no .prettierrc<\/code>, no argument about whether trailing commas go after the last function parameter.<\/p>\n
The test runner is similarly no-ceremony:<\/p>\n
\/\/ handlers\/health_test.ts\nimport { assertEquals } from "jsr:@std\/assert";\nimport { createApp } from "..\/src\/app.ts";\n\nDeno.test("GET \/health returns 200", async () => {\n  const app = createApp();\n  const req = new Request("http:\/\/localhost\/health");\n  const res = await app.fetch(req);\n  \/\/ No test framework config, no jest.config.ts, no separate setup file\n  assertEquals(res.status, 200);\n});\n<\/code><\/pre>\n
deno test<\/code> picks that up automatically. For a small team where everyone’s already stretched thin, removing that category of tooling toil mattered more than I expected.<\/p>\n
deno compile<\/code> is underrated for deployment. We can now ship a single self-contained binary of one of our smaller services, which simplified our Docker setup considerably. The binary is larger than I’d like \u2014 roughly 80MB for a small API \u2014 but cold starts are nonexistent and the deployment story is much cleaner.<\/p>\n
I know the permissions model is the first thing people push back on. I was annoyed by it initially \u2014 --allow-net<\/code> and --allow-read<\/code> and --allow-env<\/code> feel like ceremony when you’re trying to get something running fast. But I pushed a config change on a Friday afternoon that accidentally let a dependency try to write to \/tmp<\/code> in a way we hadn’t expected, and the permission system caught it before it reached prod. You get a stack trace pointing exactly to where the filesystem access was attempted. In Node you’d have gotten nothing, until something went wrong downstream. I’m a convert.<\/p>\n
The Night Something Actually Broke in Production<\/h2>\n
Most migration writeups skip this part. Here it is.<\/p>\n
We had a memory leak. Not from our code \u2014 from a combination of our event loop handling and a third-party WebSocket library that had slightly different behavior under Deno’s runtime than under Node. The leak was slow enough that it took<\/a> about six hours of production<\/a> traffic to manifest, which meant we caught it around 2am on a Tuesday. Not fun.<\/p>\n
The root cause: Deno uses Web-standard APIs wherever possible. WebSocket<\/code> in Deno behaves according to the browser spec, which is great for consistency, but some npm WebSocket libraries have code paths that assume Node’s net<\/code>\/stream<\/code> internals and fall back to different \u2014 in this case, leaky \u2014 behavior when those aren’t present. The library in question was ws@8.x<\/code>, and the fix was switching to Deno’s native WebSocket API, which meant rewriting a chunk of our connection management layer.<\/p>\n
What surprised me \u2014 and I thought I understood the compatibility layer well by that point \u2014 was how hard it was to spot in the<\/a> heap snapshots. The leak showed up in<\/a> what looked like native code, not in anything we’d written. I spent several hours convinced the problem was somewhere completely different before Priya ran a targeted reproduction script that isolated it.<\/p>\n
I’m not 100% sure this would have surfaced the same way if we’d been on Deno.serve()<\/code> from the start rather than routing through Express. My hunch is yes, because the underlying WebSocket handling was in a shared module. But the failure mode was confusing enough that I’m not confident.<\/p>\n
What I’d do differently: before migrating, audit every package that touches network I\/O or streams, and specifically check whether there are open issues about Deno compatibility. The npm compatibility layer is solid. It is not a guarantee.<\/p>\n
Performance Reality Check \u2014 My Numbers, Not the Marketing Benchmarks<\/h2>\n
Every runtime publishes benchmarks showing itself winning. Here’s what I actually<\/a> saw on our hardware \u2014 a pair of AWS c6g.xlarge instances running ARM.<\/p>\n
For a basic JSON API endpoint (fetch from Postgres, serialize, return):<\/p>\n