Your workflow code
One workflow per name. The trigger names it directly — no giant switch over event types. Branch, loop, call your own APIs. It's just code.
Notifications as code · sovereign in the EU
The EU-sovereign notification platform you program, not configure. Write your workflows in TypeScript; palumb runs the managed, durable control plane that delivers them across email, SMS, push and in-app.
In one sentence
palumb is an EU-sovereign notification platform that you program instead of configure. Rather than building flows in a low-code canvas, you write each notification workflow as plain TypeScript and own, review and test it like any other code. palumb runs the managed control plane and a durable runtime (Restate) that authenticates your app, stores your subscribers and channel credentials, and delivers across email, SMS, push, in-app and webhook. Because the runtime is durable, a workflow that says “wait an hour, batch, then send” survives crashes and deploys without lost or double-sent messages — you write no checkpointing or idempotency code. The control plane, the durable runtime and your data all live in the EU, run by an EU provider, with no transfer to the US. The core is open source and self-hostable.
The wedge
Each of these exists somewhere. palumb's bet is that one class of EU teams should get all four at once.
Your notification data stays in the EU, run by an EU provider. Not a US service with a region toggle.
We operate the control plane and the durable runtime. No queues, workers, or Restate cluster for you to run.
Wait, batch, branch and survive a crash mid-send. No lost notifications, no double sends — built in.
Workflows are plain TypeScript you own, review and test. No low-code canvas to fight.
01 · How it works
The boundary is the whole point. You never touch a provider's API keys, and palumb never sees your business logic. Each side owns what it's best at.
One workflow per name. The trigger names it directly — no giant switch over event types. Branch, loop, call your own APIs. It's just code.
The only part that holds state and secrets. It does exactly four jobs — and stays deliberately dumb about your logic.
02 · Notifications as code
The single send is easy. palumb's unit is the workflow: waiting, batching, branching, and surviving failure. The runtime underneath is durable — the difference that shows up in production, not in the demo.
03 · Channels
Your workflow names a channel kind; palumb resolves the concrete provider, decrypts its credentials, looks up the subscriber's address, and records every attempt.
SMTP & providers
global routes
iOS · Android · web
inbox feed
your endpoints
The same trigger can target one subscriber or fan out to a whole topic — palumb expands it to a deduplicated set and runs your workflow once per subscriber.
04 · EU sovereignty
Most managed notification stacks are US-centric with an EU region bolted on. palumb is built EU-first: the control plane, the durable runtime and your data all live in the EU, run by an EU provider. And because the core is open source, that independence is something you can enforce — not just trust.
No lock-in — your exit is built in →Data minimisation, residency and deletion on request are defaults, not add-ons. A DPA and sub-processor list come standard.
Provider secrets are encrypted at rest and never returned — your app never holds a provider key.
The control plane is open source (AGPL-3.0), so your exit is built in: audit it, or self-host the whole thing on your own EU infrastructure.
05 · Durability
The durable runtime under your workflows is Restate. It's why “wait an hour, then send” survives a deploy or a crash — without you holding a worker open or writing a single idempotency key.
06 · Why palumb
palumb does one shape of the problem very well — code-first, durable, managed, EU-sovereign — rather than every shape adequately.
| Build it yourself | Generic send API | Low-code builder | palumb | |
|---|---|---|---|---|
| Logic in code you own & review | ✓ | partial | — | ✓ |
| Durable workflows (wait, batch, retry) | — | — | partial | ✓ |
| Survives crashes — no double sends | — | partial | partial | ✓ |
| Fully managed runtime | — | ✓ | ✓ | ✓ |
| EU-sovereign by design | partial | — | — | ✓ |
| No provider keys in your app | — | — | ✓ | ✓ |
Not the right fit if your notifications are authored by non-developers, or if EU residency genuinely doesn't matter to you — the sovereignty wedge is a real part of the value. Read the honest version →
Free to start. Open source if you'd rather self-host. EU-sovereign either way.
$ npm i @palumb/sdk