Dittofeed: self-hosted customer engagement with an MIT core and a closed-source edge

The gap Dittofeed occupies between an ESP and a CDP

Sending a transactional receipt is a solved problem. Sending a receipt, then a push notification two days later if the user has not opened the app, then an SMS if they still have not, and only to users who match a segment built from event history, is where teams usually end up buying three products or writing a scheduler. Dittofeed targets that middle layer. The README describes it as an omni-channel customer engagement platform where you send broadcasts or create automated user journeys along email, mobile push, SMS, WhatsApp, Slack and more, and positions it as an open source, dev-friendly alternative to OneSignal, Customer.io and Segment Engage. The intended user is a product or growth engineer who is comfortable running a Postgres-backed service and who wants the journey logic inside their own infrastructure rather than behind a vendor API. The repository is TypeScript, MIT-licensed, and not archived.

Data in through Segment or the API, messages out through your ESP

The README lists the intended data flow as a numbered sequence. User data arrives via Segment, a Reverse ETL job, or the Dittofeed API. Segments are then built with what the README calls multiple operators. Templates are authored in HTML or MJML, or through a low-code editor, and delivery happens either as a one-off broadcast or as an event-based automated journey configured in a GUI. The actual sending is delegated: the README names Sendgrid and Amazon SES as the ESP integrations, so Dittofeed is deciding who gets what and when, while the ESP handles delivery. Performance data comes back into the dashboard. The repository also ships an architecture diagram and dashboard screenshots for the journey builder, broadcasts, segmentation and template editor, though the diagram itself is an image and the README does not restate its contents in text. Two roadmap entries are worth noting for anyone evaluating the internals: the project replaced Prisma with Drizzle in Q1 2025, described as improving memory efficiency and stability, and deprecated Postgres user property and segment assignments in the same quarter to improve computed property efficiency. Both suggest the data layer has been reworked rather than stable since the beginning.

Deployment paths: Docker Compose, Render, or the hosted trial

There are three documented ways in. The README links a walkthrough video for deploying with Docker Compose and automating a first message, with accompanying documentation at docs.dittofeed.com/deployment/self-hosted/docker-compose. The second is a Deploy to Render button that points Render at the GitHub repository, with further instructions under the self-hosted Render docs page. The third is the hosted trial at app.dittofeed.com/dashboard, plus a public demo app at demo.dittofeed.com/dashboard. The README does not print the Compose file, the environment variable names, or the Render blueprint contents inline, so the configuration keys you will actually need live in the docs site rather than in the repository front page. That is a real friction point: you cannot size the deployment, count the required services, or check which database and queue components are involved without leaving the README. What the README does make clear is that the supported self-hosted path is container-based, and that a one-click Render deployment exists for teams who do not want to manage the containers themselves.

The open core boundary runs through embedding, multi-tenancy and white-labeling

This is the part to read twice. The README lists embedding as step seven, with an asterisk, and the footnote says to email support to learn more about a licensed closed-source codebase that includes multi-tenancy, embedding and white-labeling. The topics list on the repository includes embedded, white-label and self-hosted, which makes the distinction easy to miss if you skim. In practice this means the MIT licence covers the platform you self-host for your own users, but if you are building a product where your customers log into Dittofeed-derived dashboards under your brand, or where a single deployment serves multiple isolated tenants, that capability is not in this repository. The roadmap is consistent with this: embedded components are marked as shipped for a private beta in Q4 2024 and then as a public release in Q2 2025, but the public release entry is about the internal dashboard, docs and demo projects, not about moving the feature into the MIT codebase. Treat the licence boundary as a scoping question, not a legal one, and confirm with the maintainers which side of it your use case falls on before you build a product plan around it.

Alpha releases and a roadmap that still has unchecked boxes

