Introducing Palumb, and why I am building it
Hello. I am Adriano, and I am writing to you from Italy.
I am a software engineer. I love open source and I love this craft, and this is the first post on the Palumb blog. If you want to know more about me, there is a page about that.
So let me introduce you to Palumb. Palumb is notification orchestration for teams who keep their workflows in code: the workflow is a function in your own repository, in your own language, and Palumb executes it durably (the sends, the waits measured in days, the digests), and keeps the record of every attempt.
Where it came from
It began inside another SaaS I am building. I needed notification workflows that survive a deploy: several steps, waits measured in days, and a record of what actually went out. There were two ways to get that, and I did not want to defend either one in a review.
The first was to hand the whole thing to a company under another country’s law. The second was to self-host the open option in this category, which is six services to keep alive (an API, a worker, a websocket server, a dashboard, MongoDB and Redis) for something that is not my product. So I built the third way: three services, and one jurisdiction.
Once it was designed, I asked myself why I should keep it to myself. Palumb became a project of its own, an open alternative to the solutions already on the market, which are good ones. If you want that in detail, every comparison is here, including the parts where the other product wins.
What Palumb offers that they do not: control
It is open source, and of the products it competes with only one other is. With the rest, your exit is a purchase order. And that one asks you to operate six services to run it yourself; Palumb is three, and the licence is the permission: there is nothing to ask for.
There is no difference between the open source version and the cloud. It is the same code, and no feature is held back on either side. What is closed is the registry of tenants and the issuing of keys: the machinery that makes this a business, not the path your notifications travel.
You are not locked in. Your workflow lives in your version control, your template engine renders the message, your own sending credentials deliver it, and running the whole delivery path yourself is free. For good, not for a trial.
Not a philosophy invented for a landing page
Twenty years of this, self-taught first, then leading software architecture as a CTO. I have written the application and administered the servers underneath it, which is the habit that makes you count the services you are asking somebody else to keep alive.
The work before this one was self-custody: a wallet, and a modular smart account protocol. Systems whose entire premise is that the keys stay with the person who owns them. Palumb is the same instinct pointed at notifications: your logic in your repository, your template engine, your provider’s credentials, and the whole delivery path under AGPL-3.0. It is the third product in a row built that way.
Palumb is also not a team and not yet a company. It is one person in Italy, and the details are on the about page. You would find that out anyway, and finding it out here costs everyone less.
Where it is today
I am building the beta. If that interests you, join the waitlist and you get a key
as soon as there is one to give. It is a queue, not a selection. You will be able to try it on the
Palumb cloud for nothing (the free tier is 500 runs a month, and there is no card to
give) or on your own infrastructure with a docker compose up.
What the beta contains, and what it does not, is an answer that changes, so it carries a date and lives in a post of its own.
I am glad to have you here. If you have a suggestion, or a question of any kind, write to me at hello@palumb.com. I answer. Thanks for reading, and see you in the next post.