Why DurableStack

I built DurableStack because I wanted background job infrastructure that felt simple to adopt but was designed for real distributed production environments from the beginning.

The problem this solves

• In many systems, background work starts simple and then grows into multi-instance deployment.
• At that point, correctness and operational visibility become the hard part.
• I wanted a runtime that stays practical for small teams while scaling into distributed execution without changing core architecture.

How DurableStack compares to tools like HangFire

DurableStack and HangFire solve related problems, but DurableStack intentionally emphasizes a few design choices:

1) Built for distribution from day 1

• Lease ownership, reclaim behavior, and worker identity are first-class runtime concerns.
• The default mental model assumes multiple workers and rolling deployments.
• This keeps scaling behavior predictable instead of being an afterthought.

2) Free observability website

• You can connect runtimes to the hosted DurableStack observability site at no cost.
• This gives teams run visibility, failure insight, and trend data without building internal dashboards first.
• It is optional, but available immediately.

3) Uses only your existing database to coordinate runs

• DurableStack coordinates job execution using the database you already operate.
• Supported providers include PostgreSQL, SQL Server, SQLite, and MySQL.
• There is no required sidecar queue system to run the core runtime.

4) No new or external runtime dependencies required

• You do not need Redis, RabbitMQ, Kafka, or a separate orchestration service just to run jobs.
• Adoption can start inside an existing .NET service and existing deployment model.
• Optional integrations (observability, telemetry export) layer on top instead of becoming required infrastructure.

What this means for a future developer

• The runtime model is consistent from local development to distributed production.
• Operational behavior is explicit instead of hidden behind implicit infrastructure assumptions.
• The same codebase can evolve without introducing a second operational stack just for background jobs.