How to list Deno and Cloudflare Workers on a CV

What does the Cloudflare–Deno deal change about how you list Deno?

Nothing about the acquisition devalues your Deno experience; it changes the story you tell around it. On 9 October 2026 Cloudflare announced it was acquiring Deno, and the whole runtime team — including Node.js creator Ryan Dahl and co-founder Bert Belder — moved across. The runtime itself gets roughly one more year of maintenance releases, bug fixes and security patches, after which official development stops. It stays open source. Deno Deploy, the hosted service, winds down inside six months, with paying customers migrated onto Cloudflare Workers. So the honest framing on a CV in late 2026 isn't "Deno developer." It's "built and shipped on Deno, now migrating to the Workers model" — which is exactly the work hiring teams are staffing for right now.

The reason Cloudflare paid for a runtime it already competed with sits in a Rust binary called celld, which the Deno team shipped in August. It lets you run Workers and Durable Objects on your own servers, and Dahl and Belder are now leading the work to fold it into workerd, Cloudflare's open-source Workers runtime. The stated goal is making self-hosted workerd a first-class way to build apps. Read that as a hiring signal: the "Workers programming model" is being pushed as a general way to write servers, not just one vendor's product. Job ads will increasingly describe that model without naming the vendor, and your CV has to match both the branded term and the generic one.

Practically, that means you keep Deno on the page and give it a timeframe. Recruiters' saved searches move slowly; plenty will still be matching on "Deno" eighteen months from now, and plenty of teams genuinely run it in production today with no plan to rip it out before the maintenance window closes. Deleting it costs you matches and gains you nothing. What you should drop is any phrasing that implies Deno is your whole identity as an engineer — "Deno specialist" in a headline, or a skills block where Deno sits alone with no Node.js or Workers beside it. Pair the runtime with the platform and the standard it implements, and the line ages well whatever the vendor does next.

Where do Deno, Node, Bun and Workers belong in your tech stack section?

Runtimes and platforms belong on separate lines, labelled with the words the industry actually uses. A tech stack block that works for backend and full-stack roles in 2026 runs: Languages, Runtimes, Edge and serverless platforms, Data and storage, Tooling. Deno, Node.js and Bun go on the Runtimes line. Cloudflare Workers goes on the platforms line next to AWS Lambda, Vercel Edge Functions or whatever else you've genuinely shipped to. Wrangler, D1, KV, R2, Durable Objects and Queues sit under data and tooling, not jumbled in with the runtimes. The distinction matters because a recruiter screening for "Workers experience" is looking for the platform, while the hiring manager reading the same CV wants to know which runtime you've debugged at three in the morning.

Keep it single-column and plain. Parsers read a page in reading order, so a two-column skills sidebar, an icon grid or a skills table turns a clean list into scrambled text — and the one thing worse than a missing keyword is a keyword the extractor mangled. Line breaks are safer than long comma runs, because each term lands on its own line. Hold each entry to one to three words: "Cloudflare Workers," not "extensive hands-on experience with the Cloudflare Workers platform." And cap the block at roughly ten to twenty terms you can defend in a technical screen. A fifty-tool wall is quick to write and quicker for a reviewer to discount, because nobody is credible at fifty things.

Then add the layer most CVs skip: the standard underneath the brand. Workers and Vercel Edge Functions both run V8 isolates and expose web-standard APIs — Fetch, Request and Response, Web Crypto — with a Node.js compatibility layer bolted on for the rest. Writing "web-standard APIs (Fetch, Web Crypto), V8 isolates, WebAssembly" tells a reader your knowledge transfers across vendors, which is precisely the worry a hiring manager has about a candidate whose only credential is one platform. It also keeps the document from expiring. If your employer moves off Workers next year, the isolate and web-standards vocabulary still describes what you know, while a line reading only "Deno Deploy" quietly stops meaning anything.

A six-line tech stack block that separates runtimes from the platforms they run on.

How do you phrase runtime migration and edge work as measurable impact?

Runtime and edge work becomes measurable the moment you attach a before-and-after number to it. "Migrated 14 services from a container-based function platform to Cloudflare Workers, cutting p95 cold start from ~400ms to under 10ms" is a bullet. "Experience with serverless migration" is a label. Edge platforms happen to be generous with metrics, because the whole argument for isolates is latency: they start in single-digit milliseconds where container-based functions can take hundreds. You almost certainly watched a dashboard move during that migration. Write down what moved — p95 latency, cold-start count, monthly invocation cost, deploy duration, error rate — and the scope it moved across, measured in services, endpoints or requests per day.

