Introduction
ZenZip is an agent-native backend framework for Node.js: durable workflows, queues, schedules, and (soon) agents on a single embedded Rust runtime.
What is ZenZip?#
ZenZip gives a Node.js process the backend capabilities that normally require a small fleet of infrastructure: durable job queues, persisted cron schedules, and crash-proof multi-step workflows. The engine is written in Rust and embedded into your process via napi-rs — state lives in a single SQLite file in your project folder.
import { zenzip } from "zenzipjs";
const app = zenzip(); // embedded SQLite store, zero config
const emails = app.queue("emails", { retries: 5 });
emails.process(async (job) => smtp.send(job.data));
app.schedule("digest", "0 9 * * *", () => buildDigest());
const onboard = app.workflow("onboard", async ({ step, input }) => {
await step.run("create-account", () => accounts.create(input));
await step.sleep("wait-a-day", "24h");
await step.run("follow-up", () => emails.push({ to: input.email }));
});
await app.start();Everything above survives kill -9. Jobs that were mid-flight are redelivered. The workflow sleeping for 24 hours wakes up on schedule even if you deployed twice in between.
Why it exists#
A typical production Node backend accumulates this stack:
- BullMQ + Redis for background jobs
- Temporal (a cluster you operate) for durable workflows
- node-cron on a box that must never restart at the wrong time
- RabbitMQ / SNS for events
- LangGraph + custom glue for agents
- OpenTelemetry + Grafana assembled by hand
Each piece works. Together they are six services to provision, secure, monitor, and pay for — before writing a line of business logic. ZenZip collapses them into one dependency, the way SQLite replaced “install a database server” for a huge class of applications.
Speed is not the pitch
The Rust core is fast, but frameworks don't win on router benchmarks — our own measurements killed the idea of a Rust HTTP server. The pitch is deleting infrastructure and durability by default.
Where it fits#
| Product | What it covers | The gap ZenZip fills |
|---|---|---|
| Temporal | Durable workflows | Heavy cluster, replay-determinism rules, not embeddable |
| Inngest / Trigger.dev | Step functions, jobs | Cloud-first platforms — you don't own the runtime |
| Hatchet / Restate | Queues + durable execution | Separate engine service / sidecar to operate |
| Encore.ts | Rust-powered backend framework | No durable workflows, no retry queues, no agents |
| BullMQ | Queues | Requires Redis; no workflows or observability |
The unoccupied square: embedded (in-process, zero extra services) + durable + agent-native + a full backend framework. That is the square ZenZip sits in.
One engine#
Internally there is exactly one execution engine. Every feature is a projection of it:
- A queue job is a single unit of leased, retryable work
- A schedule fires by enqueuing onto a hidden internal queue
- A workflow run is a job whose handler drives the step-memoization journal
- An agent is a workflow whose steps are generated dynamically by an LLM loop
One engine means every feature inherits the same lease-based crash recovery, retry backoff, and observability — and the codebase stays small enough to audit. See Architecture for the full picture.
Project status#
ZenZip is a pre-1.0 alpha being built in strictly serial, test-gated phases:
| Phase | Scope | Status |
|---|---|---|
| 0 | NAPI boundary + storage benchmarks | ✅ complete |
| 1 | Queues, scheduler, runtime shell | ✅ complete |
| 2 | Durable workflow engine | ✅ complete — chaos-tested, step API frozen |
| 3 | Event bus, state machines, HTTP adapter, dashboard | ✅ complete |
| 4 | Agent engine | ✅ complete |
| 5 | Postgres multi-node | ✅ complete — 3-node chaos-tested |
| 7 | Production hardening: retention/GC, health, fencing, clock-skew, SSRF, RBAC, payload encryption at rest, idempotency | ✅ mostly (SLSA-signed releases remain) |
| 8 | Express-native DX: middleware, routers, node + fetch adapters | ✅ complete |
| 9 | AI depth: large-payload offload, MCP both directions, realtime subscribe | ✅ complete |
| 10 | Flow control & scale: per-key concurrency, fairness, debounce, throttle, PG partitioning, radix router | ✅ complete |
| 6 / 11+ | Launch packaging, modular split, realtime/WebSocket layer | 🔜 in progress |
The engine and full API are feature-complete against the plan and covered by 190+ tests (53 Rust + 138 TypeScript), including SIGKILL crash-injection and multi-node Postgres chaos suites. What remains is launch ceremony — npm prebuild publishing, the modular package split, and the realtime/WebSocket layer.
The roadmap tracks every task. The benchmarks page shows the measurements behind each architecture decision.