Open Source Azure Durable Functions Alternatives

Retry loops, recovery code and hand rolled state machines eat the time meant for the application. Temporal is a durable execution platform that takes that work over, without giving up scale or reliability.

The server executes units of application logic called Workflows in a resilient manner, handling intermittent failures and retrying failed operations on its own. It is a mature technology that began as a fork of Uber's Cadence, and it is developed by Temporal Technologies, a startup founded by the people who created Cadence.

Getting from install to a running workflow is a short path.

• Local server: one Homebrew install and one start command bring up a prebuilt image with its dependencies.
• Samples: Go and Java sample repositories run against the local server, from hello world upwards.
• CLI: the Temporal CLI lists namespaces and workflows and drives the running server.
• Web UI: a browser interface on port 8233 shows your sample workflows executing.
• Language support: Workflows, Activities and Workers are written in one of the supported SDK languages.

This repository holds the source of the server itself rather than the SDKs, and the server architecture is documented alongside the code. Proposals for new features have a repository of their own, and a community site handles questions from people getting started.

Trigger.dev is a platform for writing background tasks in TypeScript and running them without a timeout. Serverless functions cut work off after a few minutes, which is the wrong shape for an agent that browses, transcodes or waits on a human decision.

Tasks live in your own codebase, version controlled and reviewed like everything else, and reach the platform through the SDK. Durability comes from checkpointing, so a run survives interruption, and atomic versioning means a new deployment leaves runs already in flight untouched.

The runtime gives you rather more than an executor.

• Queues and concurrency: concurrency rules, batch triggering, idempotency and automatic retries after an uncaught error.
• Waits and approvals: pause a run for a set duration, or until a person approves, rejects or comments.
• Realtime: subscribe to runs from your frontend with React hooks, including streaming model responses.
• Build extensions: hook into the build to add system packages, browsers, Python scripts or FFmpeg.
• Observability: full traces and logs per run, plus tags, run metadata, bulk actions and failure alerts.

Development, staging, preview and production environments are supported, and preview branches integrate with Git workflows and Vercel. Machines are configured by vCPU and memory per task. The managed cloud removes infrastructure work entirely, and self-hosting is documented for Docker Compose and for Kubernetes through an official Helm chart.

Hatchet orchestrates background tasks, AI agents and durable workflows at scale. It removes the custom admin tooling teams end up writing around traditional queues, where a task vanishes from the broker once it finishes and leaves nothing to inspect, replay or debug.

Postgres is the durability layer for both the task runtime and the observability system, which is what makes the platform straightforward to self-host. SDKs cover Python, TypeScript, Go and Ruby, and a CLI brings up a local server on macOS, Linux or WSL with Docker installed.

The feature set spans queuing, orchestration and the operations around them.

• Durable tasks: recover from failure mid-run, with pause and resume conditions built from durable sleep and event waits.
• DAGs: express data pipelines and multi-step workflows as directed acyclic graphs.
• Retries and scheduling: cover configurable retry policies with exponential backoff, cron jobs and scheduled runs.
• Fair scheduling: applies concurrency policies, priorities, rate limits and worker slots so one workload cannot starve the rest.
• Task routing: assigns work by worker labels or weighted affinity rules.
• Observability: ships a real-time web UI with alerting and logging, plus OpenTelemetry and Prometheus metrics.

Hatchet is MIT licensed and has been load tested to 10,000 tasks per second, with the maintainers noting that durability costs more resources than a Redis or RabbitMQ queue reaching higher raw throughput. Instances are multi-tenant by default with users and roles, so one deployment can serve several teams.

Rivet Actors are long-running, lightweight processes for stateful workloads. State lives in memory beside the compute and persists automatically, which removes the usual routine of loading a session out of a database and writing it back on every single request.

You create one actor per agent, per session, per document or per tenant, and each one arrives with the plumbing already attached: WebSockets for real-time streaming, workflows with automatic retries, durable queues, and its own timers and cron jobs. Actors run indefinitely while active and hibernate when idle, scaling down to zero.

Observability is built in, from local development through to production.

• SQLite viewer: browse and query an actor's own database while it runs.
• Workflow state: inspect progress, steps and retries as they execute.
• Event monitoring: track every state change and action as it happens.
• REPL: call actions, subscribe to events and interact with your code directly.
• Agent skills: a published skill set gives coding assistants what they need to add Rivet to a project.

RivetKit is a library first, so installing the package runs actors inside your own process during development. Production has three routes: a self-hosted Rust binary or Docker container backed by Postgres, the file system or FoundationDB, or the managed Rivet Cloud edge network. Clients exist for Node.js, Bun, Deno, React and Next.js, with examples for Hono, Express, Elysia and tRPC.

Inngest replaces the queue, the state store and the scheduler that usually sit behind background work. Developers write durable step functions in their own application code, and the infrastructure that normally has to be assembled and watched over disappears from the job.

A function has three parts, triggers from events, cron schedules or webhooks, flow control that governs how runs are enqueued and executed, and steps. Wrapping code in a step makes it retry on failure independently, which lets one workflow run for months and recover from errors as it goes.

The self-hosted server is worth understanding before you run it.

• Event API: receives events over HTTP, authenticates them with event keys and publishes to an internal stream.
• Runner: schedules runs, resumes paused functions on matching events and cancels others by expression.
• Queue: multi-tenant and multi-tier, handling concurrency, throttling, prioritization, debouncing, rate limiting and batching.
• Executor: executes steps, writes incremental run state and retries after failures.
• Dashboard and APIs: GraphQL and REST access plus a UI for apps, functions and run history.

SDKs cover TypeScript and JavaScript, Python, Go and Kotlin or Java, all under Apache 2.0, while the server and CLI carry the Server Side Public License with delayed open source publication. Local development runs the Dev Server from one npx command with production parity, then functions deploy to your own infrastructure and sync with the hosted platform or a self-hosted server, which invokes them over HTTPS when triggering events arrive.