Motia

Last reviewed Aug 26, 2026 · 769 words

One Motia project replaces the four things a typical backend grows into separately: an HTTP API, a job queue, a scheduler, and whatever framework the AI agent lives in. Everything is a step, a file that declares what triggers it (an HTTP route, an event topic, a cron schedule) and which events it emits; the runtime wires the graph together and shows it to you in a built-in Workbench with a trace per request. It is young (2024), MIT licensed, has 18,628 stars, and the lock-in it asks for is real. But if you are about to bolt a queue library onto Express and then start a second service for the LLM part, Motia is the one-folder version of that stack.

A step is a file with a config and a handler

// steps/order-created.step.ts
export const config = {
  type: 'event',
  name: 'OrderCreated',
  subscribes: ['order.created'],
  emits: ['invoice.requested'],
  flows: ['orders'],
}

export const handler = async (input, { emit, logger, state }) => {
  await state.set('orders', input.id, input)
  logger.info('order stored', { id: input.id })
  await emit({ topic: 'invoice.requested', data: { id: input.id } })
}

Steps come in four types: api (an HTTP endpoint), event (runs when a topic fires), cron, and noop (a placeholder for an external system so the diagram stays honest). The same folder can hold Python steps next to the TypeScript ones; a Python step subscribes to the same topics and emits onto the same bus, which is the practical answer to "my agent code is Python but my API is Node". State, streams (for pushing live updates to a client) and logging are injected into every handler, so you are not picking libraries for them.

Workbench is the reason to choose it over hand-rolled queues

npx motia dev starts the runtime and the Workbench on port 3000: a live diagram of your flows, a log of every emitted event, and a trace for each request showing which steps fired and how long each took. This is the piece people normally assemble from a queue dashboard plus a tracing tool, and getting it for free at development time changes how you debug. For production I still ship traces somewhere durable; the Workbench is a development console, not a long-term store.

Self-hosting is a Node process plus Redis

Motia is a framework, so hosting it means hosting your app. The CLI's build step produces a deployable bundle; the plain route is a Node container that runs it, with Redis alongside once you leave the in-memory adapters that dev mode uses, since the project's production adapters back state, event delivery and streams with Redis. A 512 MB container is enough for the runtime; your steps set the real budget, especially if they hold LLM clients or embedding models. Put the API steps behind your usual reverse proxy like any other Node service. The vendor's Motia Cloud is optional and nothing in the self-hosted path requires an account.

Where it sits next to n8n, Temporal and Windmill

This is not a low-code tool. n8n gives non-developers a canvas; Motia gives developers a file layout and expects tests. Against Temporal it is lighter and less rigorous: Temporal guarantees durable execution of long workflows across crashes and is a serious piece of infrastructure to run; Motia's steps are ordinary event handlers with retries, which is enough for most application backends and not enough for a payments saga that must survive a datacentre loss. Windmill is the closest cousin, with polyglot scripts and a UI, but leans toward internal tooling and scheduled scripts rather than being the app server itself. The agent angle is where Motia is most distinct: an agent is just steps that call a model and emit events, which matches the patterns in agent architectures better than most agent frameworks' bespoke loops.

What I'd do

Reach for Motia on a new backend that will have all three of an API, background work and an LLM in the loop, and keep it in one repository with Redis as the only extra service. Do not migrate a working Express or FastAPI app to it; the win is in not building the plumbing, and you already built it. Keep business logic in plain functions the step handlers call, so the day you outgrow the framework the exit is mechanical. And be honest about durability: if a failed step must never be lost, Temporal or Hatchet is the tool, and Motia is the thing that calls it.