//Durable Objects

Serverless code with its own consistent state

Build and run chat services, multiplayer systems, and collaborative apps that keep users in sync worldwide, with no message brokers or state stores to manage.

Long-running serverless apps

Durable objects run for as long as the work takes. They can compute in the background and handle high volumes of requests concurrently.

Every user in sync, instantly

Each durable object works as a WebSocket server and client. Broadcast state to all connected clients in a few lines of code.

Scale to millions as you grow

Give each unit of work in your app its own lightweight, isolated durable object. Run millions of them, with no capacity to plan.

One coordinator for every unit of shared state

Every call to a durable object reaches its one active instance, wherever it runs across 100+ data centers. A conditional write in durable storage guarantees a single owner, even during network failures. You write the class. Azion handles placement, routing, and failover.

Users in different regions connected to durable objects running across Azion's distributed infrastructure

Use cases

AI agents

Stateful agent runtime

Give each agent its own durable object to keep conversation and task state, run steps in order, and resume after a pause.

Chat and messaging

Real-time chat with presence

Run one durable object per room to store messages, track who's online, and broadcast every update to connected users.

Multiplayer games

Authoritative game server

Keep each match's players, rules, and score in one durable object and push every move to all players as it happens.

Collaborative editing

Live document sync

Route all edits to a document through its durable object, so concurrent changes apply in order and everyone sees the same version.

Booking and checkout

Inventory and seat reservations

Manage each event, cart, or SKU in its own durable object, so the same seat or item is never sold or added twice.

Counters

Consistent shared counters

Count likes, votes, views, or quotas in a durable object, so every increment lands even when updates arrive all at once.

The shortest path to real-time, stateful apps

Requests from anywhere reach the same durable object, so one instance coordinates every client that shares its state. It handles fan-in and fan-out over WebSockets, and its embedded SQLite database keeps state, events, and history next to your code.

DNZ
Axur
Radware
Arezzo
Contabilizei
Magazine Luiza
Fourbank
HeroSpark
Crefisa
Netshoes
Dafiti
Global Fashion Group
HeroSpark Logo

"Azion transformed our operations, reducing costs and improving performance while freeing 200+ monthly hours for strategic development."

Mateus Leonardi

CTO at HeroSpark

//Complete, not complex

All the development primitives you need

Frequently Asked Questions

What is Durable Objects?

Durable Objects is serverless compute with its own consistent state on the Azion Web Platform. Each object is a single instance of your code, identified by a unique name, with in-memory state, transactional SQL storage, WebSocket support, and alarms. Every request for that object reaches the same instance, which makes the object the coordination point for anything that many users or services share.

How do Durable Objects keep state consistent?

Three guarantees work together. Only one instance of each durable object runs at a time, protected by an ownership record in durable storage. That instance processes one event at a time, so concurrent requests never interleave. And every write is an ACID transaction in the object's own SQLite database, confirmed in durable storage before the response is sent.

How are Durable Objects different from Functions?

Functions handle each request independently and keep nothing between executions. A durable object keeps its state across requests, holds WebSocket connections, runs alarms, and serves every client that addresses the same object from a single instance. Use Functions for request-time logic and Durable Objects when many clients need to share and update the same state.

When should I use Durable Objects instead of KV Store or SQL Database?

KV Store is eventually consistent and keeps the last write when two writes hit the same key, which fits configuration and session data read at high volume. SQL Database fits relational data that your whole application queries. Use Durable Objects when one entity, such as a room, a cart, or an account, needs ordered updates and a single source of truth.

How do WebSockets work in Durable Objects?

An object accepts WebSocket connections directly and can broadcast to all of them. When no messages arrive, the object hibernates while the connections stay open, and it wakes up when the next message comes in, so idle connections don't keep the object running.

How do alarms work?

An object sets an alarm for a future time, and the platform wakes that object when the time comes, even if it has hibernated. In rare failure cases an alarm can fire more than once, so write alarm handlers that are safe to repeat.

Can I build AI agents with Durable Objects?

Yes. Give each agent or conversation its own durable object and keep its history in the object's SQL storage, so every turn reads and writes the same state.

How does Durable Objects on Azion compare to other platforms?

Azion follows the same Durable Objects model: one instance per object, events processed in order, transactional storage, WebSockets, and alarms. Each object keeps its data in its own SQLite database, with changes saved to durable storage outside the machine that runs it. The API is compatible, so existing Durable Objects code runs on Azion.

How do I migrate existing Durable Objects code to Azion?

The programming model is the same: a class, a name, storage, WebSockets, and alarms. The API is compatible, so your classes run on Azion without a rewrite. Just replace your current bindings with Azion configuration.

//Build

Build once.
Run everywhere.

Get a faster path to launch, lower latency, and less infrastructure overhead.