Customer.io vs Dittofeed: which fits your messaging stack
Choose Customer.io if you want a vendor to run event-driven messaging and you can accept a bill that scales with profiles. Choose self-hosted Dittofeed if personal data must stay inside your own VPC, you want campaigns versioned in git, or you need to avoid volume-based pricing. Customer.io fits teams that want hosted operation, with the vendor running the platform, and that already rely on its managed deliverability tooling and reporting. If your send and profile volumes are predictable and your team does not want to operate messaging infrastructure, that model is usually the simpler decision. Before renewing, ask for a profile forecast for the next contract term so you can compare it with the self-hosted cost model.
Dittofeed fits when self-hosting is a requirement rather than a preference. The project states that self-hosting keeps sensitive personal data in the operator's VPC and avoids volume-based pricing. It also suits teams that want templates and journeys managed like code. Dittofeed supports branch-based git workflows for campaign version control, keeps email templates in git, and offers a testing SDK for checking campaigns in CI. Data arrives through Segment, reverse ETL or the Dittofeed API, which fits a stack that already has a customer data pipeline. Dittofeed also integrates with email providers such as SendGrid and Amazon SES instead of sending mail itself, so teams with an existing provider can keep it.
The decision turns on three things. First, data control requirements: list which personal data must remain in your environment, and confirm with legal whether your email or SMS providers may process it under your agreements. Second, in-house engineering capacity: Dittofeed documents Docker Compose and Render deployments, with Helm charts in its repository, so someone must own deployment, upgrades, backups and monitoring. Third, tolerance for pre-release software: the project's recent GitHub releases are pre-release tags, with v0.24.0-alpha.21 published on October 4, 2026. Check the Dittofeed releases page for the current status, pin versions, and test upgrades in staging before production.
Which option fits which scenario
This table matches common team situations to the option that usually fits better, with the condition that changes the answer. Read each row against your own staffing, data rules and delivery process before deciding. The main takeaway is that Dittofeed suits teams that can operate their own infrastructure and want messaging managed as code, while a hosted service suits teams that need vendor support guarantees today.
| Team situation | Better fit | Condition that makes it so |
|---|---|---|
| Small team without platform engineers | Customer.io (hosted) | Dittofeed becomes viable only if someone can run containers, databases, upgrades and backups without a dedicated platform team |
| Must keep personal data in its own VPC | Dittofeed (self-hosted) | Requires the email and SMS providers you connect to be covered by your own data processing terms and controls |
| Already runs Segment and reverse ETL | Dittofeed (self-hosted) | Works best when your event pipeline already feeds user data, so you repoint existing flows rather than rebuild them |
| Manages campaigns in git and CI | Dittofeed (self-hosted) | Branch-based version control, templates in git and the testing SDK fit teams that already review code before release |
| Needs vendor support guarantees today | Customer.io (hosted) | Dittofeed is alpha-stage with pre-release tags, so support depends on your own staff or a retained partner |
| Wants to avoid volume-based pricing | Dittofeed (self-hosted) | Savings depend on your server, database and provider costs plus the engineering time to run them, so compare totals |
| Needs a fixed, pre-agreed service level | Customer.io (hosted) | Confirm the contract terms directly with Customer.io, since this site does not state its SLAs |
| Runs SMS or WhatsApp across several providers | Confirm before deciding | Check which channel providers you need are supported in the current Dittofeed release before committing |
How Dittofeed takes in user data and sends messages
Dittofeed takes user data from three places: Segment, reverse ETL, or the Dittofeed API. Whichever you choose becomes the single path that feeds people and events into the platform, so decide it before you rebuild anything. Once data arrives, Dittofeed builds user segments from it using multiple operators, and those segments decide who enters a broadcast or an automated journey. If your Customer.io setup sends events through a customer data pipeline today, confirm which of these three inputs can carry the same event names, identifiers and attributes, because segments that depend on a renamed event will quietly return different audiences.
Dittofeed does not send email itself. Journeys hand messages to an email service provider, and the documented options are SendGrid and Amazon SES. The same is true for other channels: the platform's documentation describes sending over mobile push, SMS, WhatsApp and Slack, and each of those depends on a provider or integration your team configures. This means your organization owns the provider accounts, the sending domains, the API credentials, the suppression and bounce handling that the provider reports back, and the contract with each provider. Those accounts also process recipient addresses and message content under their own terms, so review what each provider stores and where, and confirm it against your data residency and privacy obligations before the first live send.
Plan for this ownership split early. Ask who will hold each provider account, who rotates its keys, and who watches bounce and complaint rates when a journey goes live. Write down which system is the source of truth for consent and unsubscribes, and test that a suppressed person is excluded from both broadcasts and journeys. Because Dittofeed is an alpha-stage open-source project, confirm the exact provider integration and event schema against the current release notes in the project's GitHub repository before you commit to a production design, and run both systems side by side until message volumes, segment counts and delivery outcomes match.
Where your data lives and who controls it
Moving from a hosted platform changes who holds the data, who runs the servers and who must prove the controls work. The cards below cover the decisions that follow from running Dittofeed in your own infrastructure, and the parts that stay with third parties even after you self-host.
Data location inside your VPC
Dittofeed states that self-hosting keeps sensitive personal data inside the operator's own VPC. With Customer.io, profiles, events and message logs sit in the vendor's account in a region fixed at setup. With Dittofeed, your team chooses the cloud account, region and database, and decides where backups go. Check which databases hold profile attributes, event payloads and message history, and confirm that no copy leaves through logging or error tooling.
Hosting models and deployment paths
Dittofeed documents Docker Compose and Render deployments, and ships Helm charts in its repository for Kubernetes. Each path changes who patches the platform, who manages the database and how upgrades roll out. A single Compose host is simpler to run but leaves availability and backup design to your team. A Kubernetes install fits clusters you already operate. Decide the model before you size the team that will run it.
Identity and access in self-hosted deployments
In a hosted account, the vendor manages the admin console, user roles and login. In a self-hosted deployment, you define who can edit journeys, export profiles, change templates and read message logs, and you must integrate sign-in with your identity provider. Confirm which roles the current release supports, how API keys are issued and rotated, and where audit logs of campaign changes are kept.
Evidence your team must produce
DeployOpen prepares controls and evidence for compliance assessments, but does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. With Customer.io, the vendor supplies its own compliance documentation. With Dittofeed, your team owns the evidence for access reviews, change records, backup restores and encryption settings. Ask your assessor early which artifacts they will request.
Email and SMS providers still process data
Dittofeed integrates with email service providers such as SendGrid and Amazon SES rather than sending email itself. Self-hosting therefore does not remove third-party processing: recipient addresses, message content and delivery events still pass through your sending provider, and SMS and WhatsApp routes add further processors. List each provider, its processing location and its contract terms, and align them with your data residency requirement.
What an alpha-stage open-source project means for support
Dittofeed is MIT licensed and describes itself as free forever, so the license cost is zero, but the release status is the constraint to plan around. Its recent GitHub releases are pre-release tags, and the latest one in the supplied material, v0.24.0-alpha.21, was published on October 4, 2026. An alpha label on a version string signals that interfaces, configuration and data handling may change between tags without the stability guarantees a mature commercial product usually offers. Before you commit, read the release notes for every tag between your candidate version and the one you plan to run, and look specifically for breaking changes to the API, the data model, template handling and Docker Compose or Helm configuration.
Treat upgrades as deliberate projects rather than routine patches. Pin a single known-good version in your deployment definition, run it in a test environment that mirrors your production event flow and email provider settings, and promote a new tag only after the segments, journeys and templates you depend on have been checked against it. The git-based workflows and the testing SDK for CI described in the project documentation help here, because they let you replay campaign changes before they reach customers. Record who owns each upgrade decision and how long a rollback path must remain available.
Support is the other half of the decision. Customer.io offers vendor support as part of its service, so ask it directly which channels, response expectations and escalation paths are included in your plan. For Dittofeed, support comes from the open-source community, from your own engineers, or from an implementation partner under a written scope, and that model must be confirmed before go-live. Ask who will investigate a broken journey at 2 a.m., who holds the on-call runbook, and what written commitment, if any, covers security fixes. The answers determine whether the staffing cost of self-hosting is acceptable for your team.
Who runs each option day to day
With Customer.io, the vendor operates the platform. Hosting, scaling, database management, software updates and the delivery infrastructure behind the messaging service are handled by Customer.io. Your team's work centers on configuration: defining data attributes, building segments, designing campaigns and broadcasts, managing templates, and deciding which events trigger journeys. Day-to-day ownership usually sits with marketing operations or lifecycle teams, supported by engineers who send events from the product.
- Platform operations: Customer.io runs the infrastructure and applies updates, so your team does not schedule upgrades or patch servers.
- Configuration ownership: Marketing and lifecycle staff manage segments, campaigns and templates through the interface.
- Event integration: Engineers maintain the code that sends events and attributes to Customer.io, which is still your responsibility.
- Provider relationships: Your team manages sending domains and messaging channel settings within the vendor's configuration options.
- Compliance and support: Support requests and service status are handled through the vendor, and the plan you buy determines which features and security options are available.
Before relying on this model, confirm with Customer.io which operational responsibilities sit with them and which sit with you, and which plan tier covers the controls your auditors will ask about.
With self-hosted Dittofeed, your organization or its implementation partner operates the platform inside your own infrastructure. Dittofeed is documented with Docker Compose and Render deployments and Helm charts in its repository, so the hosting model you choose determines the operational load. Someone must own provisioning, the database, backups, monitoring, upgrades, access control and security patching, along with the setup of email and SMS providers such as SendGrid or Amazon SES, which Dittofeed integrates with rather than replacing.
- Hosting and upgrades: Plan who tracks releases, tests upgrades in a staging environment and schedules production rollouts.
- Backups and recovery: Define backup schedules and restore tests for the database that holds user data and journey state.
- Monitoring: Set alerts for delivery pipelines, queue backlogs and provider errors, since failures affect messages sent to customers.
- Provider setup: Own the configuration, sending domains, suppression handling and bounce processing in your email and SMS providers.
- Security patching: Apply operating system, container and application patches, and keep secrets and access controls under review.
Before committing, confirm which of these tasks your team will perform and which a partner will handle under a written scope, and what on-call coverage applies.
The skills required differ sharply between the two models. A Customer.io team needs marketing and lifecycle expertise, data modeling for attributes and events, and enough engineering to instrument the product correctly. Self-hosting Dittofeed adds platform engineering for containers, databases, networking and CI pipelines, data engineering for event streams and reverse ETL, and deliverability knowledge covering authentication records, bounce handling, complaint rates and provider rules. Compliance knowledge is also needed to document how personal data is stored and processed.
- Platform engineering: Container orchestration, database administration, TLS, secrets handling and infrastructure as code.
- Data engineering: Designing event schemas, operating Segment or reverse ETL connections, and validating data quality.
- Deliverability: Managing SPF, DKIM and DMARC, warm-up, suppression lists and provider feedback loops.
- Messaging and design: HTML and MJML templates, campaign logic and testing campaigns in CI with the Dittofeed testing SDK.
- Security and compliance: Access reviews, logging, data retention and evidence for assessments.
Ask any implementation partner to show who on their side covers each skill, and check which skills your own staff already hold.
What drives the cost of each option
What does Customer.io charge for?
Customer.io is a hosted service, so you pay a subscription that scales with the size of your audience and the volume of messages you send. Pricing is set by profiles and email volume, and HIPAA support sits on its higher tier. Check the current plan terms, the profile count you expect in the next year, and whether the features you need (such as HIPAA, EU data region or advanced journey tools) are on the plan you are quoted. Customer.io does not publish prices in the facts supplied for this page, so get the figures from its sales team or current pricing page before comparing. These charges recur every billing period and grow as your audience grows.
Is Dittofeed free to use?
Dittofeed is MIT licensed and describes itself as free forever, so there is no license fee to pay. The costs move to infrastructure, email and SMS providers, and the people who run the platform. Dittofeed says self-hosting avoids volume-based pricing, which means your software cost does not rise with profile count. Confirm the current license terms in the repository before you rely on them for a board decision.
What infrastructure costs does self-hosted Dittofeed add?
You pay for the servers and databases that run Dittofeed in your own cloud account or data center, and these costs recur monthly. The components are:
- Compute for the Dittofeed application, sized to your event throughput and deployment method (Docker Compose, Render or Helm charts on Kubernetes).
- A managed or self-run database, backups and storage for user data.
- Networking, monitoring and logging, which many teams already pay for elsewhere.
The main cost drivers are event volume, the number of environments you run (production, staging and CI test environments) and whether you need high availability. Ask your platform team for a sizing estimate based on your expected event rate, and price it against your own cloud rates.
Do I still pay email and SMS provider fees with Dittofeed?
Yes. Dittofeed integrates with email service providers such as SendGrid and Amazon SES rather than sending email itself, so the provider bills you for sent messages. SMS, WhatsApp and push delivery also depend on the providers you connect. These fees recur and follow your send volume, which is the same driver you see with a hosted platform, but they are billed by the provider and not by the messaging tool. Ask each provider for its current rates and compare them against the messages you send today.
How much engineering time does running Dittofeed take?
Engineering time is usually the largest ongoing cost in a self-hosted setup, and it is recurring. Work includes deployment, upgrades, monitoring, backups, access control, provider configuration and maintaining segments, journeys and templates in git. Because Dittofeed is at an alpha stage, plan for upgrades that may include breaking changes. The hours depend on your team's existing skills, how many environments you run and how often you change campaigns. Estimate this internally or ask an implementation partner for a fixed-scope written plan, since DeployOpen scopes and quotes each engagement in writing.
What does migration cost in one-time effort?
Migration is a one-time cost that covers exporting people and attributes, repointing event tracking through Segment, reverse ETL or the Dittofeed API, rebuilding segments and journeys, connecting your email provider and running both systems until messages match. Customer.io exports people and attributes as CSV, but journeys and templates usually need to be rebuilt by hand, so budget for that work. The effort rises with the number of journeys, templates and event types you rely on. Ask for the scope in writing, including what gets tested and how long parallel running lasts.
What ongoing upgrade and support costs should I plan for?
Upgrades, security patches, backups testing and monitoring recur for as long as you run the platform. Because Dittofeed's recent releases are pre-release tags, with v0.24.0-alpha.21 published on October 4, 2026, check each release for breaking changes before you upgrade. Support comes from the open-source community, from your own staff, or from a retainer with an implementation partner. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, which are quoted from a written scope. Compare these recurring costs with the support tier of your current vendor.
What should I ask for when comparing quotes?
Ask each vendor or partner for a line-by-line breakdown so you can compare like with like:
- Customer.io: the plan tier, profile count at your expected peak, email volume, and the features that need a higher tier, such as HIPAA.
- Dittofeed: the infrastructure sizing for your event rate, provider rates for email and SMS, and the internal or partner hours for setup, migration and upkeep.
For both, ask what is one-time and what recurs, and what changes if your audience doubles. Use a three-year view to make the totals comparable.
What a move from Customer.io to Dittofeed involves
The sequence moves people, event tracking, segments, journeys and sending providers across in an order that lets you prove the new system sends the same messages before the old one is switched off. Each phase is owned by a named team and closes with a check you can verify.
Inventory journeys, templates and sending setup
Before exporting anything, list every journey, broadcast, template, segment and event your current Customer.io workspace relies on, along with the email and SMS providers it sends through. This is a review step that your marketing operations lead and an engineer complete together. Customer.io's people and attribute export does not carry journeys or templates, so this inventory is the only record of them unless you copy them out by hand. It is done when each item has an owner and a target in Dittofeed or an explicit decision to retire it.
Export people and attributes
Export people and their attributes from Customer.io as CSV, optionally filtered by segment, and store the files in a location your data protection policy allows. Clear or exclude sensitive fields you do not need to carry over, and check the file against your inventory. The export does not include journeys, templates or message history, so those are rebuilt in later steps. It is done when record counts and key attributes have been checked against the source workspace.
Load people into Dittofeed
Bring the exported people and attributes into Dittofeed through the API or your data pipeline, so user records and traits exist before live events arrive. Your engineering team owns the import and the mapping of Customer.io attribute names to Dittofeed user traits. It is done when a sample of users matches the source records on identifiers and key attributes.
Repoint event tracking to Dittofeed
Change where application events are sent, either by pointing your Segment sources or reverse ETL flows at Dittofeed or by calling the Dittofeed API directly from the services that emit events today. Engineers own this change and should review the event names and properties against what your segments and journeys expect. It is done when events from a test environment reach Dittofeed with the expected fields and appear on the correct user records.
Rebuild segments, templates and journeys
Recreate each segment, template and journey from the inventory in Dittofeed. Templates can be written in HTML or MJML or built in the low-code editor, and Dittofeed supports branch-based git workflows if you want changes reviewed and versioned. Keep the testing SDK in mind for checking campaigns in CI. It is done when each rebuilt journey has been tested with sample users and signed off by the team that owns the message.
Connect SendGrid or Amazon SES
Dittofeed integrates with email service providers such as SendGrid and Amazon SES rather than sending email itself, so configure the provider you already use or set up a new account, with its sending domain, authentication records and suppression handling. Your platform or email operations team owns this work. Confirm with the provider that sending limits and domain reputation can support the traffic you expect. It is done when test messages arrive from the new configuration with authentication passing.
Run both systems in parallel until messages match
Run Customer.io and Dittofeed side by side, with a defined set of journeys sending through each, and compare what each system sends, to whom and when. Investigate every difference in segment membership, timing or content before cutting over. Dittofeed is an alpha-stage open-source project, so keep a rollback path and a named owner for upgrades and fixes. It is done when your comparison shows the messages match for the agreed journeys and the team accepts the cutover plan in writing.
Cut over and retire the hosted account
Switch live sending to Dittofeed journey by journey, stop the matching Customer.io journeys, and keep the hosted account readable until your records and any retention obligations are satisfied. Confirm the contract terms and data handling steps with Customer.io before you cancel. It is done when all in-scope journeys send only from Dittofeed and the final export and retention checks are signed off.
Questions buyers ask before switching
How much effort does switching from Customer.io to Dittofeed take?
The effort depends mostly on how much of your messaging logic lives in Customer.io and how cleanly your event data is already structured. The main work items are exporting people and attributes, repointing event tracking through Segment, reverse ETL or the Dittofeed API, rebuilding segments and journeys, moving templates into HTML or MJML, and connecting your email provider such as SendGrid or Amazon SES. Journeys and templates do not come out of Customer.io as a simple export, so plan to rebuild them by hand. Running both systems in parallel until messages match is the step that usually takes the most care. Ask any implementation partner for a written scope that lists each of these items before agreeing a timeline.
Can our own team migrate to Dittofeed without outside help?
A team with solid backend engineering, familiarity with its event pipeline and some experience running containers can often do the migration in house. Dittofeed documents Docker Compose and Render deployments, and Helm charts are in its repository, so the deployment path is well defined. The harder parts are event schema decisions, template rebuilding, deliverability setup with your email provider and the parallel run. Be honest about whether you have an engineer who can own the platform after go-live, because the open-source model moves operational responsibility to you. Outside help can cover any part of this, from a single review to the full build, under a fixed-scope written agreement.
What do our engineers need to know before a Dittofeed project?
Your engineers should understand how events are emitted today, how user identifiers are set, and which attributes drive segments and journeys. They also need to be comfortable with the deployment stack, secrets handling and database operations inside your own VPC. On the templating side, Dittofeed supports HTML, MJML and a low-code editor, and its git-based workflows and testing SDK for CI suggest that campaign changes can go through the same review process as application code. Check the current Dittofeed documentation for how each of these is configured in your version, since the project is still changing quickly.
Is Dittofeed production ready given its alpha releases?
Treat Dittofeed as early-stage software until you have verified otherwise for your own use case. Its recent GitHub releases are pre-release tags, with v0.24.0-alpha.21 published on October 4, 2026, which signals an active project that has not yet settled on a stable release line. The MIT license means you can fork, pin a version and maintain your own patches, but that also means your team or a partner carries the upkeep. Before going live, pin a specific release, test upgrades in staging, review the issue tracker for open problems in your channels, and agree on who fixes what when something breaks. Ask your support provider how they handle alpha-stage upgrades and rollbacks.
What support is available for an open-source project still in alpha?
Support for Dittofeed comes from the open-source community, the project's public repository and whatever commercial support arrangement you put in place yourself. There is no vendor-backed service level in the way a hosted product offers one, so ask any provider you consider to define response expectations, escalation paths and upgrade handling in writing. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted open-source platforms inside your infrastructure, and offers ongoing support and upgrades as retainers. Those terms are agreed in writing before work starts.
How does EU data residency change the choice between these two?
Self-hosting Dittofeed lets you keep personal data in infrastructure you choose, including an EU region, which is the main reason many teams consider it. Customer.io fixes the data region at account setup and does not migrate accounts between regions, so a region change means a new setup. With Dittofeed, the data stays where you deploy it, but your email, SMS and push providers still process message data, so check where each of them processes and stores it. Confirm the residency position with your legal and privacy teams, and do not assume that self-hosting alone settles every transfer question.
What drives the cost of switching, and what should we ask for in a quote?
Cost has four main parts: the engineering time to migrate and rebuild journeys, the infrastructure and database you run, the email and SMS provider fees you pay directly, and the ongoing operations effort. Dittofeed's license is free, and it states that self-hosting avoids volume-based pricing, but the other components are real costs that recur. Customer.io's pricing is based on profiles and email volume, so the comparison depends on your own profile count and send volume. Ask any provider for a written scope that separates one-time migration work from recurring hosting, support and upgrades, and that names each third-party fee it expects you to pay.
How DeployOpen helps you evaluate and run Dittofeed
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Customer.io vs Dittofeed, we start with a written scope that covers your event sources, channels and sending providers, then build and test the deployment in your environment.
How we scope
- Inventory the events, profile attributes, segments and journeys your team runs in Customer.io today.
- Confirm the data path: Segment, reverse ETL or the Dittofeed API, and which systems send events.
- Agree in writing which email, SMS and push providers connect, and who holds those accounts.
How we build
- Deploy Dittofeed in your own cloud account, data center or network using the documented Docker Compose, Render or Helm options.
- Rebuild priority segments and journeys, and move templates into HTML or MJML kept under version control.
- Set up CI checks with the testing SDK and run parallel sends until message output matches the baseline.
How we hand over
- Document architecture, data flows, configuration and campaign workflows for your engineers and compliance reviewers.
- Provide runbooks for backups, upgrades, access control and incident response within the agreed scope.
- Prepare the systems and evidence your internal or external assessors will need, without issuing any audit opinion.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan upgrade windows around Dittofeed's pre-release tags, testing each candidate build before it reaches production.
- Ask us to confirm the current release status and support boundaries before you commit to production use.
