n8n vs Make vs Temporal: choosing a fulfilment backbone

It is Friday 18:00 in Eindhoven and the dispatch board at a 28-person AV-rental company shows 312 events going out Saturday morning. Rigging trucks are loaded. The Sunday tear-down picking-lists, however, have not generated. The operations lead phones the developer. The developer is on a beach in Greece.

That phone call is the question this post is about. Their fulfilment automation runs around 4,200 events a day at peak. A signed quote triggers a picking list, the picking list assigns a crew, the crew check-in fires a damage scan, the return drives a re-stock workflow, and somewhere in that chain an invoice gets sent. When any link breaks at 23:00 on a Saturday, somebody pays. The question is which "somebody."

We have built or rescued versions of this stack three times in the last eighteen months. Each time the choice came down to the same three tools: n8n self-hosted, Make.com, and a hand-rolled Temporal worker pool. Below is how we score them on the three numbers that matter when your operations lead is staring at the dispatch screen on a Saturday: weekend reliability, audit log, and who pays per execution.

What the work actually is

Before the tools, the work. A typical event in this stack runs eight to twelve discrete steps. A signed quote arrives from the contract module. A picking list generates against warehouse inventory. A van and driver get assigned from a calendar. A check call is scheduled two days out. On the day, scan-in events from field tablets update stock counts. Damage flags spawn a Slack thread to the warehouse lead. The tear-down workflow mirrors the same machinery in reverse. A pro-forma invoice fires once the gear is back and scanned clean.

That is the unit of work. Multiply by 312 events on a busy Saturday, factor in the previous week's returns trickling back, and you land around 4,200 events in a 24-hour window, each fanning out into a handful of step-executions. Some take seconds. Some wait two days for a human signal. All of them have to survive a process crash, a network blip, and the developer being away from a laptop.

n8n self-hosted

n8n is a Node-based workflow engine you host yourself. You draw flows in a visual editor, the engine executes them, and the resulting state lives in a Postgres database you own. Workflows trigger on webhook, schedule, or polling.

For an AV company with five core flows and a handful of integrations, n8n self-hosted is the cheapest option per execution, at zero. The runtime is yours, and a €40-per-month Hetzner box handles their peak comfortably when set up with queue mode and a Redis worker.

Queue mode is the part most teams skip and regret. By default n8n runs everything in the main process. At bursty Saturday peaks the main process becomes a single point of failure. We always set it up the same way: main process for the editor and webhooks, a separate worker container consuming a Redis queue, all state in Postgres.

Audit log is decent but not court-grade. Every execution is logged with input, output, and timestamps. The retention window is whatever your database can hold. With a sensible index you can answer "what happened to event #4218 last Saturday at 22:47" in about ten seconds. The catch is that n8n's default retention is effectively "keep everything," and a 200GB Postgres volume fills in roughly three months at this volume. Add a pruning cron on day one or your weekend workflows will start failing silently in May.

The bigger catch is operations. Every n8n upgrade is your problem. Every Postgres backup is your problem. Every "the workflow stopped firing at midnight because the disk filled with execution logs" is your problem.

Make.com

Make (formerly Integromat) is the SaaS pole star. Visual editor, deep library of connectors, scenarios trigger on schedules, webhooks, or watchers. Their billing meter is the "operation," which roughly maps to one node firing once in one scenario run.

The reason Make tops most short-lists is that the first six weeks are bliss. You host nothing. Connectors for Twinfield, Exact, Slack, Google Calendar, and Microsoft Graph are already written and tested. Build the first workflow on a Tuesday, demo it to operations on Wednesday.

The reason Make ends up replaced is the operations bill. The AV company did the math: 4,200 events a day at an average of nine operations per workflow run lands around 1.13 million ops a month. Make's standard tiers cap in the tens of thousands of operations a month; at over a million you are talking to enterprise sales. The forecast they got back was meaningfully north of €1,000 a month including seats, and it grew linearly with their business.

Audit log is strong for the recent past, thin for the distant. Scenario execution history is fully queryable in the app, but retention is measured in weeks on standard plans. If a customer disputes an invoice in October that was triggered in May, you are reconstructing from secondary sources.

