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.
Use cases
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.
"Azion transformed our operations, reducing costs and improving performance while freeing 200+ monthly hours for strategic development."
Mateus Leonardi
CTO at HeroSpark
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 once.Run everywhere.
Get a faster path to launch, lower latency, and less infrastructure overhead.