{"slug":"tako-vs-inngest-and-trigger","url":"https://tako.sh/blog/tako-vs-inngest-and-trigger/","canonical":"https://tako.sh/blog/tako-vs-inngest-and-trigger/","title":"Tako vs Inngest and Trigger.dev","date":"2026-04-16T00:47","description":"Inngest and Trigger.dev gave JavaScript a durable-step model worth copying. Tako ships the same primitives embedded in the server that already runs your app — no separate queue service, no per-run bill.","author":null,"image":"7be9245001bf","imageAlt":null,"headings":[{"depth":2,"slug":"at-a-glance","text":"At a glance"},{"depth":2,"slug":"what-inngest-and-triggerdev-get-right","text":"What Inngest and Trigger.dev get right"},{"depth":2,"slug":"where-tako-is-different","text":"Where Tako is different"},{"depth":3,"slug":"its-not-a-service--its-a-feature","text":"It’s not a service — it’s a feature"},{"depth":3,"slug":"the-billing-unit-is-you-already-paid-for-the-box","text":"The billing unit is “you already paid for the box”"},{"depth":3,"slug":"same-primitives-smaller-surface","text":"Same primitives, smaller surface"},{"depth":2,"slug":"different-ambition","text":"Different ambition"}],"markdown":"Every app eventually grows a background-work problem, and for the past few years the best answer in JavaScript has been <a href=\"https://www.inngest.com\" target=\"_blank\" rel=\"noopener noreferrer\">Inngest</a> or <a href=\"https://trigger.dev\" target=\"_blank\" rel=\"noopener noreferrer\">Trigger.dev</a>. Both teams made durable steps, retries, crons, sleeps, and signals feel ordinary — you write async code, and the platform handles crashes, restarts, and \"wait three days for a human to approve.\" That's a genuinely nice developer experience, and [Tako's new workflow engine](/blog/durable-workflows-are-here) borrows the shape of it on purpose.\n\nThe difference is where the engine lives.\n\n## At a glance\n\n|                       | **Inngest**                                 | **Trigger.dev**                             | **Tako**                                 |\n| --------------------- | ------------------------------------------- | ------------------------------------------- | ---------------------------------------- |\n| **Deployment model**  | SaaS (self-host available)                  | SaaS (self-host available)                  | Embedded in your app's server            |\n| **Durable primitive** | `step.run`, `sleep`, `waitForEvent`         | `retry.onThrow`, `wait.for`, schedules      | `step.run`, `step.sleep`, `step.waitFor` |\n| **Queue storage**     | Hosted (self-host: multi-service stack)     | Hosted (self-host: Postgres + Redis + more) | Per-app SQLite file on your VPS          |\n| **Billing unit**      | Per execution (~$0.00005/exec on Pro)       | Per-second compute + per-run                | None — runs on a box you already own     |\n| **Free tier**         | 50k executions / month                      | $5 monthly credits                          | Unlimited                                |\n| **Self-host effort**  | Separate stack (queue, executor, state, UI) | Docker Compose or Helm stack                | Zero — it's already in `tako-server`     |\n| **Open source**       | Yes (5.2k stars)                            | Yes, Apache 2.0 (14.6k stars)               | Yes, part of Tako                        |\n\n## What Inngest and Trigger.dev get right\n\nBoth companies deserve real credit. Inngest's team basically introduced the \"TypeScript-native step functions\" category to a generation of devs who'd never heard of Temporal. Trigger.dev pushed the ergonomics further — per-task machine sizing, a beautiful dashboard, Realtime, and, as of v3, a proper open-source license.\n\nThe SDK primitives they landed on are the right primitives. `step.run` for memoized side effects, durable sleep for long waits, event-driven pauses — this vocabulary is now the default way JavaScript developers reason about durable work, and we adopted the same vocabulary in Tako on purpose. If you know one of their SDKs, our [workflows docs](/docs/tako-toml) should feel familiar within ten seconds.\n\nIf you want a hosted workflow platform with dashboards, observability tooling, and someone paged when the queue gets backed up at 4am, those are the two names to look at first.\n\n## Where Tako is different\n\n### It's not a service — it's a feature\n\nInngest and Trigger.dev are workflow platforms. Even self-hosted, you're running _another system_ next to your app: Inngest self-hosting is a multi-service install (event API, runner, executor, state store, dashboard); Trigger.dev's self-host is Postgres + Redis + web + workers wired together with Docker Compose or a Helm chart. That's fine — it's what a full workflow platform requires.\n\nTako's workflow engine lives inside `tako-server`, the same process that already runs your app's HTTP proxy, TLS, and scale-to-zero supervision. The queue is a single SQLite file at `{tako_data_dir}/apps/<app>/runs.db`. The worker is a subprocess. The protocol is a unix socket. There is no second thing to deploy, monitor, or upgrade — [`tako deploy`](/blog/what-happens-when-you-run-tako-deploy) ships your HTTP handlers and your `workflows/*.ts` files in the same release.\n\n```d2\ndirection: right\n\nsaas: SaaS workflow platform {\n  direction: down\n\n  app: Your app\n  net: Internet\n  queue: Managed queue + dashboard\n  worker: Hosted workers\n\n  app -> net: enqueue\n  net -> queue: persist\n  queue -> worker: dispatch\n  worker -> net: results\n}\n\ntako: Tako {\n  direction: down\n\n  app: Your app\n  server: tako-server\n  db: runs.db (SQLite)\n  worker: Worker subprocess\n\n  app -> server: unix socket\n  server -> db: persist\n  server -> worker: supervise\n}\n```\n\n### The billing unit is \"you already paid for the box\"\n\nInngest charges per execution — each step counts as one. Trigger.dev charges per-second compute plus a per-run fee. Both are fair pricing for a hosted service, and both scale gracefully for small projects. But it's a per-run meter on every `step.run` your code executes, forever.\n\nTako's workflow engine runs on the VPS you were going to pay for anyway. The marginal cost of one more workflow run is the CPU it uses. Enqueue a million a day; the bill doesn't move.\n\n### Same primitives, smaller surface\n\nWe kept the API to the handful of things that actually matter: [`step.run`, `step.sleep`, `step.waitFor`, `signal`, and cron via `defineWorkflow`'s `schedule` option](/docs). That's enough to express retries, long waits, human approvals, fan-out, and scheduled jobs. You can read the full contract in [SPEC.md](https://github.com/lilienblum/tako) in one sitting.\n\n## Different ambition\n\nInngest and Trigger.dev are workflow platforms with big roadmaps — AI agents, realtime, fine-grained observability, managed cloud. If your whole job is background work at scale, a dedicated platform is a reasonable bet.\n\nTako is building the other direction: [the platform layer between your code and the internet](/blog/durable-channels-built-in), with workflows as one feature among [channels](/blog/durable-channels-built-in), [secrets](/blog/secrets-without-env-files), [local dev](/docs/development), deploy, proxy, and TLS. All of it runs from one `tako-server` on one box, with a single config file. No queue vendor, no dashboard login, no per-run meter — just a keyword called `step`.\n\nIf you already love Inngest or Trigger.dev, keep loving them. If \"one more vendor for this\" is the thing that's been pushing you toward a different approach, [give Tako workflows a try](/docs/cli)."}