Actors, supervision, lifecycle
The classic actor toolkit — Actor, Props, tell / ask, mailboxes,
dispatchers, supervision strategies, become / stash, death-watch,
coordinated shutdown. Single-process or clustered.
actor-ts
The actor model for TypeScript — cluster sharding, event sourcing,
distributed data, persistence, observability. Runs on Bun, Node, and Deno.
What you get
Section titled “What you get”Cluster + sharding
Gossip membership, phi-accrual failure detection, downing strategies, cross-node refs, distributed pub/sub, cluster singleton with lease coordination, entity sharding with rebalancing and remember-entities.
Event sourcing + persistence
PersistentActor with persist / onEvent / snapshots, DurableState,
projections, persistence query, replicated event sourcing with vector
clocks. Pluggable journals (in-memory, SQLite, Cassandra, object-storage).
Distributed data (CRDTs)
GCounter, PNCounter, LWWRegister, MVRegister, GSet, ORSet, LWWMap, ORMap. Quorum reads/writes, gossip replication, durable storage, subscriber pattern for live updates.
Integrations
HTTP (Fastify, Express, Hono) with a route-DSL. Brokers — Kafka, MQTT, AMQP, NATS, Redis Streams, gRPC, SSE, WebSocket, raw TCP/UDP. Cache — in-memory, Redis, Memcached. Serialization — JSON, CBOR, custom.
Observability + testing
Stock metrics for actors / mailboxes / cluster + exporters (Prometheus, OTel). Tracer API + OTel spans. Management endpoints for health, members, sharding. TestKit with probes, manual scheduler, multi-node spec.
Where to start
Section titled “Where to start” Quickstart Five minutes to a running actor — installation, first message, supervision.
Why actors? The model in plain terms — what an actor is, why it's not just a worker thread or a Promise.
Learning path Suggested reading order based on what you're building — single-node, cluster, persistence-heavy, integration-heavy.
Migration guides Coming from Akka-JVM, Pekko, Orleans, Akka.NET, or vanilla TypeScript? Here's what's different.
Status
Section titled “Status”actor-ts is pre-1.0. The API surface is broad and battle-tested in internal use, but breaking changes can land between minor versions until 1.0 is cut. See the Version policy for the SemVer plan, and the ROADMAP for what’s coming next.
Runnable end-to-end demos: chat sample, voice sample.