mixdive/mixdive repository overview

⁠Mixdive

Self-hosted product analytics. Your apps send events. Mixdive counts them and gives every event its own report screen, on your servers, with nothing defined up front.

mixdive.com⁠ · Documentation⁠ · Free to run yourself

The console, running on your own server. Watch it in motion on mixdive.com⁠.

⁠Insight or ownership? You shouldn't have to choose

That is the trade most analytics tools ask you to make. Send your users' behaviour to somebody else's servers, or fly blind. Mixdive is the third option: the same reports, running on a machine you control.

Your users' data never leaves your infrastructure. There is no vendor holding a copy of who your users are and what they did. Mixdive itself makes two small calls: a version check that sends nothing about your installation, and basic usage data (the project name, the version, which modules are on and which console screens get opened). An admin can switch either one off. Teams in regulated industries, and anyone whose data simply cannot go to a third party, tend to arrive here for exactly this reason.

Nothing to configure before you get value. Send an event and its report screen exists. Properties register themselves the first time they appear, so a new field becomes a breakdown you can look at instead of a ticket for somebody. No schema, no event definitions, no dashboard to assemble first.

One container and a MongoDB. That is the entire architecture. No Kafka, no ClickHouse, no warehouse to feed, nothing to keep in sync. The queue is a Mongo collection, which is why a small VM handles more than you would expect.

You don't need a data team. The screens answer the questions a product person actually asks. Which features get used, by whom, how often, and what people did before they stopped.

Free to run yourself, for good. No licence key, no seat count, no end date. If you would rather not look after a server, Mixdive Cloud runs one for you⁠.

⁠Try it in a minute

Docker, and nothing else:

curl -O https://docs.mixdive.com/compose.yaml
docker compose up -d

That brings up Mixdive, a MongoDB with a persistent volume, and Caddy in front of both. Open http://localhost:8080, or your server's address, and a one-time wizard asks for a project name, the address your apps will use, and an owner account. Then you are looking at the console.

Already running a MongoDB? Skip Compose:

docker run -d --name mixdive -p 8080:8080 \
  -e MONGODB_URI="mongodb://..." \
  mixdive/mixdive:latest

⁠What you get

Four modules over a core you cannot switch off. Each one is on or off in Settings, so an installation that only wants web traffic never grows a users table.

Ingestion answers straight away, because the request path writes to a queue and stops there. A worker then applies events oldest first and counts each one exactly once, so a retry or a double delivery never inflates a number.

⁠What it looks like

A report for every event. Totals, average per day, unique users, and a breakdown by any property the event carries. Nobody assembles it first.

Website traffic too. One line on your site, and visitors, sessions and pages start counting themselves.

The people behind the numbers. Every count goes back to somebody: what they did, and when they were last around.

Your own things, counted. A product, an order, a support ticket, each with its own screen and its own counters, merged from whatever your apps send.

More screens, including the received log and the storage panel, are on mixdive.com⁠.

⁠HTTPS with nothing to edit

Give the setup wizard an https:// address, point that name's DNS record at the machine, and leave ports 80 and 443 open. The bundled proxy gets the certificate the first time somebody opens the address and renews it on its own. It asks Mixdive first, and Mixdive only ever approves the one name you configured. How it works⁠.

⁠Configuration

Two variables, and that is the list. The project name, the server URL, how long raw events are kept, how often the worker runs and which modules are on all live in the database, with a screen each under Settings.

⁠Tags and upgrades

latest moves to whatever was released last. Version tags such as 0.2.1 stay put, so pin one when you want to choose your own upgrade moment. Every tag is built for linux/amd64 and linux/arm64. Upgrading is docker compose pull && docker compose up -d, with collections and indexes ensured at startup and nothing to migrate by hand.

Which version an installation runs is never a guess: Settings → Storage shows the version and the commit it was built from, and so does GET /health. The same card says when a newer version is out.

⁠Sending data

A web tag⁠ you paste once, React⁠, Next.js⁠, SDKs for Node.js⁠ and Go⁠, a Google Tag Manager template⁠, and an HTTP API⁠ that needs no SDK at all.

More SDKs are coming. If the one you need is missing, write to [email protected]⁠ and it moves up the list.

⁠Where to go next

• mixdive.com⁠ is where the product is written up in the open: what it does, what it leaves out on purpose, where it is going, and a devlog you can follow.
• docs.mixdive.com⁠ has the guides, the concepts and the ingest contract.
• Running a real product with real users and data that cannot go to a third party? A few lines to [email protected]⁠ is enough. You get a reply from a person, and what you run into shapes what gets built next.

Mixdive is a commercial product and not open source. It is version 0.2.1, which is honest about where it is: the ingestion and reporting core is stable, and screens still move between releases.