Weekend reliability is Make's problem, which is genuinely the right answer for most teams. They have a status page, they have on-call. Outages happen and they are rare. There is one specific failure mode worth knowing: webhook scenarios silently consume operations even when the downstream system is dead. We saw a client burn through eleven thousand operations in a weekend retrying against a Slack channel that had been archived. The retry budget is on you.

Temporal worker pool

Temporal is a workflow engine for code, not pictures. You write your workflow in Go, TypeScript, Python, Java, or .NET; the Temporal server records every event in a durable history; worker processes pick up tasks. If a worker dies mid-workflow, the next worker resumes from the last recorded event. State machines, retry policies, sleep-for-days timers all live in the same file.

Here is a sliver of the tear-down workflow in TypeScript:

import { proxyActivities, sleep, defineSignal, setHandler } from '@temporalio/workflow'
import type * as activities from './activities'

const { generatePickList, assignCrew, scanReturn, postInvoice } =
  proxyActivities<typeof activities>({ startToCloseTimeout: '5 minutes' })

const damageReported = defineSignal('damageReported')

export async function teardownWorkflow(eventId: string) {
  const list = await generatePickList(eventId)
  const crew = await assignCrew(list, { window: '24h' })

  let damaged = false
  setHandler(damageReported, () => { damaged = true })

  await scanReturn(eventId, crew)
  if (damaged) {
    await sleep('2 days') // wait for warehouse triage
  }
  await postInvoice(eventId)
}

The sleep('2 days') is the line that does not exist honestly in n8n or Make. The process can restart, the server can be patched, the worker can be swapped out, and the workflow still wakes up two days later in the same state with the same variables in scope.

Audit log is the killer feature. Every step, every retry, every signal, every input, every output is in the event history. You can replay a 2024 workflow against its original inputs in 2026 and get the same outputs, byte for byte. For a company whose customers occasionally dispute scope of work six months later, that property is worth real money. The same property lets a junior engineer answer "why did event 1847 end up assigned to van seven" in five minutes with no production access.

Per-execution cost is server cost. Temporal Cloud bills per action; for 4,200 events a day, retention dependent, the bill lands in the €200 to €400 a month range plus your own worker compute. Self-hosting on Postgres or Cassandra is cheaper at scale and more work to run.

The catch is that somebody has to write code. n8n and Make let an operations lead build a workflow. Temporal needs a developer who can commit to a repository. There is also a third cost that does not show up on any invoice: the gap between your operations team and your code. Make and n8n keep the workflow in the visual language operations already speaks. Temporal moves it into a repository, which means changes go through pull requests, which means the operations lead now files a ticket instead of editing a flow. Some teams prefer that trade. Most do not.

One more gotcha worth flagging: Temporal worker memory is sneaky. Long-running workflows that hold large objects in scope across a sleep balloon worker RAM. The fix is to keep workflow state tiny and push everything heavy into activities.

How we would score it for a 28-person company

For the AV-rental company specifically we landed on n8n self-hosted with queue mode, a managed Postgres at Aiven, and a separate read-replica Postgres for execution-history archival beyond 90 days. All-in cost ran around €120 a month. The dev hire that Temporal would have needed became a part-time ops contractor who could maintain the workflows visually.

If their business doubles, the answer changes. At 8,000 events a day the n8n setup needs three workers and a serious Redis. At that point the operational delta between "we run n8n" and "we run Temporal" shrinks, while the engineering payoff (provable audit, six-month time-travel debugging, code-versioned workflows) grows. We told them to plan that switch for 2027.

If they had been in a regulated industry, pharma logistics or financial-services back-office, we would have skipped n8n and started with Temporal on day one. The audit log alone justifies it.

Make never won the comparison once we factored in operations bills past month four.

What to do tomorrow morning

When we built the fulfilment backbone for the AV-rental crew, the part that ate the most time was not the workflows themselves. It was wiring n8n's execution history into a separate read replica so their bookkeeper could pull audit records older than ninety days without touching the live engine. We ship that pattern as part of our automation and AI agents work because every operations team that survives a year eventually asks the same question.

The five-minute audit you can do this morning: open whichever tool you are already running, find the busiest scenario from last Saturday, and check how far back the execution history actually goes. If you cannot answer "what did this workflow do on the second weekend of last year," your audit log is shorter than your business needs.