Does self-hosting Customer.io's replacement cost less?
Dittofeed is MIT licensed and describes itself as free forever, so the license line on your Customer.io invoice disappears. What replaces it is not zero. You take on the servers and database that run Dittofeed, the email and SMS provider fees that Dittofeed does not absorb (it integrates with providers such as SendGrid and Amazon SES rather than sending mail itself), the one-time cost of migrating profiles, segments, journeys and templates, and the engineering time to operate, upgrade and back up the platform. Customer.io charges by profiles and email volume. Dittofeed states that self-hosting avoids volume-based pricing, so the variable part of your bill moves from the vendor's meter to your own infrastructure and provider contracts, where it grows with the data you choose to run. The net result depends on three inputs you have to supply: how many profiles you hold and how many of them are reachable on each channel, how many messages and events you send per month, and how many engineers already know how to run Postgres, container platforms and a message pipeline. A low-volume team with spare platform capacity may come out ahead. A team with few internal skills may find that engineering time outweighs the license saving. No honest price comparison is possible without your own figures. Pull last year's Customer.io invoices, your provider usage reports and a realistic count of the engineer hours your platform team spends on messaging, then ask Customer.io and your provider for the numbers that apply to you. Before you commit, ask for a written quote from DeployOpen based on your scope, and confirm the open items with Dittofeed directly. Its GitHub releases are pre-release tags, with v0.24.0-alpha.21 published on October 4, 2026, so check how the project treats upgrades and support for production use before you set a support budget. Treat the migration and the first months of parallel running as a one-time cost, and treat hosting, provider fees and on-call coverage as recurring costs in your model.
Which cost components appear on each side
This table sets each cost component on the Customer.io side against the self-hosted Dittofeed side, with its timing and main driver. Use it to see which costs stay with a vendor and which move to your own budget. The main takeaway is that Dittofeed removes the license and volume-based subscription, but it adds recurring hosting, provider and engineering costs that you must budget for.
| Cost component | Customer.io | Dittofeed (self-hosted) | One-time or recurring |
|---|---|---|---|
| Platform license or subscription | Plan fee set by profiles and email volume | No license fee. Dittofeed is MIT licensed and describes itself as free forever | Recurring on Customer.io, driven by profile count and volume |
| HIPAA support | Tied to the Premium plan. Confirm current terms in writing | Depends on your own controls and on terms from each provider you use | Recurring plan cost on Customer.io. One-time evidence work on Dittofeed |
| Email sending (SendGrid or Amazon SES) | Confirm whether sending volume is included in your plan | Paid directly to SendGrid or Amazon SES, which Dittofeed connects to | Recurring, driven by message volume |
| SMS and WhatsApp provider fees | Confirm whether these channels are billed separately | Paid directly to your SMS or WhatsApp provider | Channel setup is one-time. Messages are recurring, driven by volume |
| Servers and databases | None. Hosting is part of the subscription | Compute and database for your VPC or cloud account, sized by users and events | Recurring, driven by user count and event throughput |
| Implementation and data input | Internal effort to set up event tracking and rebuild templates | Deployment, identity setup, data input through Segment, reverse ETL or the API, and templates in HTML or MJML | One-time. A fixed-scope services quote applies if you hire a partner |
| Migration of people, journeys and templates | Export covers people and attributes as CSV. Confirm what else you can export | Rebuild segments and journeys, then run both systems until messages match | One-time on both sides. Journeys and templates usually need manual rebuilding |
| Upgrades, patching and support | Included in the subscription. Confirm the support tier you need | Your team or a retainer covers upgrades. Releases are pre-release alpha tags, such as v0.24.0-alpha.21 published on October 4, 2026 | Recurring. Driven by release frequency and how much testing you run |
| Internal engineering time | Lower. Mostly campaign configuration and operations | Engineers to run, monitor, back up, secure and maintain the stack | Recurring. Driven by staffing model and how much you self-manage |
What moves the comparison most
Customer.io bills on profiles and message volume, while self-hosted Dittofeed carries no license fee and its costs follow infrastructure, provider fees and the people who run it. The factors below decide which side grows faster as your program expands, so size each one against your own numbers before you request a quote.
Profile count and growth
Customer.io prices its plans by the number of profiles you store, so every new customer record raises the subscription even when messages stay flat. Dittofeed is free to self-host and avoids volume-based pricing, so profile growth shows up instead as database storage, compute and segment evaluation load on your own servers. Ask your team for the current profile count and its growth rate over the last year, then model both curves before choosing a path.
Email and SMS message volume
Message volume affects two bills at once: Customer.io's plan tier and the fees your email and SMS providers charge Dittofeed for sending. Dittofeed integrates with providers such as SendGrid and Amazon SES rather than sending email itself, so a self-hosted program still pays per message to the provider, and that cost is the one most teams underestimate. Confirm your monthly send counts by channel and each provider's current rate card.
Number of channels in use
Dittofeed supports email, mobile push, SMS, WhatsApp and Slack, and each channel you add needs its own provider account, credentials, templates and delivery monitoring. Customer.io also charges differently by channel, so list which channels you use today and which you plan to add within the next contract term. Each extra channel adds integration work at setup and ongoing support work after go-live.
Journeys and segments
Complex automated journeys and large segment logic increase compute and database load on a self-hosted Dittofeed deployment, and they also increase the testing and migration effort. Rebuilding journeys is usually a one-time cost, while the ongoing cost depends on how often your team edits them. Count active journeys, segments and templates, and identify which ones depend on Customer.io-specific features that must be rebuilt rather than copied.
Availability and data residency
If you require HIPAA coverage or a fixed data region, check which Customer.io plan provides it and what it costs to keep it, because the hosted price for that tier can change the comparison sharply. Self-hosting keeps sensitive personal data inside your own VPC, but it also moves uptime, backups and regional controls onto your team. Ask Customer.io in writing which plan and region terms apply, and map your own availability targets to a self-hosted operating model.
Existing container and hosting skills
Dittofeed documents Docker Compose and Render deployments and ships Helm charts in its repository, so the fastest path depends on what your team already runs. A team with Kubernetes operations experience can absorb the platform into existing clusters, while a team without that skill will pay for training or outside support. Inventory who on staff can operate databases, upgrades and monitoring, because that labor is the largest recurring cost in a self-hosted setup.
How to build the cost model with your own numbers
This sequence turns your current Customer.io bill and sending habits into a side-by-side cost model for self-hosted Dittofeed, with each component priced by its owner. The output is a set of scenarios you can take to finance and to implementation partners for written quotes.
Export your current profile and volume data
Pull your own figures from the Customer.io account: the number of people profiles you are billed for, and monthly send volumes for email, push and SMS over the last several billing periods. Ask the account owner to confirm which profiles the invoice counts, since the billing definition is the one you will compare against. Done when you have a dated table of profiles and sends per channel, with the source of each number recorded next to it.
List every channel and integration in use
Walk through each campaign and journey with the marketing and product owners and record the channels it uses: email, mobile push, SMS, WhatsApp or Slack. Also note which data sources feed Customer.io today, such as Segment, reverse ETL or direct API calls, because each one carries its own engineering cost after migration. Done when every active journey maps to a channel list and a data source, and the list is signed off by the team that owns each journey.
Price the provider fees you already pay
Dittofeed sends through your email and SMS providers rather than sending messages itself, so those fees stay in the model. Collect the current contracts or invoices from SendGrid, Amazon SES and your SMS vendor, and note the unit price, any monthly minimum, and the volume tiers that apply to your sends. Ask each provider to confirm whether a change of sending account or IP warm-up would affect rates. Done when each provider's cost is expressed per message or per month for the volumes in step one.
Estimate hosting in your own VPC
Dittofeed documents Docker Compose and Render deployments, and Helm charts are in its repository, so the hosting cost depends on which path your platform team will use. List the compute, PostgreSQL database, storage, backup, monitoring and network components in your own cloud account, and price each one from your provider's current rate card. Ask your infrastructure team to confirm the sizing for your expected event volume, because it is not set by the license. Done when you have a monthly hosting estimate for production and a separate one for staging, each itemized by component.
Add migration and parallel-run effort
Migration covers exporting people and attributes, repointing event tracking, rebuilding segments and journeys, connecting the email and SMS providers, and running both platforms until messages match. Plan these as one-time costs and ask a delivery partner or your own team to estimate each task in writing. Parallel running adds cost because you pay for Customer.io and the new stack for the same period. Done when every migration task has an owner, an estimate source, and a parallel-run period agreed with the business.
Assign internal engineering allocation
Dittofeed is an open-source project whose recent GitHub releases are pre-release tags, so someone in your organization must own upgrades, incidents, template changes and vendor-neutral support. Estimate the share of named engineers' time for build, run and change work, and record it as a recurring cost at your internal loaded rate. Include security patching and backup testing, which you carry directly when you self-host. Done when each role has a time allocation in hours or percent per month and a named owner.
Model three scenarios and request written quotes
Build a low, expected and high scenario by varying profile count, send volume and the engineering allocation, keeping the one-time and recurring costs separate. Ask at least two implementation firms for a written fixed-scope quote that matches your component list, and ask Customer.io to confirm its current plan terms for your profile count and any HIPAA requirement. Use the scenarios to test where the break-even point falls for your organization. Done when the model shows total cost over a fixed period for each scenario, every line cites its source, and the quotes are attached.
Where provider fees and infrastructure stay on your bill
Moving to Dittofeed does not remove the sending bill. Dittofeed integrates with email service providers such as SendGrid and Amazon SES rather than sending email itself, so the per-message charges that Customer.io currently bundles into its plan become invoices you pay directly to your provider. Confirm the provider's pricing tiers, sending limits and any dedicated IP or SMS sender fees with your account team before you model the switch, and keep those lines in the total cost of ownership from day one. The provider invoice is the cost most often forgotten in a comparison.
Infrastructure is the second recurring line. Dittofeed runs as a set of services backed by a database, and the Docker Compose and Render deployments, along with the Helm charts in the repository, describe what you host. Each of these is a compute, storage and backup cost that grows with the deployment: more environments for staging and production, higher event throughput, longer retention and redundancy for recovery. Ask your cloud or data center team to price the servers, managed or self-run databases, load balancing, monitoring and backups for your target architecture, and to state which of these are one-time setup and which recur monthly.
Dittofeed states that self-hosting avoids volume-based pricing, which is the core of the cost argument. That is a statement about the pricing model, not a guarantee of a lower total. Your infrastructure and provider costs still rise with message volume, and the saving depends on your profile count, send volume and how much engineering time the hosting requires. Build two scenarios from your own numbers, one at current volume and one at the volume you expect in two years, and compare each against a Customer.io quote for the same profiles and sends. Both must include the provider fees, not only the platform line.
What an alpha-stage project means for your budget
Keeping Customer.io means the vendor operates the messaging infrastructure, applies its own platform updates and carries the uptime work. Your budget is mostly a recurring subscription that moves with the number of profiles and email volume, plus any higher tier that includes features you need. Internal effort stays smaller, but it does not disappear, because your team still builds journeys, maintains data pipelines and manages sending domains.
- Recurring subscription: Cost follows profiles and email volume, so growth in either raises the bill without any change to your architecture.
- Feature tiers: Requirements such as HIPAA coverage sit on a higher plan, so confirm which tier you need before modeling totals.
- Low platform labor: Hosting, patching and platform upgrades are the vendor's responsibility, which keeps internal engineering time focused on integrations.
- Exit cost: Moving later means exporting people and attributes, then rebuilding journeys and templates, and that work grows with the account.
Check the current plan terms and your expected profile count and send volume in writing before comparing totals.
Dittofeed is MIT licensed and describes itself as free forever, so the software line item is zero. The cost moves to infrastructure and people: servers, databases, email and SMS provider fees, and the engineers who deploy and operate the system. Docker Compose, Render and Helm chart deployments reduce setup work, but production hosting still needs monitoring, backups and access control under your own policies.
- Infrastructure: Compute and database capacity must be sized to your event volume and tested before launch.
- Provider fees: Amazon SES or SendGrid bills for each message sent, and SMS and WhatsApp carry their own charges.
- Operations staff: Engineers handle deployment, monitoring, incident response and on-call coverage, which is the largest recurring cost for most teams.
- Migration project: Exporting data, repointing event tracking and rebuilding journeys is one-time work, followed by a period of parallel running.
Ask your team to list each of these lines with an owner and a recurring or one-time label before comparing them with the subscription.
The recent Dittofeed GitHub releases are pre-release tags, with v0.24.0-alpha.21 published on October 4, 2026. A pre-release tag signals that the project has not declared a stable release line, so upgrades may change behavior or configuration between versions. That affects how many engineering hours you reserve for upgrades, regression testing and fixes you cannot postpone.
- Upgrade effort: Each release may need a staging test, a review of configuration changes and a tested rollback plan, all of it internal labor unless you contract it out.
- Testing discipline: The testing SDK for checking campaigns in CI helps catch breakage early, but your team still writes and maintains those tests.
- Version pinning: Pinning a known version keeps production stable, but it delays security fixes that someone must then apply by hand.
- Outside support: A retainer for upgrades and fixes moves that risk into a written scope, with the work priced from what is agreed.
Model upgrade time as a recurring line until the project publishes a stable release line you can rely on.
Before you finalize any cost model, confirm the current release status and support model directly with the Dittofeed project. The releases page shows which tags are current, but it does not settle support commitments, response times or security patch policy, so put those questions to the maintainers in writing. The answers decide whether the budget needs internal staff, an outside retainer or both.
- Release channel: Ask which tag the maintainers recommend for production and how long each release line receives fixes.
- Security patches: Ask how vulnerabilities are disclosed and how quickly fixes ship for supported versions.
- Breaking changes: Ask where migration notes and configuration changes are published for each release.
- Commercial support: Ask whether the project or any partner offers paid support, and what each option covers.
Record the answers in your model before requesting a quote, since they set the scope of any fixed-scope engagement.
Questions buyers ask before comparing costs
How much effort does a Customer.io to Dittofeed migration take?
The effort depends mainly on how many journeys, segments and templates you run and how clean your customer data is. The work has four parts: exporting people and attributes, repointing event tracking through Segment, reverse ETL or the Dittofeed API, rebuilding segments and journeys, and connecting an email provider such as SendGrid or Amazon SES. Journeys and templates usually have to be rebuilt by hand, so confirm what Customer.io exports for your account before you plan the rebuild. A team with one developer who knows the event pipeline and one marketer who knows the journeys can often do the core work alone, but the first migration usually takes longer than expected. If you want outside help, DeployOpen plans, implements and supports this kind of migration under a fixed-scope written agreement.
What does running Dittofeed need from engineers day to day?
Day-to-day work is smaller than the migration but it does not stop. Engineers need to keep the deployment running, which the project documents through Docker Compose and Render, with Helm charts in its repository for Kubernetes users. Ongoing tasks include:
How long should a parallel run last before switching off Customer.io?
Keep both systems running until the messages from Dittofeed match what Customer.io sends for the same people, and the length of that period depends on what drives your traffic. The main drivers are the number of journeys that wait for a delay or event before the next step, because those people stay in flight during cutover. Other drivers include message volume, how many channels you use, how many event sources feed the system, and whether your email provider needs time to build sending history for a new configuration. Set exit criteria in advance, such as matching send counts for each journey and reviewing bounce and complaint rates, and do not base the cutover on the calendar alone. Ask your implementation partner to write these criteria into the scope before work begins.
Does HIPAA on Customer.io Premium have a self-hosted equivalent I must document?
Customer.io offers HIPAA support on its Premium plan, but self-hosting does not hand you an equivalent certification. Running Dittofeed in your own VPC keeps sensitive personal data inside your environment, yet you become responsible for the controls that the HIPAA Security Rule requires of covered entities and business associates. Those controls include access management, encryption, audit logging, backup and recovery, risk analysis and documented policies. You also need to confirm with each email and SMS provider whether it will sign a business associate agreement and what it will process. Ask Customer.io exactly what its Premium HIPAA terms cover so you can compare scopes. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations. Independent auditors and certification bodies do that work.
Can a fixed-scope implementation fee replace hiring internal engineers?
A fixed-scope fee usually covers a defined one-time project, while hiring creates a recurring salary cost, so the two often serve different purposes. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. That covers the migration, integration and handover. It does not remove the need for an internal owner who decides what to send, to whom and when, and who answers for campaign data and consent. Ongoing support, upgrades and continuous testing are available as retainers, which can replace some in-house effort without replacing a staff role. Compare the fee with the internal hours a migration would consume, plus the salary of any engineer you would need to keep the platform running after go-live.
What should a written quote for a self-hosted messaging migration include?
A useful quote lists the scope in enough detail that two vendors could price the same work. Ask for these items:
Is an alpha-stage open-source release safe to run for production messaging?
Treat it as a release that needs a controlled upgrade process, because the project publishes pre-release tags. The latest release listed in its GitHub releases page is v0.24.0-alpha.21, published on October 4, 2026, so confirm the current tag before you plan. Pin the exact version in your deployment, test each upgrade in a staging environment with copies of your templates and segments, and read the release notes for changes to APIs or configuration. Decide in advance who triages bugs and whether you will carry patches. Dittofeed is MIT licensed and describes itself as free forever, so the cost of an alpha release is operational risk and staff time rather than a license fee. Ask the upstream maintainers what support they offer, and ask DeployOpen what a retainer covers for upgrades, testing and incidents.
When the self-hosted option makes financial sense
The self-hosted option makes financial sense when per-profile pricing becomes the dominant line item. Customer.io bills by profiles and email volume, so the cost rises with every person you message, not only with the number of messages you send. Dittofeed's own project description says self-hosting avoids volume-based pricing, which changes the cost curve: the license is free, and your spend shifts to servers, databases, email and SMS provider fees and the engineers who run the stack. Ask Customer.io for a quote at your projected profile count and at double that count. If the second figure drives a large step up and your internal cost of running Dittofeed grows slowly, the business case holds. Build the comparison with your own volumes, because the break-even point depends on your channel mix and on who already staffs your infrastructure.
The second condition is data control. Dittofeed states that self-hosting keeps sensitive personal data inside the operator's own VPC. If your legal or security team requires that event payloads, attributes and message logs never leave your cloud account, the hosted subscription may not be available to you at any price, and the self-hosted path becomes a compliance decision rather than a cost decision. Confirm with your privacy and security leads which data must stay inside your boundary, and remember that your email and SMS providers still receive message content and recipient addresses. Those providers are separate processors with their own fees, and they belong in the same cost model.
The business case also depends on capacity and risk tolerance. Running Dittofeed means someone owns upgrades, backups, monitoring and on-call response, and the project's releases are still pre-release tags, with v0.24.0-alpha.21 published on October 4, 2026, so you should expect breaking changes and budget time for testing before each upgrade. If you have platform engineers who already operate PostgreSQL, container platforms and CI pipelines, the marginal cost is manageable. If you have a small marketing team without platform engineers, Customer.io usually remains the better choice: its hosted service carries the operational burden, its support model is established, and the cost of a single outage or a stalled migration can exceed years of subscription fees. Ask any implementation partner for a written, fixed scope before committing.
How DeployOpen scopes a fixed-price Dittofeed implementation
DeployOpen is a Chainscore Labs company that plans, implements, hardens and supports self-hosted open-source platforms inside your own cloud accounts or data centers. For a Customer.io exit, we start by writing down what the Dittofeed deployment must cover, then build and hand it over with documentation your team can run.
How we scope
- Inventory every Customer.io workspace, message channel, segment, journey and template that the new setup must replace.
- Agree the event sources, whether Segment, reverse ETL or the Dittofeed API, and which email or SMS providers will connect.
- Record the hosting location, data residency needs and sensitive personal data rules in the written scope before work starts.
- Set out the deliverables, timelines and acceptance criteria in writing, since most engagements are fixed-scope.
How we build
- Deploy Dittofeed in your own infrastructure using Docker Compose, Render or the Helm charts in its repository, as your environment requires.
- Rebuild segments and journeys, and design email templates in HTML, MJML or the low-code editor, under git version control.
- Connect SendGrid or Amazon SES and test campaigns with the testing SDK in your CI pipeline before any live send.
- Run security testing on the deployment and its APIs, and harden access, secrets and backups as agreed in the scope.
How we hand over
- Document the architecture, configuration, data flows, runbooks and the Customer.io-to-Dittofeed message mapping for your team.
- Walk your engineers through running a parallel period so both systems can be compared until messages match.
- Provide evidence of configuration and controls that your internal or external auditors can review, without us issuing any audit report.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover, based on the written scope.
- Plan upgrades carefully, since Dittofeed's recent GitHub releases are pre-release tags, so confirm the version your team will run.
- Ask for a written quote that lists each deliverable, the environments covered and the support terms before you commit.
