Hatchet is an MIT-licensed, Go-based orchestration engine for background tasks, AI agents, and durable workflows, built for teams that need reliable queueing, retries, and observability while writing workers in Python, TypeScript, Go, or Ruby.

What it is

Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It provides a full stack for queuing, automatic retries, durability, real-time monitoring, alerting, and logging, and it can be consumed either as a managed service through Hatchet Cloud or as a self-hosted deployment. The engine is written in Go and released under the MIT licence, with client libraries covering Python, TypeScript, Go, and Ruby.

The concrete problem it addresses is the gap between a plain job queue and a system that must survive failure and stay observable. Hatchet replaces the ad hoc combination of a queue plus separate retry, scheduling, and monitoring layers by using Postgres as the durability layer for both the task runtime and the observability system. That single-storage design is what makes the project comparatively easy to self-host, and it keeps task state and monitoring data in one place an operator already knows how to run.

Key capabilities

• Background tasks defined as simple functions, supporting both fire-and-forget and fire-and-wait execution with subscriptions.
• Configurable retry policies for tasks, including optional exponential backoff.
• Cron jobs and scheduled runs for executing tasks at a point in the future.
• Task routing by strict conditions such as worker labels, plus weighted scheduling through worker affinity.
• Event-based triggering with listeners and durable event waits, alongside webhook-based triggering for upstream data sources.
• Durable tasks for fault-tolerant, long-running workflows that recover from failure, and DAG-based workflow orchestration.
• TypeScript client distributed as the @hatchet-dev/typescript-sdk package on npm, with the Go packages published under github.com/hatchet-dev/hatchet.

Who uses it and how

• Teams that need horizontal scalability and correctness for long-running workflows such as AI agent pipelines can define each step as a durable task and let Hatchet manage retries across workers.
• Python and TypeScript application teams can add Hatchet workers alongside existing services, since the topic list covers Python, TypeScript, Node.js, FastAPI, and Go.
• Deployment is split between Hatchet Cloud, which provides a fully deployed platform for evaluation, and a self-hosted option documented for production operators.
• Event-driven and distributed system builders can wire external sources through webhooks and events rather than polling, using durable event waits to suspend workflow progress until a signal arrives.
• Scheduled work such as recurring cron runs fits teams replacing hand-rolled schedulers, with routing rules directing jobs to specific workers by label or affinity.

Getting started

The documented local path installs the Hatchet CLI with curl -fsSL https://install.hatchet.run/install.sh | bash, verifies it with hatchet --version, and boots the stack with hatchet server start, which requires Docker installed locally. The README recommends signing up for Hatchet Cloud even when self-hosting is the eventual plan, so a fully deployed instance can be inspected first.

How it compares

The facts provided name no comparable or paid products that Hatchet replaces, so no like-for-like contrast can be drawn on licence, hosting, data ownership, or cost model. On that basis Hatchet stands alone in this registry among the products described in the supplied material, and the only internal distinction the README makes is architectural rather than competitive: its use of Postgres as the durability layer for both runtime and observability.

When to use it — and when not to

A self-hoster takes on running Postgres as the durability layer and Docker for the local server, so teams without database operations capacity should prefer Hatchet Cloud or a different tool. The project carries 135 open issues and the README excerpt is truncated mid-sentence in the workflow section, so anyone evaluating DAG orchestration should read the full documentation at docs.hatchet.run before committing. It suits teams that value correctness, reliability, horizontal scalability, and observability as requirements rather than extras, and it is a poor fit for anyone wanting a queue with no operational footprint at all.

curl -fsSL https://install.hatchet.run/install.sh | bash
hatchet --version
hatchet server start