Dittofeed is an open-source, MIT-licensed omni-channel customer engagement platform, written in TypeScript, that sends broadcasts and automated user journeys across email, SMS, mobile push, WhatsApp, Slack, and other channels — built for developers and product teams who want to own their messaging infrastructure instead of renting it.

What it is

Dittofeed is a self-hostable customer engagement and marketing automation platform. It lives in the Node.js and TypeScript ecosystem and combines four dashboard surfaces — Journey Builder, Broadcasts, Segmentation, and Template Editor — into a single application. Users connect customer data through Segment, Reverse ETL, or the Dittofeed API, build segments with multiple operators, design templates in HTML or MJML or in a low-code editor, and then send either one-off broadcasts or event-triggered automated journeys from a graphical interface.

The concrete problem it solves is the split between customer data, segmentation, and message delivery that most teams patch together across several vendors. Dittofeed replaces the closed hosted products in that category — OneSignal, Customer.io, and Segment Engage — with software the operator runs and controls. It also removes hand-rolled send scripts, because template management, audience logic, and message performance tracking sit in the same dashboard. Delivery itself is delegated to established providers: the platform integrates with major ESPs such as Sendgrid and Amazon SES.

Key capabilities

• Sends across email, mobile push notifications, SMS, WhatsApp, and Slack from one platform.
• Builds highly customizable user segments with multiple operators, including user grouping for collections such as a club, company, or team.
• Runs two campaign shapes: one-off broadcasts and automated event-based journeys, both configured through the GUI.
• Designs messaging templates in HTML or MJML, or in the low-code editor (Emailo) with its expanding command palette.
• Ingests user data through Segment, Reverse ETL, or the Dittofeed API.
• Connects to major ESPs such as Sendgrid and Amazon SES for delivery.
• Tracks and analyzes message performance and campaign progress from the dashboard, and supports embedding Journey Builder, Segment Builder, and Template Builder in third-party apps via iframe or headless React components.

Who uses it and how

• Product and engineering teams that want segmentation, journeys, and broadcast sending in one self-hosted application rather than across three vendors.
• Teams already standardized on Segment or a Reverse ETL pipeline, which can feed user data into Dittofeed without new instrumentation work.
• SaaS products with an existing ESP contract — Sendgrid or Amazon SES — that need a journey and segmentation layer above the sending provider.
• Applications that need messaging tooling embedded inside their own product, using the iframe or headless React component path.
• Platform operators needing multi-tenancy and white-labeling, who are directed to the separately licensed closed-source codebase.

Getting started

Self-hosting is documented as a Docker Compose deployment, with an end-to-end walkthrough video and accompanying docs at docs.dittofeed.com/deployment/self-hosted/docker-compose. A one-click Deploy to Render path covers the hosted-infrastructure alternative, and a demo app runs at demo.dittofeed.com/dashboard for evaluating the dashboard before deploying.

How it compares

Dittofeed positions itself as an open-source, developer-friendly alternative to OneSignal, Customer.io, and Segment Engage. The difference is the licence and the cost model: those three are paid hosted services, while Dittofeed's core is MIT-licensed and runs on the operator's own infrastructure, so customer data and message history remain under the operator's control. The trade-off is operational — the hosted products include the hosting, scaling, and support, while the self-hosted path leaves Docker deployment, the Postgres-backed data layer, and ESP configuration with the operator.

When to use it — and when not to

Choose Dittofeed when the team can operate a Docker Compose deployment backed by Postgres and already has, or is willing to obtain, an ESP account such as Sendgrid or Amazon SES for delivery. Do not choose it when the requirement is multi-tenancy, embedding, or white-labeling, because those features live in a licensed closed-source codebase rather than the MIT repository. Further caution: LLM-assisted journey generation and Stripe integration appear on the roadmap with unchecked boxes, identity resolution and the expanded analytics dashboard are still in development, and the repository carries 51 open issues.