we just migrated our gRPC services to the ConnectRPC protocol instead. this turned out to be a fairly simple migration, but unlocks a whole bunch of new features for Hatchet in the next few months. gRPC is fantastic, but support across runtimes isn't great. in particular, we've had a bunch of requests for serverless runtimes like @Cloudflare Workers which we haven't been able to support because of gRPC compatibility issues. the original serverless runtimes were built around the fetch() API, which is missing a bunch of http/2 features that we need. we've been quietly waiting on gRPC support across these runtimes -- and Cloudflare just rolled it out in beta! -- but demand was high enough that we're just sending it. The great part about ConnectRPC is that it's fully gRPC compatible, so existing clients will still work. Just a 10/10 dev experience overall: connectrpc.com/ full serverless and sandbox support coming soon.

Here's a look behind the scenes at our team offsite in Cape Cod last week! ⛵️🚲🦞🎄🌊 (Not shown here: @igor_kupczynski trying a lobster roll for the first time, loving it, and then ordering a second, third, fourth, etc.)

Here's a look behind the scenes at our team offsite in Cape Cod last week! ⛵️🚲🦞🎄🌊 (Not shown here: @igor_kupczynski trying a lobster roll for the first time, loving it, and then ordering a second, third, fourth, etc.)

for our offsite hackathon, i created hatchet.run/bananas it is bananas 🍌

for our offsite hackathon, i created hatchet.run/bananas it is bananas 🍌

We got these @useTRMNL e-ink displays for the Hatchet hackathon, and naturally @mnafees and I wanted to get these running as Hatchet workers. Initially we tried to get a vibe coded C SDK running. This worked, but the esp32-c3 processors only have 400kb of RAM, so we were limited to spawning tasks with payloads <25 chars. So instead we started playing around with a new feature in Hatchet called operators, which lets you turn anything that can run an HTTP server into a hatchet worker. This isn't natively supported on TRMNLs, but modifying the firmware to add /heartbeat and /trigger endpoints was very easy. Obviously, the next step was sending base64 images, and then playing Bad Apple at around 1 fps. Had to do some more firmware shenanigans to disable "full refresh" to get below .3fps, but it ended up working pretty nicely.

Congrats to the Temporal team on the raise! One thing that's become pretty clear from being really deep in this space: there was a moment between mid-2025 - early-2026 where it seemed like agent state should be offloaded entirely to a durable workflow. It's pretty clear from this announcement that this is the trend that Temporal is riding in this raise, and in large parts helped create. This is no longer the case. The durability layer for agents is shifting very significantly from durable workflows towards filesystems. Frankly, durable execution is far to expensive and has far too much overhead for the types of agents we're seeing these days. That doesn't mean that durable workflows aren't involved in the agent lifecycle; the concept of a durable session manager which orchestrates agent turns / sessions is still an important architectural concept. It just means that it's a much smaller part of agent state. (granted, there are cases where a fully i/o bound agent with remote tool calls should use durable execution, but that's not the trend we're seeing in more powerful agentic stacks. they trend towards sandboxes.) We have a very different view on the orchestration space. The bet that we're making with Hatchet is: - Deep integrations with sandbox providers built on durable filesystems - Durable streams - Built-in observability features for self-improving agents - Agents being able to easily run and manage deterministic tools and workflows which run on distributed compute - An open orchestration layer which you can easily extend for your own use-case and runtimes -- whether you're running on Kubernetes, a Cloudflare stack, Vercel, or anywhere else We started building towards this vision about a year ago. We've shipped a ton & have lots of new features coming this fall @hatchet_dev

