Skip to content
Akter 0.1 alpha is outRead the post

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.

REQUESTSBROWSERYOUR APISCHEDULEAKTERONE TRANSACTIONAGENT/S_41COMMITDATABASEPUSHLIVE CLIENTSEVERY TABUPDATES
Figure 1. Requests reach one actor by its address. It commits each one to your Postgres database in a single transaction, then pushes the change to every connected client.

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

Process kills and network partitions
192,794acknowledged
0Lost
0Duplicated
0Unknown

Latency

p50 on one host, not an SLO
Write1.62msFresh read0.40ms

One hot key, 64 callers

Writes per second, median of 3 runs
1,647op/s

Read the benchmark report

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

001

Call actors directly. Starts on an embedded Postgres database with nothing to install.

On your servers

002

The same actors over HTTP, WebSocket and SSE, on any Postgres server you run.

Akter Cloud

003

Managed 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.