Build Secure REST APIs with Deno 2, Oak, and Deno KV

js

Build Secure REST APIs with Deno 2, Oak, and Deno KV

Learn how to build secure REST APIs with Deno 2, Oak, and Deno KV using TypeScript, built-in storage, and safer defaults. Start now.

Apr 30, 2026

I remember the first time I tried to build a REST API with Deno. It was version 1, the ecosystem was young, and I spent hours wrestling with import maps and missing libraries. Deno 2 changed everything. It is not just an upgrade; it is a fundamental rethinking of what a server-side runtime should look like when you start from scratch instead of carrying decades of Node.js baggage. The marriage of native TypeScript, a built-in key-value store, and a secure-by-default permission model makes it an attractive alternative for anyone tired of fighting config files and node_modules bloat. But how does it all work in practice? Let me walk you through what I have learned building production-grade endpoints with the Oak framework and Deno KV – and why I think you should give it a try.

Before we write any code, we have to understand why Deno 2 exists at all. Node.js was designed in 2009, when JavaScript was a different language. Deno was created by Ryan Dahl, the same person who invented Node, to fix the mistakes he saw in his earlier creation. Have you ever looked at a package.json with hundreds of dependencies and wondered if there is a cleaner way? Deno thought so too. It removes node_modules, replaces it with URL imports and a simple import map, and bakes TypeScript support directly into the runtime. You do not need tsconfig.json or Babel. You write .ts files, run deno run main.ts, and it just works.

The permission model is the feature that took me longest to appreciate. I am used to Node giving my application full access to the file system, the network, and environment variables the moment I run it. Deno flips that: every capability is denied by default. You have to explicitly allow access to specific network addresses, directories, or environment variables. At first this feels tedious, but it forces you to think about security from the start. When I deployed my first Deno API to production, I was able to restrict it to only bind to port 8080 and talk to my Stripe webhook endpoint. No script in the application could accidentally read your home directory.

Let me show you what a typical start command looks like:

deno run --allow-net=0.0.0.0:8080 --allow-env=PORT,JWT_SECRET --allow-kv src/main.ts

Think about that. If someone manages to inject malicious code, they cannot read your .ssh folder or make requests to internal services. The runtime gives you a contract you can trust.

Now, the Oak framework is the Express equivalent for Deno. It is built by the same community that maintains many of the standard libraries, and it follows the middleware pattern you already know. But because Deno is modern, Oak uses the Web standard Request and Response interfaces, not the Node.js req and res objects. This means the same middleware you write for Oak can theoretically be reused in any platform that supports web standards, like Cloudflare Workers or Deno Deploy.

Here is a minimal Oak server:

import { Application, Router } from "jsr:@oak/oak";

const app = new Application();
const router = new Router();

router.get("/", (ctx) => {
  ctx.response.body = { message: "Hello from Deno 2" };
});

app.use(router.routes());
app.use(router.allowedMethods());

console.log("Server running on http://localhost:8080");
await app.listen({ port: 8080 });

No npm install, no package.json. Just import from the URL and run. The jsr: prefix is Deno’s modern registry, but you can also use npm: for any npm library. Need Zod for validation? import { z } from "npm:zod" and it works.

Deno KV is the built-in persistent key-value store. It is not an afterthought; it is part of the runtime, backed by SQLite locally and FoundationDB on Deno Deploy. You do not need to install Redis or set up a database. You call Deno.openKv() and you get a consistent, transactional store that scales to millions of keys in production. The API is straightforward: kv.set(["products", "123"], product) and kv.get(["products", "123"]). But the real power lies in secondary indexes, atomic transactions, and list queries with prefixes.

Let’s build a simple product repository that uses both Oak and KV:

// src/db/kv.ts
const kv = await Deno.openKv();

export async function createProduct(product: Product) {
  const id = crypto.randomUUID();
  const key = ["products", id];
  const result = await kv.set(key, { ...product, id });
  return id;
}

export async function getProduct(id: string) {
  const result = await kv.get(["products", id]);
  return result.value;
}

Notice the crypto.randomUUID() – Deno has the Web Crypto API built in, no need for a random ID library. And because KV supports atomic operations, you can implement optimistic locking for inventory counters:

async function decrementStock(productId: string, quantity: number) {
  const key = ["products", productId, "stock"];
  const res = await kv.atomic()
    .check({ key, versionstamp: null }) // ensures we have the latest value
    .set(key, (await kv.get(key)).value - quantity)
    .commit();
  if (!res.ok) throw new Error("Stock changed");
}

This is production-ready concurrency control without external tools. Have you ever had to add pessimistic locks to a Node API? Here it is handled in ten lines of code.

Middleware in Oak is similar to Express, but with better error handling thanks to async. A logger middleware might look like this:

app.use(async (ctx, next) => {
  const start = Date.now();
  await next();
  const ms = Date.now() - start;
  console.log(`${ctx.request.method} ${ctx.request.url} - ${ms}ms`);
});

And for authentication, you can check a JWT token in a middleware and attach the user to the context:

app.use(async (ctx, next) => {
  const token = ctx.request.headers.get("Authorization")?.replace("Bearer ", "");
  if (!token) {
    ctx.response.status = 401;
    ctx.response.body = { error: "No token" };
    return;
  }
  // verify with @std/crypto or a JWT library
  ctx.state.user = await verifyToken(token);
  await next();
});

The ctx.state object is the recommended way to pass data between middleware and route handlers. It is type-safe if you define an interface for the context.

Now, how do we structure a real API? I prefer a module folder per domain. For example, a products module contains its own router, service, repository, and schema. The router imports Oak’s Router, defines endpoints, and calls the service layer. The service uses the repository, which calls the KV store. This separation makes testing easy – you can mock the repository without touching the store.

Here is a product router example:

// src/modules/products/product.router.ts
import { Router } from "jsr:@oak/oak";
import * as productService from "./product.service.ts";

const router = new Router({ prefix: "/api/products" });

router.get("/", async (ctx) => {
  const products = await productService.listProducts();
  ctx.response.body = { data: products };
});

router.post("/", async (ctx) => {
  const body = await ctx.request.body().value;
  const id = await productService.createProduct(body);
  ctx.response.status = 201;
  ctx.response.body = { id };
});

export default router;

Then in the main app file:

import productRouter from "./modules/products/product.router.ts";
app.use(productRouter.routes());
app.use(productRouter.allowedMethods());

The whole application initializes cleanly. No build step, no bundler. You run deno task dev and it watches for changes with the --watch flag.

But what about environment variables? Deno has native support for .env files through the --env-file flag. I add this to my dev task:

"dev": "deno run --watch --env-file=.env --allow-net --allow-env --allow-kv src/main.ts"

Now my .env file is loaded automatically, no dotenv dependency.

Testing is also built in. Deno’s test framework is part of the runtime. A test for the product repository might look like:

import { assertEquals, assertExists } from "@std/assert";
import { createProduct, getProduct } from "../src/db/kv.ts";

Deno.test("create and retrieve a product", async () => {
  const id = await createProduct({ name: "Test", price: 9.99 });
  const product = await getProduct(id);
  assertEquals(product.name, "Test");
  assertExists(product.id);
});

Run it with deno test --allow-kv. The KV store used in tests can be in-memory because Deno KV opens a temporary database when no path is specified. No mocking needed.

One of the aspects I love most about Deno 2 is its compatibility with Node.js packages. If you have an existing npm library you depend on, you can import it with npm: prefix. For example, I use zod for validation because I am familiar with it. But I could also use Deno’s built-in @std/assert or @std/collections. The choice is yours.

Now, where does Deno shine compared to Node? Large enterprises often require strict security and minimal configuration. A financial services company could use Deno to enforce that their API only writes to KV – not to the filesystem – by giving only --allow-kv. Developers cannot accidentally log secrets to disk. That kind of guarantee is hard to achieve with Node without complex sandboxing.

I have found that Deno is also excellent for edge computing. Deno Deploy (the official serverless platform) runs your code in data centers around the world, using the same runtime API. The KV store becomes a global, fast persistence layer that replicates across regions. Writing a global API with low latency is surprisingly simple.

Let me ask you this: how many times have you spent hours debugging CORS headers or proxy configurations with Node? Oak handles CORS with a single middleware:

import { oakCors } from "https://deno.land/x/cors/mod.ts";
app.use(oakCors());

Or you can write a minimal one yourself. The point is: the ecosystem has matured.

As you build your own APIs, remember that Deno expects you to be explicit. Explicit imports, explicit permissions, explicit error handling. That explicitness translates into fewer runtime surprises. I cannot count how many times a missing import in Node caused a runtime error that never showed during development. In Deno, every import is resolved at compile time. If it is not there, the program does not start.

Finally, I encourage you to try building a small project with Deno 2, Oak, and KV. Start with a simple CRUD API for a personal blog or a to-do list. You will discover that you can go from zero to a deployed, secure API faster than you thought possible. And when you do, hit the like button if this article helped, share it with a friend who is still configuring Babel, and leave a comment with your experience. I read every single one.

Happy coding, and remember: Deno is not just a tool. It is a philosophy of design that values clarity and safety over convenience. Once you get used to it, you may never look at Node the same way again.

As a best-selling author, I invite you to explore my books on Amazon. Don’t forget to follow me on Medium and show your support. Thank you! Your support means the world!

101 Books

101 Books is an AI-driven publishing company co-founded by author Aarav Joshi. By leveraging advanced AI technology, we keep our publishing costs incredibly low—some books are priced as low as $4—making quality knowledge accessible to everyone.

Check out our book Golang Clean Code available on Amazon.

Stay tuned for updates and exciting news. When shopping for books, search for Aarav Joshi to find more of our titles. Use the provided link to enjoy special discounts!

📘 Checkout my latest ebook for free on my channel!
Be sure to like, share, comment, and subscribe to the channel!

Our Creations

Be sure to check out our creations:

We are on Medium

Share: Facebook Twitter Reddit LinkedIn WhatsApp Telegram Pinterest Email Instagram

js