Three rewrites show the pattern. Weak: "Worked with Deno and Cloudflare Workers." Strong: "Ported a TypeScript API from Deno Deploy to Cloudflare Workers ahead of the platform sunset, keeping 40+ endpoints live with zero downtime across a two-week cutover." Weak: "Built serverless functions." Strong: "Moved auth token verification and rate limiting to the edge, trimming 120ms of round-trip latency for users outside the US and cutting origin traffic by a third." Weak: "Used Durable Objects." Strong: "Replaced a Redis-backed session store with Durable Objects, removing a single-region dependency and one on-call pager source." Each strong version names the tool, the action, the number and the consequence — and each survives being read aloud in an interview.

Be exact about what you can defend, because these bullets get probed. If you can't share absolute traffic figures, give the shape instead: "high-six-figure daily requests" or "the busiest of our four regions." Quote p95 or p99 rather than averages; any engineer worth working for will ask which one you meant. Don't claim a migration you only scoped, and don't inherit the team's number as yours without saying what you owned. If you want a read on whether your bullets land as ownership or as activity, the free CV analysis scores impact and ownership as its own category alongside tech stack and ATS compatibility, so you can see which of the two your current wording registers as.

Which keywords does an ATS match when the ad says "serverless" instead of Deno?

When the ad says "serverless" or "edge runtime" and your CV says "Deno," many systems record no match at all. The literal layer of an ATS still runs first and still looks for the exact string from the posting, before any language-model scoring gets a chance to reason about synonyms. "Workers" does not automatically resolve to "serverless," and "Deno" certainly doesn't. So the rule is unglamorous but reliable: write both the branded term and the generic category, in the posting's own words. If the ad says "edge functions," your CV says "edge functions" somewhere, even if the thing you built was a Worker. Mirror, don't paraphrase — paraphrasing is how qualified people get filtered out.

Here's the pairing worth memorising for this corner of the market. Branded: Cloudflare Workers, Wrangler, Workers KV, D1, R2, Durable Objects, Queues, Hyperdrive, Deno, Node.js, Bun, AWS Lambda, Lambda@Edge, Vercel Edge Functions. Generic: serverless, serverless architecture, edge computing, edge runtime, edge functions, V8 isolates, WebAssembly, distributed systems, Infrastructure as Code, CI/CD. Write acronyms and their expansions together wherever both are true — "IaC (Infrastructure as Code)," "CDN (content delivery network)" — because a filter built on one form won't fire on the other. And keep "TypeScript" spelled exactly that way. A posting asking for TypeScript will not credit you for "JS/TS" or "JavaScript frameworks," however obvious the equivalence looks to a human.

Placement beats repetition. One appearance in the stack block plus one inside a quantified bullet is the strongest pattern there is; saying "Cloudflare Workers" seven times doesn't lift your rank in any modern system, and it does make a reviewer suspicious. Spread the high-priority terms across your summary line, your job titles where they're accurate, the stack block and two or three achievement bullets. Then check the file rather than the design: paste the job ad into an AI CV builder and you'll see the skills the posting asks for that your draft never mentions, plus ATS-friendly versions in six templates that use the ad's own vocabulary. Add only terms you'd happily be interviewed on.

What should a full-stack developer's CV look like for edge-first roles in 2026?

An edge-first CV in 2026 leads with architectural judgment, not with the length of your tool list. The senior signal hiring managers screen for is whether you know what doesn't belong at the edge: tight CPU budgets, no native modules and request-scoped execution make isolates excellent for auth checks, routing, rate limiting and geo-based rewrites — and wrong for long-running batch jobs, large-model inference or anything leaning on heavy native npm packages. A CV that says "moved token verification and A/B bucketing to Workers, kept image processing and nightly reconciliation on Node.js" demonstrates more seniority than a skills block listing every binding Cloudflare has ever shipped. Judgment is the scarce thing. Show it in a bullet, not in an adjective.

Structurally, keep it to two pages and put the stack where it gets read. A summary of two lines naming your domain, your primary runtime and your deployment target. Then the stack block. Then three or four roles in reverse order, each with four to six bullets that carry numbers. Then one project — ideally the migration you just ran, or something self-hosted with workerd or celld, which is about the most topical thing a backend engineer can have on a CV this quarter. Skip the skill-percentage bars, the headshot and the two-column template. For the longer version of this layout, the walkthrough for engineers clearing the first screen covers structuring a stack section parsers read correctly.

One opinion, held firmly: listing Node.js, Deno and Bun as three equal strengths makes you look junior, not versatile. Almost nobody has production depth in all three, and an interviewer will find the gap in about four minutes. Name the one you've run under load, show the second as working knowledge, and drop the third unless a job ad asks for it. The same discipline applies to this acquisition. Don't rewrite your CV into a Cloudflare brochure because of one deal — reframe the Deno work as migration experience, keep your runtime vocabulary generic enough to survive the next reshuffle, and spend your effort on the numbers. Tools churn every eighteen months; a bullet proving you cut latency by 120ms doesn't.

Frequently asked questions