Hatchet: Workflow Orchestration Engine
/hatchet
Hatchet coordinates background tasks, AI agents, and durable workflows, with its entire durability and observability stack backed by Postgres rather than a separate datastore. That keeps self-hosting lean: you get the web UI, OpenTelemetry, and Prometheus metrics without wiring together a broker and a time-series store. Reach for it if your services use Python, TypeScript, Go, or Ruby and you want durable execution without that operational overhead; skip it if raw throughput on a Redis queue matters more than persisted task history.
Understanding Hatchet's Orchestration Engine
A platform that coordinates background tasks, AI agents, and durable workflows for applications written in Python, TypeScript, Go, and Ruby. Postgres serves as the persistence layer for the task runtime and the observability system, so self-hosting requires no separate broker. Queuing, retries, durability, real-time monitoring, alerting, and logging come bundled in one deployable unit, available as Hatchet Cloud or self-hosted.
When to Choose Hatchet for Your System
- •Running AI agent pipelines that must resume after a worker crash instead of restarting from scratch, using durable tasks.
- •Replacing ad hoc cron scripts with scheduled runs that carry retry policies and full observability out of the box.
- •Building DAG-based data pipelines where you want to write your own integrations rather than rely on pre-built connectors, per the README's own guidance for choosing Hatchet over Airflow-style tools.
- •Self-hosting a task queue without operating a separate Redis or RabbitMQ broker just for durability.
- •Coordinating multi-tenant background processing where different teams need isolated visibility into their own tasks.
Core Capabilities of Hatchet
- ✓One-off background tasks defined as plain functions, supporting fire-and-forget calls and fire-and-wait calls with subscriptions.
- ✓Configurable retry policies with optional exponential backoff, plus cron jobs and scheduled runs for time-based triggering.
- ✓Durable tasks for long-running workflows that recover from failure, and DAGs for data-pipeline-style task graphs.
- ✓Task routing via worker labels or weighted affinity rules, with pause/resume via durable sleep and event waits.
- ✓Scale controls: priority ordering, rate limiting including per-user dynamic limits, concurrency-based fair scheduling, and worker slots that cap how much work a single worker accepts.
- ✓Real-time web UI for monitoring, with OpenTelemetry and Prometheus metrics built in rather than added separately.
- ✓Multi-tenancy by default with users and roles; one Hatchet instance can serve multiple teams without separate deployments.
Getting Started with Hatchet
The fastest path, per the README, is signing up for Hatchet Cloud even if you plan to self-host later — it's the quickest way to see what a fully-deployed instance looks like. To run locally, install the Hatchet CLI on MacOS, Linux, or WSL, which requires Docker: curl -fsSL https://install.hatchet.run/install.sh | bash hatchet --version hatchet server start Full self-hosting and cloud documentation lives at docs.hatchet.run.
Hatchet Compared to Other Platforms
Strengths
- ✓Using Postgres for both the task runtime and the observability system means self-hosting skips a separate broker or time-series store — the README calls this out as a key self-hosting advantage.
- ✓One orchestration engine covers four languages (Python, TypeScript, Go, Ruby), letting polyglot teams share the same queue and observability layer instead of running one per language.
- ✓Monitoring is built in from day one: real-time web UI, OpenTelemetry, and Prometheus metrics ship with the platform rather than requiring separate tooling.
- ✓Scale controls are granular — worker affinity, dynamic per-user rate limits, concurrency-based fair scheduling, and worker slots — which matters once multiple task types compete for the same workers.
- ✓MIT license imposes no copyleft requirement if you embed or modify the code.
Considerations for Using Hatchet
- △The README acknowledges higher resource use than Redis- or RabbitMQ-backed queues; load-tested to 10k tasks/second, but a pure in-memory broker will still outperform it on raw throughput.
- △Native SDKs are Python, TypeScript, Go, and Ruby only — no Java or .NET SDK is mentioned, so JVM or .NET teams would need to call it over HTTP.
- △The quick-start assumes Docker; non-Docker or bare-metal self-hosting paths aren't documented in the README.
- △Cloud pricing beyond "autoscaling and pay-as-you-go plans" isn't spelled out in the README, requiring direct inquiry before budgeting.
Common Questions About Hatchet
Hatchet supports applications written in Python, TypeScript, Go, and Ruby, per the README, allowing polyglot teams to share one orchestration engine across services.
Hatchet can be self-hosted or run as the managed Hatchet Cloud service; the README recommends trying Hatchet Cloud first, even for self-hosters, to see what a fully-deployed instance looks like before setting one up yourself.
Hatchet's durable tasks are pitched as a drop-in replacement for Temporal or DBOS workflows, with OpenTelemetry observability built in. Against Celery or BullMQ, the key difference is persistence: Hatchet keeps full execution history in Postgres instead of only holding tasks on the broker while they run.
Hatchet is released under the MIT license, so there's no copyleft requirement if you embed or modify the code.
Hatchet ships a real-time web UI for monitoring, plus OpenTelemetry support and Prometheus metrics, per the README's feature list.
Hatchet Cloud is the managed, hosted version of Hatchet; the README lists autoscaling, pay-as-you-go plans, multi-region deployments, SSO, and improved performance for monitoring, logging, and observability as distinguishing features.
The problem it solves
Celery- and BullMQ-style queues keep jobs on a Redis or RabbitMQ broker only while they run, losing the ability to replay or debug once a task finishes. Airflow-style DAG platforms, by contrast, are built for data engineers connecting to common datastores rather than high-volume application traffic. Teams running AI agents and background tasks have needed to pick one side. Hatchet addresses this by persisting full execution history in Postgres so you get replayable tasks and durable workflows without a separate broker or observability stack.
Who should try it — and who should skip
Try Hatchet if your team already runs Python, TypeScript, Go, or Ruby services and wants durable execution — retries, DAGs, cron, event triggers — without operating a separate broker and observability stack; the Postgres-backed design keeps the self-hosted footprint small. Skip it if you're on the JVM or .NET without an HTTP integration strategy, or if your workload needs more throughput than a durable system can deliver.
Related repositories
Is hatchet worth your time?
ChatGPT, Claude and Perplexity can all read this page. Ask one of them what it makes of hatchet.