finds.dev← search

// the find

Vanderhell/Basalt.NET

C · MIT · updated Sep 2026

Durable background job, scheduling and workflow engine for .NET applications with embedded and SQL Server storage.

Basalt.NET is a .NET background job/scheduler/workflow engine that runs either embedded (via a custom native C storage engine) or on SQL Server for multi-process coordination, using the same API either way. It's aimed at teams that want Hangfire/Quartz-style durable jobs without standing up a separate job server, including on .NET Framework/WPF apps.

The embedded-vs-SQL-Server split behind one API is a real design win — you can start single-process and move to a shared queue without touching handler code. The durability story is explicit rather than hand-waved: docs call out at-least-once semantics and the need for idempotent handlers, and there's dedicated support for leases/fencing for multi-process crash recovery. The embedded storage isn't a thin wrapper around SQLite — it's a hand-rolled file format with its own codec, CRC32 checksums, and locking (jobdb.c/jobdb_codec.c/jobdb_lock.c), backed by a fuzz test (fuzz_jobdb.c) and dedicated C unit tests, which shows real effort went into correctness at the storage layer specifically.

Zero stars, zero forks, and a very fresh push history — this is an untested, unvalidated project, and the riskiest part of it (a custom binary storage format with its own locking) is exactly the kind of thing that only gets proven correct after years of real crash/corruption exposure, not a fuzz harness alone. The management dashboard is a separate WPF app, so despite Basalt targeting .NET 8, there's no cross-platform or web way to inspect queue state — Linux/Mac users are locked out of the only tooling. Workflows are explicitly static DAGs with no conditional/dynamic branching, so anything beyond a fixed pipeline shape has to be modeled as multiple workflows. Embedded mode also ships a native interop layer (BasaltCore.Native/P-Invoke), which means per-platform native binaries and a harder debugging path than a pure-managed embedded store.

View on GitHub →

// want more like this?

We dig through GitHub every week and send a few repos picked for what you actually care about — each with an honest take like this one.

Get finds in your inbox → Search again →