Cipher Projects ships production software. NestJS is the API door we have used for years when an app must scale and stay locked down: JWT, guards, Postgres, Redis as infra. Hono is newer to us. The 2026 job-post stack is Hono, Vite, Prisma, Better Auth, and often Bun. That is fashion until you map it onto the job. This page is the architecture fork. It is not a product sheet for either kernel. We will pick Nest or Hono for the work in front of us.
Quick answer
When you build an agent-based app (named workers, a live trail, tools, maybe a computer, maybe cron), you are not picking a web framework. You are picking who owns the HTTP door, where the model turn runs, what the computer is, how many clients share one API, and how tools enter the product. Nest + Next if you ship one browser app, operate identity and audit yourself, review every tool as code, and halt writes until a human confirms. Hono family if web, Electron, and Expo must share one typed API, tenancy is orgs and invites, or the computer stays signed in. Bun, Cloudflare Workers, and Elysia sit in the same thin-handler family. They are not required, and they are not what Rakazo runs. Rakazo runs Hono on Node 22/24/26. Runtime is not the methodology. The door, the worker, and the computer are.
Best for: teams choosing a TypeScript kernel for a production agent product, not a chat demo. Honest limit: Cipher has more hours on Nest than on Hono. The Hono side below is a dated public read of Rakazo (4 September 2026) plus the rest of the thin-handler family. Verify main before you copy defaults. We are not selling a Nest stamp or a Hono bot.
Last updated: 6 September 2026.
What are you actually choosing?
Five decisions. The framework name is a label on top of them.
| Decision | What it means in an agent app |
|---|---|
| Who owns the HTTP door | Auth, policy, persistence. The process that decides who you are before a tool runs. |
| Where the model turn runs | Inside the API process, or in a worker the API still gates. Long runs stall HTTP if you skip the split. |
| What the computer is | Ephemeral sandbox you destroy on TTL, or a signed-in desktop that survives the tab. |
| How many clients share one API | Browser only, or web plus Electron plus Expo against the same contract. |
| How tools get into the product | Code you review and stamp, or a plugin catalog users connect. |
Two TypeScript paths show up over and over. Same picture on the surface: roster, thread, ask, routines. Different kernel.
What is the Nest + Next control plane?
NestJS is the API. Next.js is the authenticated UI. Postgres is source of truth. The agent library is called from the API process, or from a worker the API still owns.
| Piece | Typical job |
|---|---|
| NestJS | Modules, DI, guards, interceptors, Passport. HTTP, authz, persistence, SSE. |
| Next.js App Router | Authenticated UI. Cookies, middleware, same-origin /api. |
| ORM | TypeORM is common in Nest apps. Prisma appears too. It is not required. |
| Postgres | Users, threads, events, policies. |
| Redis | Locks, cache, pub/sub for trail fanout. Not the session store. Access tokens stay JWT. Refresh lives in an httpOnly cookie plus a hash in the user row. |
| Agent runtime | In-process from Nest (Mastra, LangGraph, a custom loop), or a worker still gated by Nest. |
| Sandbox | Often ephemeral: start a process or container, map an authed preview URL, destroy on TTL. |
Shape: two processes, one origin. The browser talks to Next. Next and the API share a domain. Nest decides who you are before a tool runs. The UI does not own authorization.
This is the path we know for scaling and securing an API. Helmet, cookie parser, CORS with credentials, a global ValidationPipe, Passport JWT, role guards, TypeORM migrations with synchronize: false. Redis for locks and fanout. Policy as data: allow, deny, or ask on the tool path, halt a write until a human confirms. Guards and tables are the natural place.
Why people use Nest for agents
They already have a Nest + Next kernel: login, MFA, RBAC, migrations, audit. The agent is a feature on rails, not a new product. Agent #2 should not rebuild login.
Phone is a browser. No Electron, no Expo in v1. The sandbox is dead when the tab dies. Destroy / TTL. The computer is not a pet.
Subscribe is SSE with a Bearer token. EventSource cannot send Authorization, so the client uses fetch plus a readable stream. That constraint comes from JWT, not from Nest itself. Redis pub/sub is enough to fan out trail events. A typed trail can be a TypeScript discriminated union both apps import. You do not need Zod-as-RPC unless you have three clients.
What Nest costs you
Ceremony. Modules, providers, decorators, two tsconfigs, two deploys. Slow to first route compared with a Hono file. Fine when you will clone the rails. Tax on a three-week demo.
Two-process ops. Nest and Next are separate builds. Same-origin proxy is extra config. Next is a server. A Vite SPA embeds in Electron. Nest + Next will fight “one chrome, three shells.”
In-process turns block the door. If the model loop lives inside Nest, a long run contends with HTTP, SSE, and cron. The honest fix is a worker behind Nest, not a rewrite to Hono. People skip that and then blame Nest for latency.
Nest was not designed for Cloudflare Workers. You can squeeze it, and you will fight it. You must write the contract: DTOs and a shared types file. Drift is the failure mode (API event kinds vs UI cards). oRPC generates client types from Zod. Nest shops hand-maintain them.
Hiring still moves agency choices. Nest sounds like a bank. That is recruiting, not architecture.
What is the Hono family, and where does Bun sit?
Hono is a Fetch-based router. Small surface. It runs on Node, Bun, Deno, and Cloudflare Workers. That portability is the point of the family, not a reason to pick Hono for a VNC desktop.
People bundle Hono with adjacent choices that are not Hono:
| Piece | Job | Required? |
|---|---|---|
| Hono | HTTP door. Thin handlers. | This is the kernel name people use. |
| oRPC + Zod | One typed contract for web, Electron, Expo. | Yes if you have three clients. Optional if you have one browser. |
| Better Auth | Login, orgs, invites, sessions. | A second product. Replacing it later is a migration. |
| Prisma + Postgres | Persistence. Tenancy habits live here. | Common. Switching later is still a project. |
| Job runner | The turn. Graphile Worker in Rakazo. The API stays thin. | Yes once runs get long. This is the grown-up reason for the split, not “Hono is fast.” |
| Vite SPA | Embeddable chrome for Electron. Expo for native. | Yes if desktop and phone are in scope. Next is a poor Electron guest. |
| Bun | Runtime. Fast install, fast start, Workers-adjacent DX. | No. Sibling in the family. Rakazo does not use it. |
| Cloudflare Workers / Elysia | Edge webhook or small API. Same thin-handler idea. | Different job from a signed-in desktop. |
Do not collapse this into “the Hono stack.” A Hono Worker that forwards a signed payload is not a bot platform. A Bun tutorial with two files is not Graphile plus Docker computers. Name the door, the worker, and the computer, then pick runtime last.
What does a public Hono agent stack look like?
Rakazo (Apache-2.0, beta, rakazo.com) is a public example of the Hono path, not a Cipher product and not the whole family. README read plus source on 4 September 2026: TypeScript; React 19, Vite, Tailwind; Electron and Expo; Hono and oRPC; PostgreSQL and Prisma; Better Auth; Graphile Worker; Pi; Docker, E2B, Daytona, Box; Composio, Pipedream Connect, MCP, OpenAPI. Dev requirement is Node 22.x / 24.x / 26+ and pnpm 9. Rakazo does not use Bun.
Hono mounts Better Auth at /api/auth/* and oRPC at /rpc/*. threads.send returns { taskId, runId, seq } and does not own the token stream. threads.subscribe is a standing eventIterator from a cursor. Graphile Worker runs the turn. Fanout uses Postgres LISTEN/NOTIFY. Adapters sit behind interfaces: job publisher, realtime fanout, sandbox provider. Computers: Team (shared sessions) and Private (per bot). Local Docker on by default. Destroy exists. Staying signed in is the happy path.
Policy on that read: name heuristics. shell, write_file, spawn_bot, and computer_* are approval-exempt. Mutating connector names ask. User rules can Always allow. Optional LLM auto-review on the default path. Convenient for a desktop agent, and a bad default if the agent can reach customer systems. An LLM judge is not a control.
Official Grok Bot docs (the x.ai product, not Rakazo) say one cloud computer per account, not per bot, and “do not use separate bots as a security boundary.” Persistence is UX. Isolation is the sandbox user, container, or provider, plus authz on the API. The roster is not a wall.
Why people use this for agents
Three clients, one API. Web + Electron + Expo all call /rpc. Hono + oRPC + Zod is how that stays typed without Nest modules. Vite SPA is embeddable. Better Auth is orgs and invites on a short path versus writing Passport plus MFA. Turns are jobs, so the API stays thin. Sandbox adapters exist because the desktop stays on. Plugin catalogs match a consumer bot: users connect apps. You are not stamping one client’s wrappers.
What the Hono path costs you
You rebuild the door. Nest’s module and guard story is missing on purpose. MFA, RBAC, audit, “this role cannot Always-allow” become ad hoc middleware. Fine until the second customer needs them.
Better Auth is a second product. Prisma as default locks tenancy habits. Postgres NOTIFY works; payload size, connection lifecycle, and “every client LISTENs” are real. Redis pub/sub is the other common pattern. Neither is free.
Three apps to ship: web, Electron, Expo, plus a public marketing site. Local Docker plus Electron is a lot to ask of a user. Plugin catalogs mean tools you did not write. Credentials encrypted at rest is necessary. It does not replace an allowlist. Pi (or any embedded agent runtime) in the kernel couples model-loop choice to the API repo. Swapping later is political.
How do you scale and secure the API on each path?
This is the Nest muscle. Treat it as the bar, not as a reason to ignore Hono.
| Concern | Nest + Next (as we have run it) | Hono family (typical) |
|---|---|---|
| Identity | JWT access, httpOnly refresh, Passport, DB lookup, role/status guards. MFA you operate. | Better Auth sessions and orgs, or you write it. Cookie plus Bearer for SPA / native. |
| Policy | Guards and tables. Allow / deny / ask on the tool path. Writes halt. | Middleware plus rules tables if you build them. Defaults in Rakazo are name heuristics, not RBAC. |
| Validation | Global ValidationPipe, DTO classes, helmet, CORS credentials. | Zod at the contract. Helmet-equivalent is your middleware list. |
| Session store | Not Redis. Redis is locks, cache, queues, pub/sub. | Better Auth’s model. Know it before you need to leave it. |
| Trail fanout | Redis pub/sub. SSE over fetch + stream because EventSource cannot send Bearer. | LISTEN/NOTIFY, or Redis, plus oRPC eventIterator. |
| Long turns | Bull (or similar) behind Nest. Skip this and Nest looks slow. | Graphile Worker (Rakazo) or another job runner. Skip this and Hono looks slow. |
| Secrets | Encrypt at rest, inject at run, never write keys into trail events. | Same rule. Connector credentials encrypted on the server, never returned by the API (Rakazo). |
| Edge | Poor fit. Nest wants a process. | Hono on Workers or Bun for a webhook. Not the desktop computer. |
Scale is not “Hono is faster.” Scale is whether the HTTP process stays thin while turns, cron, and computers run elsewhere. Nest shops that put the model loop in the API process fail this. So do Hono shops that handle the turn inside the router. Split the worker when runs get long. Rakazo already did. Nest shops often have not.
When does Nest still win?
One web app (desktop Safari and mobile Safari). Identity and audit you operate. Tools are code you review. No marketplace. Writes must halt. Shell and spawn are not approval-exempt by default. You will clone this system, so ceremony is the product. The sandbox dies with the tab.
Poor fit for Electron-first. Poor fit for Workers-first. Good fit when the API door is the hard part and the agent is a feature on it.
When does the Hono path win?
Web, desktop, and native are in scope. Tenancy is Spaces, orgs, invites. The computer stays signed in. VNC, Chromium, or a host desktop is what you sell. You want to swap E2B / Daytona / Box behind one interface. You are publishing an open-source Grok-style bot. Turns must be jobs: long runs, recovery, multiple computers.
Pick Bun or Workers when the agent is an edge webhook or a small API, not a VNC desktop. Same thin-handler family, different job.
What is not a stack choice?
The public essay Designing Grok Bot for a world of persistent agents (3 September 2026) hides chats, sessions, models, context windows, system prompts, projects, connectors, sandboxes, permissions, and automations behind five objects: Bot, Chat, Prompt, Tool, Artifact. Those are IA rules. They do not specify Hono or Nest.
Patterns that belong on either path: a roster of named workers rather than a chat-history sidebar; send versus subscribe (the sending tab should not own the live trail); a typed trail so the renderer switches on kinds instead of treating markdown as default; Ask / Allow once / Always / Deny as policy UX with enforcement on the server; capabilities at account versus memory and cron on the role; cron as trail receipts so work can start from a schedule.
Steal the pattern. Do not take the kernel with it. Rakazo implements send/subscribe with oRPC + eventIterator + Graphile + NOTIFY. A Nest path implements the same split with POST stream + GET SSE + Redis. Same idea.
What fails on both paths?
Agent runtime in the API process stalls HTTP. Client-side Always-allow is a skip, not a policy. Keys in chat fail both stacks: encrypt at rest, inject at run, never write secrets into events. Bots are not a security boundary. Isolation is the sandbox plus authz on the API. Plugin catalogs versus code tools is a brief choice, not a framework choice. Monorepo versus two apps: pick the shape that matches how many clients you ship.
How should you choose for the next eighteen months?
Ask what still has to be true later.
Hono family if three clients; orgs; a computer that stays logged in; sandbox providers will change; you are shipping a bot platform. Add Bun or Workers only if the job is an edge webhook or a small API.
Nest path if one web app; identity and audit you operate; tools are code; writes halt; sandbox dies with the tab; you will clone the rails.
Mix, carefully: Next or Vite as UI; a Hono Worker as an edge webhook that forwards a signed payload into Nest; Nest still owns users, policy, Postgres. Do not run two full backends (two ORMs, two auth stories, two audit trails).
Cipher’s cutover rule: score the door, the worker, and the computer. Then pick the kernel. Do not pick Hono because it is on the job post, and do not pick Nest because it is what you already know, unless those facts match the job.
FAQ
Is Hono faster than Nest for agents? Not in a way that should decide this. The stall is the model loop in the HTTP process. Split a worker on either kernel. Rakazo did that with Graphile. Nest does it with Bull or the equivalent.
Does Rakazo run on Bun? No. Node 22.x, 24.x, or 26+, pnpm 9. Bun is a sibling runtime in the thin-handler family. Do not attribute it to that repo.
Can I keep Nest and still use Vite or Expo? Yes for the UI. The pain is one chrome across three shells while Next remains a server, and a typed contract across clients without oRPC. Possible. You are paying Nest’s ceremony without its “one browser origin” benefit.
Is Better Auth enough to replace Nest guards? For orgs and invites, it is the short path. For “this role cannot Always-allow a write to a customer system,” you still write policy. Nest puts that in guards and tables by habit. Hono makes you add it.
Should policy live in the model? No. An LLM auto-review judge is not a control. Ask cards are UX. Enforcement stays on the server, on both paths.
Who should implement either path? A studio that will name the door, the worker, and the computer before naming the framework. Cipher Projects does that work for Australian and Singapore teams. Applied AI engineering.
Sources
- elie222/rakazo README — stack, clients, computers, plugins. Internal read 4 September 2026 of contracts, Hono app, approval code, computer-runtime docs.
- Encore’s 2026 Nest vs Hono pages answer a different question (token cost when a coding agent writes a backend). Useful for DX cost. Wrong job for an agent product kernel.
- Designing Grok Bot for a world of persistent agents (3 September 2026) — five nouns, roster, computer ladder. IA, not a stack endorsement.
Related: Claude workflow vs production agent · AgentCore vs Daytona vs E2B · Durable workflow frameworks · How we price production AI agents