One of the really surprising things we've iterated towards with Hatchet is a lock-free, single-threaded scheduler for each tenant. I started reading up on @TigerBeetleDB recently and it's remarkable how many commonalities there are. The first one is that this works because the core workload is inherently contented (queues in our case, accounts in the TigerBeetle example). By design, queue items compete for slots on workers, rate limits, and global concurrency rules. Being able to configure these types of "global" scheduling rules are a core part of the developer experience when using Hatchet and compared to queues like Celery. But the more workers, rate limits, and queues you add, the greater a chance of a collision between queues, which means that running each individual queue in its own goroutine (which we used to do) just leaves you waiting around for >10ms waiting on other queues to schedule. And you need locking in some capacity (or you move the locks to a different coordination layer like messaging), but means lots of threads are just waiting on lock frees. The single scheduling thread is the "hot path," so obviously you can't be doing things like reading from a database on the hot scheduling path; it adds too many milliseconds of latency. So instead, database writes are batched and sent from the scheduler in chunks. This is very similar to the TigerBeetle architecture of amoritizing the overhead by batching at many layers. It's a similar story for reads; we can parallelize reading from many queues at a time, so we do spawn a pool of goroutines in that case, and pass them into the scheduler over a channel. The core insight here is that you can easily get to hundreds of thousands of schedules / second on this single thread, to the point where it's not even close to the bottleneck in the system. When we rolled this out, it also massively reduced CPU on our schedulers. And the primary benefit is that you have a single thread which is managing all scheduling state, and you have simple reads and writes on the other side. There are of course a bunch of differences; we're a Go shop, we're not statically allocated at startup, we use Postgres to store durable state, etc. But this part of the workload in particular has a bunch of similarities. Some more reading on TigerBeetle here: github.com/tigerbeetle/tiger…

New Feature: Workflow Pause → Temporarily stop a workflow from executing new runs → While the workflow is paused, new runs will automatically queue up to a queue TTL and all in-flight runs continue to run Read the docs: docs.hatchet.run/v1/pausing-…

Our designer (the fantastic @grazsebastian) built us an entire animation engine. It uses the native `requestAnimationFrame` and CSS under the hood. A good visualization is worth a ton, and I've always wanted an easier way to create them for the Hatchet website and docs. For a while I'd import Figma components into jitter.video, which was a great tool but would be very time-consuming. Then I experimented with Claude to generate animations, but they all had a certain smell to them (dark background, rounded corners, bold green/orange/red borders with low opacity backgrounds, the same sans font, etc). Even prompting / passing in our stylesheets or branding page only helped marginally. So we built our own simple animation engine, with a component called `Flow` and `Sequence`. We still primarily generate these through Claude, but they use our brand components, fonts, colors, etc. I usually provide an extremely specific prompt of exactly what I'm looking to animate (and we verify the animations heavily against docs). It's really nice that the Flow component doesn't rely on React render loops or external libraries -- they're entirely native and well-supported across a bunch of different browsers and devices. Also fully open source: github.com/hatchet-dev/hatch…

I see a lot of talk about Postgres sharding, and I'd like to encourage people to consider a strategy where each shard is entirely self-contained (without needing a global router or query planner) before looking into a third-party sharding solution. This might not work for every application, but if you can pull it off, it'll make your system truly cellular and much more resilient. The difficulty is that typically, you need to replicate some tables between all of the shards. For lack of a better word, let's call these "Config" tables: things like tenants, memberships, organizations, settings, etc. We run >20 Postgres shards in 4 regions, and we have a few config tables which need to get replicated from our control plane into the shard. We replicate these with a set of lightweight @hatchet_dev workflows which implement a compensating / SAGA pattern. If the write on the shard fails, we simply roll back on the control plane. All of the edge cases around idempotency / network partitions / unreliable tasks are handled via Hatchet. This isn't a knock against the Postgres-specific sharding options like Neki and PGDog: those have lots of cool and interesting features. But making each shard self-contained has served us extremely well.

We're really excited to unveil Hatchet Embedded, now available for TypeScript, Python, and Go! 🔥🚀 Hatchet Embedded provides a lightweight way to run a full Hatchet engine inside of your workers, useful for local development, end-to-end testing, and CI.