Hatchet shipped 12 release events in 30 days and 30 GitHub releases in 90 days. The noisy part is not just the volume. Six of the recent CLI releases landed on April 28 alone, which points to a team pushing packaging and developer workflow changes in tight loops.

The product pitch has also moved beyond plain background jobs. Hatchet’s website now calls it an orchestration engine for AI agents, background tasks, and mission-critical workflows. The GitHub README says the same thing, with support for Python, TypeScript, Go, and Ruby, plus Cloud and self-hosted deployment paths.

That matters because Hatchet is competing less like a job queue and more like infrastructure for durable execution.

The docs frame durability as the core bet. Hatchet persists task and agent invocations, then uses that event log for retries, replays, debugging, and workflow recovery. The durable execution docs are explicit about checkpointing completed work so a crashed worker can resume from the last checkpoint instead of rerunning everything.

That is a useful pitch for AI agents, where runs can be long, expensive, and full of side effects. If an agent sends an email, calls an API, waits for a human, or fans out child tasks, naive retries get ugly fast. Hatchet’s answer is to make the workflow state durable and observable.

The CLI cadence reinforces that developer-experience work is active. The v0.83.55 and v0.83.60 release pages are mostly templated CLI release notes, so they do not prove feature depth by themselves. They do confirm a stream of signed GitHub releases with install paths for curl, Homebrew, and manual binaries.

The CLI docs add more useful context. The Hatchet CLI is still marked beta, but it includes quickstarts, local worker reloading, a terminal UI for observability, and profiles for switching between Hatchet instances and tenants. That is exactly the surface area a team would polish if it wants developers to run workers locally, inspect executions, and move between local, cloud, and self-hosted environments without friction.

Hatchet is OSI-approved open source under MIT. The repository license matches the ToolVitals openness signal. That distinction matters here because Hatchet is not just publishing an SDK around a hosted product. The docs describe self-hosting the control plane, including API server, engine, PostgreSQL database, optional RabbitMQ, and dashboard.

What ToolVitals can and cannot infer

ToolVitals can say Hatchet is active. The data shows a 99 ToolVitals score, 98 health score, 100 shipping score, 198.7 hot score, 7,215 GitHub stars, 12 release events in 30 days, and 30 GitHub releases in 90 days. Data confidence is 99.

ToolVitals cannot say Hatchet is the best durable execution engine. It cannot see code quality, operational correctness, user satisfaction, revenue, support quality, or whether the product behaves well under your workload. It also cannot infer the content of each release from templated CLI notes.

The conservative read is strong enough: Hatchet is maintained aggressively, has a clear current positioning around AI agents and durable workflows, and exposes both hosted and self-hosted paths.

How it compares

Inside the related automation set, Hatchet looks materially larger than Tracecat by GitHub stars, 7,215 versus 3,613, while also shipping more release events in the last 30 days, 12 versus 8. Tracecat’s shipping score is still high at 98, so this is not a sleepy competitor comparison. Hatchet just has the stronger activity profile in this snapshot.

FakeCloud is closer on release pace with 11 release events in 30 days, but it has 302 GitHub stars versus Hatchet’s 7,215. That makes Hatchet’s signal more interesting: it combines active release flow with a larger public developer footprint.

Pulumi is the heavyweight comparison in the related data, with 25,239 stars and 17 release events in 30 days. Different category, different product shape, but useful calibration. Hatchet is not matching Pulumi’s public scale, yet its shipping score is the same 100.

Recommendation

If your team is building background jobs that increasingly look like workflows, especially AI agents, human-in-the-loop flows, or long-running task graphs, evaluate Hatchet now. The reason is concrete: the project is MIT-licensed open source, self-hostable, actively released, and explicitly designed around durability rather than treating retries as a bolt-on.

Do not pick it just because the release count is high. Use that as the reason to test it. Put one failure-prone workflow through Hatchet, crash a worker mid-run, inspect the replay behavior, and decide from evidence.

Sources