Tracardi: a self hosted, API-first customer data platform engine

An engine for a CDP, not a finished CDP

The README frames Tracardi in a way that distinguishes it from most products in its category. The banner calls it a customer data and engagement suite and an open source alternative to Segment and RudderStack, while the project description calls it a composable API-first solution for any company that needs an inexpensive CDP to integrate with, and the main heading calls it an API-first composable open source customer data platform engine. The word engine matters. What is in this repository is the backend of a customer data platform, and the website is Tracardi, with the manual hosted separately at manual.tracardi.com. The audience is a company that has decided it wants to own its customer data rather than hand it to a SaaS vendor, and that has engineers willing to assemble and run the pieces. The code is Python, the default branch is 1.1.x, and the last push to the repository was on 2026-09-22.

Profiles, modelling, segmentation and real time personalisation

The feature list is the clearest statement of scope. Tracardi can collect, ingest, aggregate and store customer data from multiple sources in real time. It can model data, with rules that model data from a page and copy it into the user profile. It can personalise the user experience with real time frontend apps injected into an existing webpage, customised messages, marketing segmentation and in-time messaging. It can merge customer data from various sources into a single profile, automate the elimination of duplicate customer records, and blend customers into one account. It acts as a centralised communication and orchestration hub that integrates different parts of your IT. Social engagement is handled through Tracardi bridges that connect an e-commerce platform to social networks so customers can be rewarded for sharing products or leaving comments. The design intent is stated as reuse of current infrastructure, since Tracardi does not require complex integration or dedicated infrastructure and runs on top of cloud managed services, spinning up new resources when needed.

Running it with Docker Compose

The documented path is Docker, and it is short. You install Docker and docker-compose locally, clone the API repository on the 1.1.x branch, change into that directory and bring the stack up.

  git clone https://github.com/Tracardi/tracardi-api.git:1.1.x

cd tracardi-api
docker-compose up

Once the stack is running you open the GUI at the local address and complete the installation there.

Two ports are named in the README, and they are worth keeping straight: the web interface is on 8787, while the API documentation is served separately on 8686, and the documentation section states that API documentation is always available after installation at that address, alongside a copy of the documentation built into the system itself. The system documentation lives at manual.tracardi.com, and the README notes that other installation methods are described in detail in the documentation's installation section, so the container route is presented as the easy default rather than the only one.

A service, a worker and an Elasticsearch-backed store

The repository layout shows the shape of the system, and it is distributed rather than monolithic. Alongside the main tracardi/ package there are separate Dockerfiles for the worker and for migration, and shell scripts for building the worker, building a migration image, and running the elastic watermark lock. The setup.py dependency list is where the infrastructure becomes explicit: aiohttp with speedups for the async HTTP layer, redis and aioredis for caching and queueing, Elasticsearch async pinned at 7.10.1 as the primary store, and Celery at 5.2.6 for the task queue. Beyond that sit a wide set of integrations, including kombu, aiomqtt, motor for MongoDB, asyncpg for PostgreSQL, aiobotocore for AWS, the Google API client, mailchimp-transactional for email, geoip2, geopy, python_weather, influxdb-client, grpcio with protobuf, a device_detector, lark for parsing, and a custom dotty-dict package pulled from the project's own GitHub. The topic list includes elastic-search and unomi, the Apache Unomi customer data platform, which tells you the lineage.

Plugins are the extension point, and there is a beginner tutorial

The README's call for contributors singles out plugin authoring as the entry point, urging everyone willing to start coding Tracardi plugins to read a beginners' tutorial on how to code a simple plugin. The general contributing guide is pointed at for getting a development environment ready. The design reason is consistent with the API-first, composable claim: the core exposes an API and plugins extend the behaviour behind it, which is how the same codebase can serve e-commerce, gaming or any other domain. The pyproject.toml shows the tooling is modern Python, with ruff configured to select the pycodestyle and Pyflakes rule sets, a line length of 120 matching Black, and a target version of py310. There are also dev-requirements.txt, a test/ directory, and project housekeeping files such as CHANGES.md, MIGRATION.md, UPGRADE.md and RELEASE.md, which indicate a project with a release process and a migration story between versions.

Licensing and the commercial shape behind the open code

The repository is not published under a standard open source licence. The project is marked as using a custom licence that GitHub cannot classify, and the top level carries a LICENSE.md file that you need to read, alongside kasuj.json, a manifest file, and the build scripts. The topics list open-source, and the project takes donations through Open Collective, and the documentation links to a Slack community and a YouTube channel with tutorials, so the intent is a community project with commercial backing around it. The practical consequence for an adopting team is that you cannot assume the usual rights of an MIT or Apache licensed dependency, and any deployment in a product you sell needs a look at LICENSE.md first. The branch structure adds a second operational fact. The release history shows 1.0.0 and 1.1.0 both published on 2024-11-18, then 1.1.25 in March 2026, and the default branch is 1.1.x, so the version line is moving and a deployment has to pin one.

Where Tracardi is the wrong tool

There are two honest reasons to look elsewhere. The first is operational. You are committing to Elasticsearch, Redis, Celery, a worker process and a migration path between versions, all of which you have to run and upgrade yourself, and the README's own positioning is that Tracardi runs on cloud managed services and spins up resources as needed. If nobody on your team is going to own that estate, a hosted vendor is cheaper than the effort, and the README is candid that Tracardi is positioned as the inexpensive alternative rather than the managed one. The second is scope. A CDP is a mature product category with a lot of hard parts, and the parts Tracardi is strongest on are the visible ones: ingesting events, merging profiles, segmentation, and injecting real time personalisation. The parts it does not claim are the ones vendors charge for: data governance, consent management, identity resolution across devices, catalogue and experimentation tooling, and the reporting layer a marketing team expects. The alternative worth naming is the hosted category itself, Segment or RudderStack, where the difference in approach is that you get a managed pipeline and a finished identity graph rather than a configurable engine, and where the cost is per event rather than per engineer.

Editorial conclusion

Adopt Tracardi if you want to run your own customer data platform rather than pay a vendor per event, and if you can operate Elasticsearch, Redis and a queue alongside the API service. Do not adopt it if you need a hosted product with a support contract, or if you want a proven profile merge algorithm rather than something you configure yourself. Verify first that the branch you clone matches the API version you intend to run, since the install instructions point at the separate tracardi-api repository on the 1.1.x branch while this repository's own default branch is 1.1.x.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Tracardi/tracardi on GitHub