Skip to content

Palumb vs Novu: notification workflows that stay in your own code

Written in your own repository, rendered by your own template engine, delivered through your own provider. The delivery path is open source, and the service is operated in the European Union under EU law alone.

Join the beta Jump to the comparison

Free up to 500 runs a month, and the beta is that free plan, so there is nothing to expire.

Notification orchestration you stay in control of

Novu: The other self-hostable one, and the closest thing we have to a mirror. Bigger product, EU regions, and a company outside the Union.

Palumb executes the notification workflows you write, and takes nothing else. There is no builder to define them in, no template system to adopt and no sending pool to share: the workflow is a function in your repository, the message is whatever your own engine rendered, and it leaves on your own provider credentials. What Palumb runs is the part that is genuinely hard: resolving who should be told, executing steps durably across days and deploys, and keeping the record of every attempt.

Why teams pick Palumb

  • Workflows in your repository, not Palumb's
  • No lock-in: your template engine, your provider
  • Open source, and free to self-host
  • One EU jurisdiction, nothing to authorise

What Novu asks you to accept

Every line comes from Novu's own documentation, checked on .

Code-first, if you write JavaScript

Novu Framework defines workflows in code: the same model Palumb uses, so this is not the difference. It is also only JavaScript: all nine quickstarts are JS runtimes, and their Python, PHP, Go, Java and .NET SDKs “trigger workflows, manage subscribers” rather than define them. Ours is declared for seven: TypeScript, PHP, .NET, Python, Go, Java and Rust.

There is still a sync step

Their docs call it GitOps and say the source of truth is your git. Fair. But you deploy the bridge, then run novu sync against it from your CI, and a Development environment exists so “your non-technical peers can view and modify controls”. Here, deploying your application is the whole of it.

Cheaper per run, dearer per plan

Their rate is lower, and that is worth saying plainly. But 20 workflows, 3 team members, 2 environments, 24 hours of history and their watermark are all on the free plan, and lifting them means Team, at $250. A product with forty kinds of notification is a $250 plan there and a €49 one with Palumb.

The open-source build is not the product they sell

