Palumb vs SuprSend: 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.
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
SuprSend: Multi-tenancy done properly, which is our own gap. Also a Delaware company processing data in the United States.
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 SuprSend asks you to accept
Every line comes from SuprSend's own documentation, checked on .
$110 and $275 buy the same volume
Both Essentials and Business include 50,000 notifications. The extra $165 a month is not capacity, it is features: from their own price list, digest and batching, and user preferences, are on Business. Here every plan is the whole product, and the free one included.
One notification per channel, per person
Their definition: “a notification is defined as a message triggered to a single user or object on any downstream channel”. A workflow that reaches someone by email and in-app is two. Palumb counts the run once, whatever it touches inside, so adding a channel changes their bill and not Palumb's.
Self-hosting behind two gates
It exists, and that is more than Knock or Courier offer. It is also “supported under the Enterprise plan and enabled via an enterprise license”, and their published dependency list is Kubernetes, PostgreSQL, two Redis stores, NATS, ClickHouse, Temporal and two object-storage buckets. Palumb is three services, and the licence is the permission.
The workflow is designed, then pushed
SuprSend workflows are built on their dashboard by adding nodes and branches, and a Management API lets you version and deploy them. That is a real product, and for a team with non-engineers editing notifications it is the right shape. It also means a second copy of your logic, in their format, on their side, where Palumb's is a function in the language your application is already written in.
SuprSend is a Delaware company, and no European region is named
SuprSend is operated by SuprStack, Inc.; their terms are governed by Delaware law with exclusive jurisdiction in Wilmington, their privacy policy says personal data is processed in the United States under the EU–US Data Privacy Framework, and no European region is named at all.
Where they beat Palumb, and it is on Palumb's own ground
Multi-tenancy for your customers is a real SuprSend feature, and Palumb's target (European B2B SaaS) is full of companies whose customers are companies. Palumb has not built it. Theirs is on Enterprise, which makes it expensive rather than absent. That difference goes their way.
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.
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.
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
- How do you follow an order all the way to feedback?
- How do you chase an unpaid invoice without chasing someone who paid?
- How do you nudge a user who signed up and never came back?
- How do you warn before a trial ends, and stop the moment they upgrade?
- How do you send a weekly summary on a fixed schedule?
- How do you stop sending one email per comment?
Palumb vs SuprSend compared
Ownership, deployment, jurisdiction, pricing and what each of those means once you have signed.
| SuprSend | Palumb | What this means for you | |
|---|---|---|---|
| Legal entity | SuprStack, Inc., Delaware law, Wilmington | One founder, Italy | Which government can compel a company follows from where it is incorporated. |
| Where data is processed | United States; no EU region named | European Union (Scaleway, France) | There is no European option to ask for, so the transfer is the arrangement. |
| Open source | No: proprietary, client SDKs aside | Yes: the whole delivery path, AGPL-3.0 | If the relationship ends you have something to run, not something to rebuild. |
| Self-hosting | Sold, not published: Enterprise contract plus a licence | Three services, any plan, no licence to ask for | Kubernetes, Postgres, two Redis, NATS, ClickHouse, Temporal and object storage, against an app, Restate and Postgres. |
| What a workflow is | A design on their dashboard, pushed by API | A function in your repository | Reviewed, typed and tested by the tools already running over the rest of your code. |
| Wait on an external event | Yes: a Wait Until branch, on a condition, with a maximum wait | Yes, on a named event, with a timeout | The mechanism differs, a condition evaluated on their dashboard against a named event awaited in your code, and the capability is on both sides. |
| Billing unit | A notification, per user, per channel | A run, per recipient, any channels | Their bill scales with channels and Palumb's does not. |
| Plans | Free 10K · Essentials $110/50K · Business $275/50K | Free 500 runs · €19, €49, €149 | Their two paid plans include the same volume: the $165 between them buys features, not capacity. |
| Digest and batching | Business plan, $275/month | Every plan, free included | Collecting twenty events into one email is table stakes, and it is priced like an upgrade. |
| User preferences | Business plan, $275/month | Every plan, free included | So is letting someone turn a notification off. |
| Multi-tenancy for your customers | Yes, on Enterprise | Not built | If per-tenant branding and settings are your requirement today, buy SuprSend. |
| Data retention | 30–90 days, custom on Enterprise | 90 days on every plan | Comparable, and Palumb's does not move with the plan. |
| Certifications | SOC 2 Type 2; HIPAA BAA on Enterprise | None | A buyer who wants an audit report on paper should buy SuprSend, and that is the right call. |
| Status | Generally available, with public customers | Private beta, no track record | You would be early, and being early carries a risk no argument removes. |
Doesn't the United States have an EU adequacy decision?
It does, since 2023, 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 SuprSend's own pricing page, terms, privacy policy and documentation, including the self-hosting introduction, the dependency list and the management API. 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 SuprSend?
Palumb is open source, and it does one thing: it orchestrates. The workflow is a function in your own codebase, in your own language, deployed with the rest of your application; your template engine renders the message and your own provider sends it. Palumb resolves the recipients, executes the steps durably (waits included), and keeps the record of every attempt. You can also run the whole thing yourself, because the entire delivery path is AGPL-3.0 and self-hosting is free.
SuprSend is the opposite arrangement: proprietary software you can only self-host by buying an Enterprise contract and a licence, workflows designed on their dashboard and pushed to their side, billing per channel, and a Delaware company processing data in the United States with no European region named. Their plans also hold back digest, batching and user preferences until $275 a month, where every Palumb plan is the whole product. On multi-tenancy for your own customers they are ahead of Palumb, and Palumb has not built it.
Is SuprSend open source?
No. SuprSend is proprietary software. The client SDKs are MIT, as everyone's are. The product is closed, and running it yourself means buying an Enterprise contract and an enterprise licence: your exit is a purchase order. Palumb publishes the whole delivery path under AGPL-3.0, so the exit is a licence you already have.
Can I self-host SuprSend?
Yes, and that is more than Knock or Courier offer, but their documentation says it is “supported under the Enterprise plan and enabled via an enterprise license”. The published dependency list is Kubernetes 1.29+, PostgreSQL 17+, two Redis-compatible stores, NATS, ClickHouse, Temporal 1.25+ and two object-storage buckets. Palumb is three: the application, Restate and Postgres, on any plan.
How much does SuprSend cost?
Free to 10,000 notifications a month, then $110 for 50,000 or $275 for the same 50,000: the difference between the two paid plans is features, not volume. Overage is $2 per 1,000 on Essentials and $5 per 1,000 on Business. Palumb is free to 500 runs, then €19, €49 and €149, with no feature held back on any of them.
Does SuprSend bill per channel?
Yes, and they say so plainly: “a notification is defined as a message triggered to a single user or object on any downstream channel”. One workflow reaching a person by email and in-app is two notifications. Batched and digested messages count as one, and messages that fail because a user opted out are not billed. Palumb counts the execution once per recipient.
Does Palumb do multi-tenancy for my customers, like SuprSend?
No. Per-tenant branding and per-tenant preferences for your own customers are a real SuprSend feature and Palumb has not built them. Our target is European B2B SaaS, which is full of companies whose customers are companies, so this is the gap that matters most, and writing around it would be dishonest. If that is your requirement today, buy SuprSend.
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 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 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 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