Klaviyo vs Dittofeed: when a product-led team should self-host its journeys
A product or app team on Klaviyo should move its journeys to self-hosted Dittofeed when engineers own the messaging logic, app events and push, WhatsApp and SMS need to run from one codebase, and customer data must stay inside the company's own VPC. Klaviyo fits better when marketers build and change flows themselves, the store's e-commerce data is already flowing into it, and the team prefers a hosted service that its vendor operates. The split is less about features than about who does the work and where the data sits.
Klaviyo is built around e-commerce data and marketer-led flows, with hosted operations and most of the setup done through its interface. Dittofeed takes user data from Segment, reverse ETL or its API, builds segments, and sends broadcasts and automated user journeys over email, mobile push, SMS, WhatsApp and Slack. Its templates can be written in HTML or MJML or built with a low-code editor, and it documents git-based version control for campaigns, email templates kept in git, and a testing SDK for checking campaigns in CI. Dittofeed says self-hosting keeps sensitive personal data inside the operator's VPC and avoids volume-based pricing. For a team where engineers ship journey changes through code review, that workflow is the main attraction.
The decision turns on four questions. First, the channel mix: confirm that the email provider you plan to use, such as SendGrid or Amazon SES, and your SMS and WhatsApp providers are supported for the sends you need. Second, marketer ownership: if non-engineers must edit journeys daily, measure how much of that Dittofeed's current interface covers. Third, in-house engineering capacity to run, upgrade and back up the platform. Fourth, data residency: check whether your rules require event data to stay in a specific region or account. Dittofeed's public GitHub releases are still pre-release tags, so ask for the production readiness plan before committing.
Which option fits which scenario
This table maps common team situations to the platform that usually fits better, with the reason tied to Dittofeed's supplied capabilities and Klaviyo's hosted, e-commerce-focused model. Read each row against your own channels, data sources and staffing, and treat the fit as a starting point for confirming requirements. The main takeaway is that Dittofeed suits event-driven messaging run by engineers, while Klaviyo suits store marketing run by marketers.
| Scenario | Better fit | Reason |
|---|---|---|
| Mobile app needing push and in-app triggers | Dittofeed | Dittofeed sends automated journeys over mobile push alongside email and SMS, driven by user data from its API or Segment. |
| Store needing pre-built e-commerce flows and forms | Klaviyo | Klaviyo ships store-focused flows, forms and product feeds built around e-commerce data. Dittofeed requires you to model that data yourself. |
| Regulated team needing data in its own VPC | Dittofeed | Dittofeed states that self-hosting keeps sensitive personal data inside your own VPC. Confirm the deployment model with your assessor. |
| Marketing team without engineers | Klaviyo | Dittofeed templates and journeys are developer-oriented, and its git workflows and testing SDK assume engineering support. |
| Team with an existing Segment pipeline | Dittofeed | Dittofeed takes user data from Segment directly, so existing event flows can feed journeys without a rebuild. |
| Team wanting email templates in version control | Dittofeed | Dittofeed keeps email templates in git and supports branch-based campaign version control and CI checks. |
| Team needing marketer-friendly reporting and polish | Klaviyo | Dittofeed's marketer-facing features are less mature. Confirm the reporting and editor features you need against its current release. |
| Team with unpredictable volume growth | Dittofeed | Dittofeed says self-hosting avoids volume-based pricing, so costs follow your hosting and email provider usage instead of profile counts. |
How Dittofeed builds event-driven journeys from app data
Dittofeed takes user data from three places: a Segment connection, reverse ETL from your warehouse, or the Dittofeed API. For a product or app team, the practical question is which of these already carries the events your journeys need, such as sign-up, feature use, plan changes and purchases. Klaviyo often receives this data through its own storefront integrations, so you will need to map each Klaviyo event name to an equivalent event your app or pipeline can send to Dittofeed. Before you build anything, write down the event schema, the user identifier you will use across channels, and which events are trusted enough to trigger a message. Confirm with your Segment or warehouse owner that these events are delivered in the shape Dittofeed expects, and check the current API reference in the project repository, since the product is still pre-release.
Once user data arrives, you build user segments from it using multiple operators, then attach those segments to automated user journeys or one-off broadcasts. A journey is event-driven: a user entering a segment or performing an action moves through steps such as waits, conditions and messages across email, mobile push, SMS, WhatsApp or Slack. Message content is designed in HTML, in MJML, or in the low-code editor, and templates can be kept in git so changes go through review like any other code. The most important piece is what Dittofeed does not do: it integrates with email service providers such as SendGrid and Amazon SES rather than sending mail itself. Your team must therefore provision the ESP account, verify sending domains, manage bounces and complaints, and configure SMS and WhatsApp providers, all of which remain separate ongoing responsibilities.
The ESP decision also changes your cost model and your compliance scope. Dittofeed is MIT licensed, so the software itself carries no license fee, but you pay for hosting, the database, the ESP and any SMS or WhatsApp provider, plus the engineering time to operate them. Ask any implementation partner to quote each of these components separately and to state who holds the ESP contract and the sending reputation. Dittofeed's own documentation says self-hosting keeps sensitive personal data inside your own VPC. That benefit only holds if the ESP, SMS provider and event sources are also configured within your data handling rules, so map every recipient of personal data in the flow before go-live.
Where your customer data lives under each option
Moving from Klaviyo to Dittofeed changes who operates the system holding your profiles, events and consent records. The cards below cover where that data sits, who runs the software, how access is controlled, what auditors will ask for, and which third parties still receive message data either way.
Data location and residency
On Klaviyo, profiles, events and consent records sit in Klaviyo's hosted environment, and your residency options are whatever Klaviyo offers. With Dittofeed, you choose the region and network, and Dittofeed says self-hosting keeps sensitive personal data inside your own VPC. Confirm which regions and subnets your data will use, where backups are stored, and whether any log or analytics store copies personal data outside that boundary.
Hosting model and operations
Klaviyo is operated entirely by its vendor, so patching, uptime and scaling are their responsibility. Dittofeed is deployed by your team or by an implementation partner using Docker Compose, Render or the Helm charts in its repository. Your team then owns upgrades, database backups, secrets rotation and capacity. Ask who will run the on-call rota and how upgrades will be tested, since Dittofeed's recent releases are still pre-release tags.
Identity and access control
Klaviyo manages user roles and account access inside its own console. With Dittofeed, access to the dashboard, the API keys and the database is controlled by your infrastructure. Define who can edit journeys, who can export profiles, and who can read API credentials, and confirm how the platform's authentication integrates with your single sign-on. Treat the Segment write key and reverse ETL credentials as sensitive, because they control what data enters the system.
Compliance evidence and auditors
Self-hosting moves more of the control evidence to you: access logs, change records, backup restores and vendor reviews. DeployOpen can plan, configure and document these controls and prepare the evidence that an assessment will need. Only independent auditors and certification bodies issue audit reports or attestations, so confirm with your auditor which controls they will test before the implementation is scoped.
Third-party senders and SMS providers
Dittofeed does not send email itself, so it passes messages to an email service provider such as SendGrid or Amazon SES. SMS, WhatsApp and push messages also pass through the channel providers you connect. Under Klaviyo, its sending partners receive similar message data. In both cases, the provider contracts, data processing terms and regional routing of recipient data determine your exposure, so list every processor before you cut over.
Developer workflows versus marketer workflows
In Dittofeed, campaigns and journeys sit closer to application code. The team that owns product events often also owns the messaging logic, and changes move through the same review and release habits used for the rest of the stack. The project's repository describes branch-based git workflows for campaign version control, email templates kept in git, and a testing SDK for checking campaigns in CI.
- Branch-based changes: Campaign and journey edits can live on git branches and pass pull request review before reaching production.
- Templates in git: Email templates are stored as files, so diffs, history and rollback work the way they do for other code.
- Testing in CI: The testing SDK lets a pipeline check campaigns before release. Confirm its exact coverage against the release you plan to run.
- API ingestion: Profile and event data arrive through Segment, reverse ETL or the Dittofeed API, so engineers must instrument events and maintain the payload contract.
- Self-managed operations: Docker Compose and Helm chart deployments mean your team owns upgrades, database backups and the connection to the email provider.
Before committing, list the events your product already emits, name the person who will maintain the event schema, and confirm your release pipeline can run the testing SDK.
Klaviyo keeps most campaign work in a hosted interface that marketers use directly, with templates, segments, flows and reporting available without a developer. Marketers who build and send campaigns themselves should not assume the same workflow appears in Dittofeed. Dittofeed supports HTML and MJML templates and a low-code editor, so the editing experience is the part your marketers will judge first.
- Editing journeys: Decide who may change a live journey. In a git-based setup, a small copy change may need an engineer or a pull request, which changes how quickly marketers can react.
- Visual editor: Test whether your team can rebuild the layouts they use in Klaviyo with the low-code editor alone, without developer help.
- Approval habits: Replace informal sign-off in the Klaviyo interface with a written review step, named approvers and a record of who approved each send.
- Reporting: List the send, open, click and conversion reports your team relies on. Confirm whether Dittofeed provides each one or whether they must be built from exported data.
- Segment building: Dittofeed builds segments with multiple operators. Check that the audience logic your marketers use today can be expressed in its interface.
Before committing, take the last ten campaigns your team sent and confirm each one can be built, approved and reported on without a developer.
The same work moves to engineers in Dittofeed and to marketers in Klaviyo. In Klaviyo, a marketer often owns the whole chain from audience to report. In Dittofeed, that chain is split across the team, so each side must learn part of the other's vocabulary. Marketers need basic git and review habits, while engineers need to understand audience logic, consent rules and send timing. Campaigns stall when nobody owns the handoff between them.
- Event naming: Agree on event and trait names with marketing before instrumenting, because journeys depend on them.
- Consent and suppression: Marketing defines consent rules, and engineering enforces them in the data pipeline. Document who answers questions about opt-outs.
- Review and rollback: Name who reviews a change, who approves a send and who can roll back a journey that misbehaves.
- Email provider setup: Sending runs through a provider such as SendGrid or Amazon SES, so sending domains, bounce handling and deliverability settings need one named owner.
- Training time: Budget time for both teams to learn the new workflow. Ask the vendor or your implementation partner for a written training plan as part of the scope.
Before migration begins, assign one owner for each channel and one owner for the event schema, and confirm both owners are on the same review process.
What drives the total cost of each option
Klaviyo's bill grows with the number of active profiles, while Dittofeed carries no license fee but moves cost onto infrastructure, messaging providers and engineering time. The cards below separate one-time work from recurring spend so you can compare written quotes on the same basis.
Klaviyo subscription by active profiles
Klaviyo's recurring fee is driven by the number of profiles you keep active, so the bill tends to rise as your audience and engagement tracking grow. Ask your Klaviyo account team how active profiles are counted, which features sit in each tier, and what happens to the rate when your list passes the next band. Use your own profile counts, not the sales forecast, when you build the comparison.
Dittofeed software license
Dittofeed is MIT licensed and describes itself as free forever, so there is no license fee to budget for the software itself. Confirm the license terms in the repository before you rely on them, and note that the project's recent releases are pre-release tags, which affects how you plan upgrades. The license cost is zero, but the cost of running it is not.
Hosting, database and infrastructure
You pay your cloud provider or data center for compute, a PostgreSQL database, storage, backups and networking. Dittofeed states that self-hosting keeps sensitive personal data inside your own VPC and avoids volume-based pricing, but that does not make infrastructure free. Ask for an estimate that covers production, staging and backups, and note that these costs recur every month.
Messaging provider and channel fees
Dittofeed integrates with email providers such as SendGrid and Amazon SES rather than sending email itself, so you pay them per message. SMS and WhatsApp add separate provider fees and possible registration costs. Klaviyo bundles some sending into its subscription, so compare sends, SMS and WhatsApp volume line by line instead of assuming like for like.
Segment and data pipeline costs
Dittofeed takes user data from Segment, reverse ETL or its API. If you already pay for Segment or a similar pipeline, that cost continues, and it often scales with tracked users or events. If you feed Dittofeed through the API instead, the cost moves to engineering time to build and maintain the event flow. Ask which pipeline you will use and what it costs at your event volume.
Implementation and migration labor
Rebuilding flows, segments, templates and event tracking is mostly one-time labor, whether done by your team or a partner under a fixed-scope written agreement. Dittofeed's journeys are configured through code and git workflows, so the setup effort depends on how many journeys and templates you port. Ask for the scope in writing, including data mapping, testing in CI and cutover support.
Upgrades and staff time
Ongoing upgrades, security patches, backup testing and on-call coverage recur for as long as you run the platform. Because Dittofeed's releases are alpha pre-release tags, plan for more frequent testing before each upgrade than you would for a stable product. Ask any implementation partner whether upgrades, monitoring and support are covered by a retainer or billed separately, and how staff time is counted.
What moving from Klaviyo to Dittofeed involves
The sequence turns Klaviyo flows, segments and consent into Dittofeed journeys running on your own infrastructure, with a parallel period that proves the new stack before Klaviyo is switched off. Each step ends with a check you can verify before moving on.
Inventory flows, segments and templates
Marketing operations and the engineer who owns your event tracking list every active flow, campaign, segment and template in Klaviyo, noting the trigger event, the filters and the channels each one uses. Mark which journeys are revenue-critical, such as abandoned cart or post-purchase sequences, so they receive the most testing later. The step is done when every live flow has a row in a shared inventory with an owner and a trigger.
Confirm the event feed into Dittofeed
Engineering decides how user data will reach Dittofeed: through Segment, through reverse ETL, or through the Dittofeed API called from your application backend. Map each Klaviyo trigger event, such as placed order or added to cart, to an event your app or warehouse already emits, and check the property names and identifiers match. The step is done when a test user action produces the expected event in a staging Dittofeed instance.
Stand up Dittofeed inside your VPC
Platform or DevOps engineers deploy Dittofeed in your own cloud account using the documented Docker Compose or Helm chart paths, connect its database, and restrict network access so personal data stays inside your VPC. Security reviews the deployment configuration, secrets handling and backup plan before any live contact data is loaded. The step is done when staging is reachable only from approved networks and a backup restore has been tested.
Connect an email service provider
Dittofeed does not send email itself, so you connect an existing provider such as SendGrid or Amazon SES, or confirm which provider your team will use for sending. Your deliverability owner verifies sending domains, DKIM and bounce handling against the provider's own documentation, and confirms that existing sender reputation is preserved for the domain you already use. The step is done when a test message sends through the provider and bounce and complaint events return to Dittofeed.
Rebuild templates and journeys in code
Developers and lifecycle marketers recreate each Klaviyo template in HTML or MJML and store it in git, then rebuild each flow as a Dittofeed journey with the same triggers, delays and branch conditions. Use the branch-based git workflow so changes are reviewed like code, and write campaign tests with the testing SDK for the flows that matter most. The step is done when every inventoried flow has a Dittofeed equivalent, a reviewed pull request and passing CI checks, and any Klaviyo feature without a match is recorded as a gap.
Migrate consent and suppression lists
Legal and marketing operations export subscription status, consent records, unsubscribes and suppression lists from Klaviyo, then load them into Dittofeed with their original consent dates and sources where the export provides them. Confirm with your privacy or compliance lead that the consent basis for each audience carries over, and that anyone who unsubscribed in Klaviyo is suppressed before the first Dittofeed send. The step is done when suppression counts match between the two systems and a sample of records has been checked by hand.
Run parallel sends and compare results
Run Dittofeed journeys alongside Klaviyo for a defined overlap period agreed by the marketing and engineering leads, with a controlled audience so the same contact does not receive duplicate messages from both platforms. Compare delivery, open, click and conversion data against the Klaviyo baseline, and fix template rendering, event timing and personalization gaps as they appear. The step is done when results from both systems are within the tolerance the team set in advance and every issue on the defect list is closed or accepted.
Cut over and decommission Klaviyo
Once parallel results are accepted, switch sending to Dittofeed journey by journey, disable the matching Klaviyo flows, and keep Klaviyo read-only until the data you need for records has been archived. The Klaviyo export guide sets out the order to export profiles, templates, analytics and SMS numbers before cancelling, and it notes which history cannot be exported, so review it before this step. The step is done when Klaviyo sends nothing, your archive is verified, and the cancellation date is recorded in the decommissioning log.
Why Dittofeed's alpha releases change the planning
Dittofeed's recent GitHub releases are pre-release tags, not stable versions, and the latest one in the supplied record is v0.24.0-alpha.21, published on October 4, 2026. That changes how you plan a Klaviyo exit. A Klaviyo replacement that sends your welcome flows, abandoned cart messages and SMS on a platform still marked alpha needs version pinning, a tested upgrade path and a named owner before anything goes live. Read the release notes on the Dittofeed releases page and confirm with the maintainers what they consider production-ready for the features you need, rather than assuming the latest tag is safe to run.
Practically, pin the exact Dittofeed image or Helm chart version in your deployment configuration and do not track the newest tag automatically. Stand up a staging environment that mirrors production: the same Segment or reverse ETL feed, the same email provider connection such as SendGrid or Amazon SES, and a sandbox SMS or WhatsApp account. Run each upgrade through staging with your journeys and templates, and use the testing SDK to check campaigns in CI before promotion. Keep your templates and journey definitions in git so you can roll back to a known state if an upgrade changes behavior.
Decide who owns patching before cutover. Someone must watch releases, schedule upgrades, apply security fixes to the Dittofeed application, its database and the underlying containers, and hold the on-call responsibility when a journey misfires. If your team does not have that capacity, ask a provider to quote ongoing maintenance and upgrade support against a written scope, and confirm in that quote how breaking changes between alpha releases will be handled. Ask Dittofeed's maintainers how they document breaking changes between tags, since the supplied facts do not describe that process.
Questions buyers ask before choosing Dittofeed over Klaviyo
Can a marketer run Dittofeed alone without engineers?
Not on day one. Dittofeed is built for developer-led operation: it takes user data from Segment, reverse ETL or the Dittofeed API, and it is deployed through Docker Compose, Render or Helm charts. Marketers can build segments, edit templates and run broadcasts once the data feed and sending integration work, but someone with engineering skills should own the data model, the event schema and the deployment. Confirm which parts of the low-code editor your team will use daily, and which changes will still need a developer.
How much engineering effort does self-hosting Dittofeed need?
The effort is mostly one-time setup plus ongoing operations. Setup covers hosting, the database, the event pipeline from Segment or the API, sending provider configuration and the templates kept in git. Ongoing work covers upgrades, backups, monitoring and security patches. Because Dittofeed's recent GitHub releases are pre-release tags, with v0.24.0-alpha.21 published on October 4, 2026, plan for upgrades to be deliberate and tested in a staging environment. Ask your team to estimate the work against your event volume and channel count.
What drives the cost of Dittofeed compared with Klaviyo?
Klaviyo charges by active profiles, and Dittofeed states that self-hosting avoids volume-based pricing. Your cost with Dittofeed is the infrastructure you run, the sending provider's fees (such as SendGrid or Amazon SES), SMS and WhatsApp provider fees, and the internal or contracted labor to operate it. Costs rise with message volume, the number of channels, data retention and the team hours needed. Costs fall when you reuse existing cloud accounts and standardize on one event pipeline. Ask any quote to separate one-time setup from recurring operations and to list every third-party fee.
How long does a migration from Klaviyo take, and what does it depend on?
The timeline depends on how much of your Klaviyo setup must be rebuilt, not on the export itself. The main drivers are how cleanly your Segment or API event data already maps to Dittofeed user traits and events, how many flows and segments you need to recreate, how many email templates must be moved into git, and whether SMS numbers and WhatsApp senders need porting. Klaviyo's event and message history cannot be exported in full, so plan to keep historical reporting in Klaviyo or your warehouse. Ask for a written scope that lists each flow and channel before agreeing a schedule.
Do SMS and WhatsApp need separate providers with Dittofeed?
Yes, plan for a separate provider for each channel. Dittofeed sends messages over email, mobile push, SMS, WhatsApp and Slack, but it integrates with email service providers such as SendGrid and Amazon SES rather than sending email itself, so the same logic applies to SMS and WhatsApp senders. Confirm which SMS and WhatsApp providers are supported in the release you deploy, how sender registration and opt-in records are handled, and who holds the phone numbers. Porting numbers out of Klaviyo is a provider task that must be scheduled with care.
Does Dittofeed replace Klaviyo forms and landing pages?
No, not as a built-in feature. Dittofeed focuses on user journeys, broadcasts, segments and message templates across channels. Sign-up forms, pop-ups and hosted landing pages that Klaviyo offers are outside the core scope described in its repository, so you will need a separate form tool, a website component or your existing site to capture consent and profile data. Confirm the capture path before migration, and make sure consent records flow into Dittofeed with the correct channel status.
When should we hire outside help for a Dittofeed deployment?
Hire outside help when the internal team lacks time or experience with the hosting, data pipeline and security work, or when the migration must meet audit or data residency needs. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own cloud accounts or data centers, and most engagements are fixed-scope with deliverables agreed in writing before work starts. Ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so ask for a quote built from a written scope.
How DeployOpen evaluates, implements and migrates Dittofeed
DeployOpen starts with a written, fixed-scope evaluation before anyone installs Dittofeed, because the decision that matters most is architectural: which data reaches Dittofeed, through which path, and which messaging channels must work on day one. The evaluation maps every Klaviyo flow and segment to a Dittofeed journey or broadcast, identifies which user events must arrive from your app or from Segment, and records which email service provider (such as SendGrid or Amazon SES) will send the mail, since Dittofeed integrates with those providers rather than sending email itself. The output is a written scope with deliverables and timelines that you confirm before work starts. Ask for the scope to name the environment, the owners of the Dittofeed, Segment or API integration, and the marketing staff who will sign off on templates.
Implementation covers deployment in your own cloud account or VPC, so that personal data stays inside your environment as Dittofeed's own documentation describes. The Docker Compose and Render paths and the Helm charts in the repository are starting points, not finished production designs, so the work includes choosing the deployment method, setting secrets and database access, configuring the ESP connection, and hardening the network path, access controls and logging. Backups of the database that holds journey state and user data, a tested restore procedure, and an upgrade process are part of the handover. Because Dittofeed's releases are still pre-release tags, the upgrade plan should pin versions, stage them in a non-production environment and document the rollback. Ask for the written runbook, the backup and restore test evidence, and the upgrade policy in the scope.
Migration work follows the same written scope. Templates can be moved into git so that changes go through review, and the testing SDK can check campaigns in CI before they reach customers. Retainers are available for ongoing support, upgrades and continuous security testing after go-live, and are priced separately from the fixed-scope project. DeployOpen does not publish prices, so ask for a quote based on the written scope and confirm which items are one-time and which recur. DeployOpen prepares systems, controls and evidence for compliance reviews, but independent auditors issue any audit report, so confirm with your assessor which artifacts they need before the project starts.
