ZenZip logozenzip

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.

app.ts
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#

ProductWhat it coversThe gap ZenZip fills
TemporalDurable workflowsHeavy cluster, replay-determinism rules, not embeddable
Inngest / Trigger.devStep functions, jobsCloud-first platforms — you don't own the runtime
Hatchet / RestateQueues + durable executionSeparate engine service / sidecar to operate
Encore.tsRust-powered backend frameworkNo durable workflows, no retry queues, no agents
BullMQQueuesRequires 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:

PhaseScopeStatus
0NAPI boundary + storage benchmarks✅ complete
1Queues, scheduler, runtime shell✅ complete
2Durable workflow engine✅ complete — chaos-tested, step API frozen
3Event bus, state machines, HTTP adapter, dashboard✅ complete
4Agent engine✅ complete
5Postgres multi-node✅ complete — 3-node chaos-tested
7Production hardening: retention/GC, health, fencing, clock-skew, SSRF, RBAC, payload encryption at rest, idempotency✅ mostly (SLSA-signed releases remain)
8Express-native DX: middleware, routers, node + fetch adapters✅ complete
9AI depth: large-payload offload, MCP both directions, realtime subscribe✅ complete
10Flow 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.