>Spinel.coop is a collective of Ruby open source maintainers building next-generation developer tooling, like rv, and offering flat-rate, unlimited access to maintainers who come from the core teams of Rails, Hotwire, Bundler, RubyGems, rbenv, and more.
I run a few instances of listmonk [0], what makes fertit different/better?
One thing I don’t particularly like about listmonk is that it doesn’t really support multitenancy. It’s lightweight enough that I can spin up multiple instances for different domains, but it’d be nice not to.
Multi-tenancy is exactly what Fertit was built to solve. But it is available only in Fertit hoster service, not the open-source version at the current moment.
Listmonk is excellent - we actually considered building on top of it initially. The main differentiators:
Multi-tenancy (your pain point):
Native support for multiple newsletters/domains in one instance
Unified management across all your properties
Positioning differences:
Listmonk: Power-user tool with SQL segmentation, advanced templating, high-throughput queues
Fertit: Simplified interface targeting small businesses who want "just works" newsletter management
Architecture approach:
Listmonk: Single binary + PostgreSQL (requires more ops knowledge)
Fertit: Docker Compose setup with Redis for caching, designed for easier deployment
Business model:
Open-source version addresses your self-hosting needs
Hosted service ($5-10/month) for users who want zero ops
When you'd choose Fertit over Listmonk:
You manage newsletters for multiple clients/domains (multi-tenancy)
You prefer simpler UI over advanced segmentation features
You want commercial support option
You're hitting operational complexity with multiple Listmonk instances
When you'd stick with Listmonk:
You need the advanced features (SQL queries, high-throughput queues)
Current multi-instance setup works fine for your scale
You prefer the mature, battle-tested codebase
Would love your thoughts on the multi-tenancy approach - is that the main friction point you're hitting with multiple instances?
Having to use actions for ssh/rsync always rubbed me the wrong way. I’ve recently taken the time to remove those in favor of using the commands directly (which is fairly straightforward, but a bit awkward).
I think it’s a failure of GitHub Actions that these third party actions are so widespread. If you search “GitHub actions how to ssh” the first result should be a page in the official documentation, instead you’ll find tens of examples using third party actions.
>Feels like something very similar should be built into tools like docker-compose.
In docker compose you can use `depends_on` [0] to define dependencies between containers and by default it will wait until a dependent container is "ready".
But you can also use a more verbose syntax to wait until a container is "healthy", as defined by its own healthcheck.
>Brought to you by Spinel
>Spinel.coop is a collective of Ruby open source maintainers building next-generation developer tooling, like rv, and offering flat-rate, unlimited access to maintainers who come from the core teams of Rails, Hotwire, Bundler, RubyGems, rbenv, and more.