Self-hosted Novu has no RBAC, no MFA, no environment variables, no more than two environments, no branding removal and no email activity tracking (their matrix, not Palumb's reading of it). They call it “how you test and experiment”. Palumb's is the same build in the cloud and on your own servers, because nothing is held back.

Ten VMs on their own sizing, three services on ours

Their published production sizing: three VMs each for API, Worker and WS, one for the dashboard, two Redis clusters at 8 GB, a MongoDB cluster at M20 or higher, and S3. Palumb is three services: the application, Restate and Postgres.

Novu is an Israeli company, and a region does not change that

Novu is operated by Noti-Fire Apps Ltd., company 516509775, Derech Ben Gurion 132, Ramat Gan, named in their own privacy policy. A regional endpoint moves where the bytes sit; it does not move the company. Behind Palumb is a natural person in Italy: no parent, no group to be reached through.

Palumb runs the workflow, and touches nothing else

The parts it runs are the ones that are easy to promise and slow to get right: waits survive a deploy, retries do not hammer the provider, and every attempt leaves a record.

The full list is here.

A workflow branching into the three ways time enters it, all three of them steps in its body: gathering events until Monday, a durable delay of three days, and waiting for a shipped signal.

Gathering, waiting, or sleeping for days.

A run can gather what arrives until an instant your code names, stay alive through hours or days without losing its place across a crash or a deploy, or pause until your app sends a signal or the timeout fires.

Any sending provider.

Send through the channel a workflow needs (Email, SMS, Telegram, Slack or push), each on your own sending provider, never pooled with anyone else's.

Fan-out.

Subscribe a recipient to a topic once; every trigger on that topic reaches everyone still on it, each with their own run. No loop you write yourself.

However you reach it.

Open the dashboard to look, call the REST API to build on it, or point your own AI agent at the MCP server. Same data, three ways in.

Tried, tracked, never twice.

A failed send is retried on a schedule that backs off, a retry never duplicates one that already went out (it carries the same Message-ID), and every attempt ends up in the record: accepted, failed or bounced, with the reason.

Three events reach one POST /sendEvent: comment.added, task.assigned, deadline.soon. It collects them into a single digest document with three entries and one email.

Digests.

Each event becomes one item in a digest that builds up over a window; when it closes, every item goes out in one notification, not one message per event.

Four template syntaxes stacked: a Handlebars tag, a React Email component, an MJML tag, and a plain template string.

Any template engine.

Keep the template engine you already use: MJML, React Email, Handlebars, or a plain string. Palumb never renders; it only delivers what you hand it.

Just write the workflow

A workflow is a function in your codebase. Our SDK gives it durable steps (a send, a wait on the clock, a pause until something happens in your product), and each one survives a crash and a deploy. There is nothing to define in a dashboard, and no copy of it on Palumb's side to drift from yours.

Three stacked boxes in one column, joined by a rail. Nothing travels along the rail. Instead the stretch of rail between two boxes fills, from the caller down to the one being called, holds while that one works, and then drains back the way it came. The fill is always the same grey, the ink of the Palumb mark: the line belongs to Palumb, and which end it starts from already says who placed the call.

At the top yourapp.com/backend, your own application, with the calls it makes into Palumb: trigger, for the orderPlaced workflow on topic.order-24, and days later sendEvent, for the order.shipped event. Each call is marked with a small square that fills in once Palumb has it, and appears only when it happens, so nothing is on screen before you make it, and the rail below it fills until Palumb holds the run, then drains back.

In the middle palumb itself, the durable engine, and it is the one box that is not an address because it is not something you run. It says one thing, running workflow, and it blinks, because a live run is the only thing in the figure that is happening rather than recorded. It appears only when the trigger arrives: before you call, there is nothing of yours in Palumb. Underneath it a row of small purple tokens grows, one for each step that has closed, each carrying that step's number, so by the end there are five and the row is the journal.

At the bottom yourapp.com/workflows/orderPlaced, your own workflow code, holding the program itself: the five steps numbered one to five: step.send for the confirmation, step.waitForEvent for the shipped signal with a thirty day limit, step.send for the tracking, step.delay of three days, and step.send for the feedback. Palumb calls down into it one step at a time, the rail filling down to that line and draining back. The moment a step is recorded its number leaves the line, replaced by a tick, and reappears as a token under Palumb: you wrote the step, we are the ones who remember it ran.

The steps are yours because they are written in your repository; what Palumb keeps is the place in the list. Through the thirty day wait and the three day delay the rail down to your code is grey and empty while the run stays alive in Palumb, which is why the run survives a wait in which your server does nothing at all.

order-placed.ts 
workflow("orderPlaced", async ({ payload, step }) => {
  await step.send("confirmation", "email", () => confirmation(payload))

  const shipped = await step.waitForEvent("shipped", {
    event: "order.shipped",
    timeout: "30d",
  })
  if (!shipped) return

  await step.send("tracking", "email", () => tracking(shipped))

  await step.delay("cool-off", { seconds: 3 * 24 * 3600 })
  return step.send("feedback", "email", () => feedback(payload))
})

Worked examples, with the code

Palumb vs Novu compared

Ownership, deployment, jurisdiction, pricing and what each of those means once you have signed.

Novu and Palumb compared on ownership, jurisdiction, hosting, licensing, pricing, channels, certifications and availability.
Novu Palumb What this means for you
Legal entity Noti-Fire Apps Ltd. (Ramat Gan, Israel) One founder, Italy Which government can compel a company follows from where it is incorporated, not from the endpoint you call.
EU data residency Yes, on every plan including free Yes Novu wins outright on residency. Residency and jurisdiction are two different questions, and residency is the easier one.
Licence MIT core; enterprise/ and src/ee/ need a commercial licence AGPL-3.0, the whole delivery path Open source with a paid perimeter inside it. Ours has no paid directories and nothing to buy a licence for.
The self-hosted build Reduced: no RBAC, MFA, env vars, >2 environments or email tracking The same build Palumb runs in the cloud If you self-host for jurisdiction, you should not lose the delivery record on the way.
Services to run yourself API, Worker, WS, Dashboard, two Redis clusters, MongoDB, S3 Three: the application, Restate, Postgres Their own recommended production topology is thirteen VMs plus object storage.
Workflows 20 on Free and Pro, 100 on Team No limit, on any plan Forty notification types puts you on the $250 plan there, and on the free plan with Palumb.
Billing unit Workflow run, per subscriber Run, per recipient The same unit, word for word: this is the one comparison in the category where the rate is directly comparable.
Plans Free 10K runs · Pro from $30/30K · Team from $250/250K Free 500 runs · €19, €49, €149 Above the plan they charge $1.20 per 1,000, and Palumb is two to six times that per run. The rate is not the bill, because their plans meter more than runs.
What a plan restricts Workflows, team members, environments, history, branding, RBAC Runs a month. Nothing else, on any plan Everything you would climb to Team for is on Palumb's free plan, so the comparison is $250 against €49 at forty notification types, not $1.20 against €4.90 per thousand.
Delivery history 24 hours on Free, 7 days on Pro, 90 days on Team 90 days on every plan Answering “it never arrived” a week later needs the paid plan there, and no plan with Palumb.
Team members 3 on Free, unlimited on Team No limit, ever There is nothing to log into with Palumb, so there is no seat to buy, and no dashboard either.
Environments 2 on Free and Pro, up to 10 on Team None Dev, staging and production mean three separate Palumb accounts. Novu does this properly and Palumb does not.
Wait on an external event No: delay, digest and throttle are time-based Yes, with a timeout Waiting for the payment, the acknowledgement or the click is a step with Palumb and something you build there.
Certifications SOC 2, ISO 27001, HIPAA BAA on Enterprise None A buyer who wants an audit report on paper should buy Novu, and that is the right call.
Status Generally available, thousands of users Private beta, no track record You would be early, and being early carries a risk no argument removes.

Doesn't Israel have an EU adequacy decision?

It does, since 2011, and it still stands, so the transfer is lawful. It answers a different question from the one procurement asks: not which government can compel the company once the data is there. The long version is on the jurisdiction page.

Taken from Novu's own pricing page, privacy policy, repository README and documentation: the self-hosting requirements, the Community versus Cloud matrix and the Framework syncing guide. Checked on . Facts about other companies go stale, and being corrected beats being wrong: if a fact here is out of date, tell us and Palumb will fix it.

Frequently asked questions

What is the main difference between Palumb and Novu?

Novu is the one vendor whose model is genuinely close: they are open source too, MIT on the core, and Novu Framework defines workflows in code the way Palumb does. Three things separate the two.

Their code-first is JavaScript only: every Framework quickstart is a JS runtime, so if your application is in PHP, Go, Java or .NET the dashboard is what you get. Their open-source build is not the product they sell: self-hosted Novu has no RBAC, no MFA, no environment variables and no email activity tracking, while Palumb's is the same build in both places.

And their plans meter workflows, seats, environments and history where Palumb's meter runs and nothing else. On product Novu is ahead (more channels, real certifications, years in production), and cheaper per run.

Is Novu open source?

Yes, and more permissively than Palumb: the core is MIT. The exception is stated in their own README: the enterprise folder and the src/ee folders “require a commercial license”. Palumb is AGPL-3.0 across the whole delivery path with no paid directories inside it; what is proprietary sits outside it entirely, in the tenant registry and the issuing of API keys.

Can I define Novu workflows in code, like Palumb?

In TypeScript, yes: Novu Framework is genuinely the same model, and this is not a difference Palumb claims. In any other language, no: all nine Framework quickstarts are JavaScript runtimes, and the Python, PHP, Go, Java and .NET SDKs trigger workflows and manage subscribers rather than define them. Palumb's surface is declared for seven languages (TypeScript, PHP, .NET, Python, Go, Java and Rust), and which of them lands first is not decided yet.

Is Novu cheaper than Palumb?

Per run, yes, and by a lot: $1.20 per 1,000 above your plan against €0.003 to €0.0076 with Palumb. The rate is not the bill. Novu's plans also meter workflows, team members, environments, delivery history and their watermark: 20 workflows on Free and on Pro, 3 people, 2 environments, 24 hours of history. Ours meter one thing: runs a month.

So a product with forty kinds of notification and eight thousand runs is Team at $250 there, and €49 with Palumb, while a product with fifteen workflows and no need for history is free there and €49 with Palumb. Work out which limit you hit first; that, not the rate, is the answer.

Novu offers EU data residency. Isn't that enough?

It depends on the question you have been asked. Residency answers where the bytes are, and Novu answers it well: the EU region is on every plan, including free. It does not answer which government can compel the company, which follows from where that company is incorporated. If your procurement form asks the first question, Novu passes. If it asks the second, no endpoint changes the answer.

What do I lose by self-hosting Novu instead of using their cloud?

Their own comparison matrix lists it: role-based access control, multi-factor authentication, environment variables, more than two environments, branding removal, snooze, and email activity tracking: the delivery and engagement events. Their framing is that Community Self-Hosted is “how you test and experiment”. With Palumb the self-hosted build is the build Palumb runs, because the licence is the permission and there is nothing held back.

The other comparisons

Six of them, each conceding first. If you are drawing up a shortlist, these are the rest of it, and the index compares all six side by side.

  • Palumb vs Knock

    Richer workflow functions and an in-app feed. A New York company, and no self-hosting path at all.

  • Palumb vs Courier

    More channels and real certifications. The only vendor here who publishes whose infrastructure runs its EU region, which is worth saying out loud.

  • Palumb vs SuprSend

    Multi-tenancy done properly, which is our own gap. Also a Delaware company processing data in the United States.

  • Palumb vs MagicBell

    An in-app inbox first, with a workflow engine of four commands and none of them waiting for an event. A San Francisco company that counts a delivery per channel.

  • Palumb vs Building it yourself

    The competitor almost everyone actually picks, and for most teams the right answer. Here is where that stops being true.

Everyone who joins gets in, and it costs nothing. Your invite goes out when the beta opens.

Join the beta