The framework for durable, stateful backends that power realtime apps, background work, and agents.
Why Akter
Most backends keep each thing in pieces. An order's state sits in one table, its retries in a queue, its timers in cron, and its live updates on a socket server. When a process dies halfway through, the pieces drift apart.
Every part of your app should have one home.
Akter gives each order, chat room or agent session its own actor: an address, its own state and tables, its jobs and events, and its live clients. It handles one request at a time and commits each one in a single database transaction, so nothing is half-written and nothing runs twice.
What you build
Realtime apps.
A chat room, a document or a dashboard keeps its history and pushes every change to the people connected to it.
Background work.
A billing run or an import retries with backoff, runs on a schedule, and never quietly vanishes.
Agents.
An agent session keeps its transcript, pauses for an approval, and picks up where it left off after a crash or a deploy.
We kill processes and cut the network on purpose, then check every acknowledgement.
Crash test
Latency
Akter runs where your data lives.
Start inside the process you already run. Serve it when you need to, or let us host it.
In your process
001Call actors directly. Starts on an embedded Postgres database with nothing to install.
On your servers
002The same actors over HTTP, WebSocket and SSE, on any Postgres server you run.
Akter Cloud
003Managed runners and Postgres databases, with an inspector for every actor. In development.
Questions
01What is an actor, exactly?
An addressable part of your app, such as one order, one room or one agent session. It handles one command at a time and owns its data, its background work and its live connections.
02Do I need a Postgres database?
Your data lives in a Postgres database, as ordinary tables you can query with plain SQL. To start, PGlite, an embedded Postgres database, runs the same code with no Docker or database server; Database.postgres points it at a real Postgres server. In the alpha, run one runtime process per database.
03Can I run it inside my existing server?
Yes. Embedded, you provide Actors.layer and call actors as Effects in your own process. Served, Actors.serve exposes the same actors over HTTP, WebSocket and SSE, with an OpenAPI document and an MCP endpoint.
04What happens when a process dies mid-request?
Before the commit, nothing was written, and a retry with the same command ID places the order once. After the commit but before the reply, the retry finds the stored result and returns it without running the handler again.
05How is this different from a workflow engine?
Temporal and Restate record a function's steps so it can resume after a crash. An Akter command is a short transaction instead, and anything slow becomes a job or a workflow owned by the actor.
06Is there a hosted version?
Akter Cloud, with managed runners, Postgres databases and an inspector for every actor, is in development and its pricing here is a placeholder. The framework is Apache-2.0 and runs wherever Bun does.
Build your first actor today.
Open source and Apache-2.0. Start on your laptop, keep the same code in production.