The most recent releases are v0.24.0-alpha.17, v0.24.0-alpha.16 and v0.24.0-alpha.15, dated 2026-03-28, 2026-03-16 and 2026-01-22. Every published tag carries an alpha suffix. There is no stable release line visible in the material, which means upgrades should be treated as a tracked activity rather than a set-and-forget one. The spacing is also uneven: roughly twelve days between the first two, then about seven weeks to the third. If your release process assumes predictable patch cadence, that is a mismatch you should plan around. The roadmap shows the same pattern of work in flight. Identity resolution, described as joining users based on traits or behavior and important for identifying anonymous users after sign-up or sign-in, is marked in development. Expanding the low-code email editor command palette and expanding the analytics dashboard are both marked in development. LLM integration for generating journeys, segments and templates, and a Stripe integration for syncing customer data, are both unchecked. None of that is a defect, but it does mean the feature set described in the README is partly aspirational, and the gap between what is shipped and what is planned is where adoption risk sits.

Where a hosted engagement vendor is the better fit

Customer.io is the obvious comparison, since the README names it directly. The difference is not feature parity, it is operational ownership. With Customer.io you get a managed service and no Postgres to run, no containers to upgrade, and no alpha tags to review before a deploy; in exchange your user data and your journey definitions live in someone else's system, and your costs scale with volume rather than with infrastructure. Dittofeed inverts that. You run the database, you run the containers, you own the upgrade timing, and you can read the source of the parts that are open. The trade is real in both directions. A team of two shipping a first onboarding email sequence will get further, faster, on a hosted vendor, and the README's own hosted trial exists for exactly that evaluation. Dittofeed starts to make sense when the journey logic is close enough to your product that you want it in your own network, when segment definitions depend on data you would rather not export, or when per-message pricing at your volume is the binding constraint. The repository being MIT-licensed does not change the operational burden; it only changes what you are allowed to do with the code once you have taken it on.

Maintenance cost and what the MIT licence does not settle

Self-hosting here means operating a multi-component TypeScript service on top of Postgres, with a background job path implied by event-based journeys and a dashboard front end. The README does not enumerate the services, so the honest statement is that the operational surface is larger than a single container and you should read the Docker Compose documentation before estimating it. Upgrades are the recurring cost: with only alpha tags published, you should expect to read release notes for each v0.24.0-alpha.x bump and to test journey execution after upgrading, particularly given that the project swapped its ORM from Prisma to Drizzle and deprecated Postgres user property and segment assignments within the same quarter. On licensing, the MIT terms cover the code in this repository, and the README states plainly that multi-tenancy, embedding and white-labeling are in a separate licensed closed-source codebase. Whether your intended use requires that separate licence is a question for the maintainers and, if the answer matters commercially, for your own counsel. The repository material does not resolve it, and guessing is the wrong move.

What to verify before you commit

Start with the licence boundary, because it determines whether Dittofeed can be your product or only your internal tool. Email support and get a written answer about embedding, multi-tenancy and white-labeling for your specific case. Second, read the Docker Compose and Render self-hosting pages end to end and count the services, the environment variables and the persistence requirements, then compare that against what your team already operates. Third, pin a specific alpha tag rather than tracking main, and read the release notes between tags before moving, since the cadence is irregular and the data layer has changed recently. Fourth, check the roadmap items you depend on. If identity resolution matters for anonymous-to-known user stitching, it is listed as in development, so plan for it to arrive later than you need it or handle it upstream. If the low-code template editor is the reason you are interested, note that expanding its command palette is also still in development. The demo app at demo.dittofeed.com is the cheapest way to test whether the journey builder matches how your team thinks about campaigns. Do that before you provision anything.

Editorial conclusion

Adopt Dittofeed if you want an MIT-licensed engagement service you can run yourself and you are willing to track v0.24.0-alpha.x releases, or if you only need the hosted trial. Do not adopt it if multi-tenancy, embedding or white-labeling is a hard requirement, because the README routes those to a licensed closed-source codebase. Before committing, verify the licensing boundary for the features you need, check the Docker Compose and Render docs against your own infrastructure, and confirm that the alpha release cadence matches your upgrade tolerance.

Official sources

1. dittofeed/dittofeed on GitHub
2. License: MIT
3. Project website
4. README
5. Releases