Talivia self-hosted: web analytics, session replay and revenue attribution in one MIT-licensed stack

What Talivia's open-source edition actually covers

Talivia is a Next.js and TypeScript application for founders who want product analytics and revenue numbers in the same place. The repository describes it as "the focused open-source edition" of the hosted Talivia platform, and the package.json describes it as "Self-hosted product analytics and revenue attribution." The self-hosted edition bundles core web analytics, Session Replay, website collaborators, shared analytics, import/export, and customer revenue pulled from Stripe, LemonSqueezy, Polar, Dodo, Yolfi or a Manual Payment API.

The revenue side is the differentiator. The README states that subscription lifecycle, refunds, disputes, and first-/last-touch attribution are retained, so the dashboard is meant to answer which visit produced which payment, not just how many people arrived. That is a narrower and more opinionated target than a general-purpose web analytics tool.

The scope boundary matters as much as the feature list. Google Search Console, Bing Webmaster Tools, GitHub activity, and social mentions from X, Reddit and TikTok are explicitly listed as Talivia Cloud features. If search-console data is the reason you are evaluating analytics tools, this repository is not the product you want.

How tracking, replay and payments fit together

The build scripts reveal the architecture. `build-tracker` and `build-recorder` run Rollup against `rollup.tracker.config.js` and `rollup.recorder.config.js`, producing two separate browser bundles: a lightweight tracker for pageviews and events, and a recorder for Session Replay. They are built independently of the Next.js app, so the snippet a customer pastes is not the whole application bundle.

The server side is Next.js (`next dev --turbo` in development, `next build --webpack` for production) with Prisma as the data layer. The `update-db` script chains `prisma migrate deploy` and a ClickHouse migration script, and `build-db` runs `prisma generate`. The Compose file, however, defines only two services, `app` and `postgres:17-alpine`, and passes a single `DATABASE_URL` into the container. So the shipped deployment path is PostgreSQL only, and the ClickHouse script is visible in package.json without a corresponding service in docker-compose.yml. Treat that as an unresolved question rather than a feature you can assume.

Payment data enters through provider webhooks. The README states that webhook URLs are generated from the incoming request origin, which is why it warns that a reverse proxy must forward the original `Host` and `X-Forwarded-Proto` headers. Get that wrong and the generated URLs point at the wrong host.

Installing Talivia with Docker Compose

The README gives two install paths. The Docker one is the shorter. You need Docker Engine with Docker Compose, and the first step is to create an environment file and generate a secret:

cp .env.example .env
openssl rand -hex 32

The generated value goes into `APP_SECRET`. The example file also defines `DATABASE_URL`, which the Compose file overrides with `postgresql://talivia:talivia@postgres:5432/talivia_oss`, and an optional `COINGECKO_API_KEY` for crypto exchange-rate conversion. Then start the stack:

docker compose up --build -d
docker compose ps

The README says the container applies the OSS database migration automatically before starting the application, and that the app listens on `http://localhost:3000`. The Compose healthcheck polls `http://localhost:3000/api/heartbeat` every 5 seconds with a 30 second start period, so `docker compose ps` should show the app becoming healthy rather than restarting.

Sign in with the bootstrap credentials `admin` / `admin`, then change that password under Settings, Account. The README is direct about this: change it immediately. For a local source checkout instead of Docker, the requirements are Node.js 22 LTS or 24 LTS, pnpm 10 or later, and an empty PostgreSQL database, with `pnpm install --frozen-lockfile`, `pnpm exec prisma migrate deploy`, and `pnpm dev` as the sequence.

First real use: a website, a snippet, one payment provider

The README lays out five setup steps in order. Create a website in Talivia, copy its tracking snippet into your site, confirm that a visit appears on the dashboard, optionally enable Session Replay in website settings, and connect customer revenue under Website settings, Payments.

The order is not arbitrary. Confirming a visit before touching payments isolates the tracker from the webhook path, so a failure tells you which half is broken. Session Replay is opt-in per website rather than on by default, which is the right default for a tool that records visitor sessions.

When you connect a provider, check the generated webhook URL against your public hostname. Because the URL is derived from the incoming request origin, a proxy that drops `Host` or `X-Forwarded-Proto` produces a URL that the provider cannot call back. That is the single most likely first-day failure in this project, and it is a configuration problem, not a bug.

The baseline migration is for an empty database only. The README states plainly that there is no migration path from a hosted Talivia database, so exporting from Talivia Cloud into this edition is not a supported route.

Backups, migrations and the upgrade cost you are signing up for

The README treats backups and upgrades as one topic, which is honest. Before upgrading, back up the PostgreSQL database and any deployment-specific storage. For a Compose install it gives a concrete command:

docker compose exec -T postgres pg_dump -U talivia -d talivia_oss > talivia-backup.sql

Future releases add ordered migrations under `prisma/migrations`, applied with `pnpm exec prisma migrate deploy`; the official container does this at startup. The README adds a warning that matters: never edit a migration that has already been applied to a persistent database.

Two operational facts follow. First, because the container migrates on boot, a bad upgrade can alter schema before you have a chance to intervene, so the dump is not optional. Second, the repository publishes no release entries, so there is no changelog to read before pulling a new image. You are upgrading against the migration files themselves.

Maintenance signals are mixed. The last push to the default branch was on 2026-09-16 and the repository is not archived, so the code is current. But there is no release history to inspect, and the ClickHouse script in package.json has no matching Compose service, which suggests the deployment story is still settling.

Where Talivia is the wrong tool

The clearest limitation is the hosted-versus-open-source split. Search Console, Bing Webmaster Tools, GitHub activity and social mentions are Cloud-only, so an SEO-driven team will find the self-hosted edition missing the integrations it came for. The README does not document a rollback procedure for a failed upgrade, and it does not document a migration path in either direction between hosted and self-hosted databases.

Infrastructure is a second constraint. You need PostgreSQL and either Docker Compose or a Node.js 22/24 runtime with pnpm 10. Teams that want a script tag and nothing else will spend more time on operations than the analytics are worth.

Session Replay is also a data-protection decision before it is a feature. The tool records visitor sessions, and the README only says it is enabled optionally in website settings; it does not describe masking or retention controls. If your visitors are in a jurisdiction where session recording needs explicit consent, that gap is on you to resolve before enabling it.

Finally, the bootstrap `admin` / `admin` credentials are a known, published default. An instance reachable from the internet before that password is changed is an open door, and the README's instruction to change it immediately is the whole mitigation.

How Talivia differs from Plausible, Umami and PostHog

Plausible and Umami are the natural comparisons for the web analytics half, and both are lighter to run: they are cookie-free pageview counters without a payments layer. Talivia's tracker exists to feed attribution, not to be the smallest possible script, and its data model has to carry customer and subscription records alongside events. If you only want pageviews, the extra Prisma schema and payment webhooks are overhead.

PostHog is the closer comparison on breadth, since it also pairs product analytics with session replay. The difference is where the revenue logic lives. Talivia's README describes first-/last-touch attribution and subscription lifecycle, refunds and disputes as retained data, with providers connected under Website settings, Payments. That is a payments-first framing rather than a general product-analytics one.

The project also names itself a "datafast alternative" in its repository metadata, which places it in the same conversation as revenue-focused analytics tools rather than general web analytics. The practical test is simple: if your question is "which campaign produced this Stripe payment," Talivia is built for it. If your question is "which feature do users adopt after signup," a general product analytics tool will fit better.

Licence, agents and what to check before you commit

Talivia is MIT licensed, and the LICENSE file sits at the repository root alongside SECURITY.md and CONTRIBUTING.md. MIT is permissive, so the usual obligations are attribution and including the licence text; the README does not describe any separate commercial terms for the self-hosted edition. That is a description of the licence file, not legal advice, and the Cloud product is governed by its own terms.

There is also an Agent Kit at talivia-group/agent for Codex, Claude Code, ChatGPT and other MCP clients. Note the split carefully: the hosted MCP server at `https://talivia.com/mcp` connects to Talivia Cloud over OAuth, and the README states that this self-hosted edition does not expose the Talivia Cloud OAuth endpoint. You can still run the kit locally:

npx -y @talivia/agent mcp

That runs over stdio against your own instance. Before you commit to this stack, verify three things: that `APP_SECRET` is at least 32 bytes and stored outside version control, that your reverse proxy forwards `Host` and `X-Forwarded-Proto`, and that one provider's webhook round-trips a real payment into the dashboard.

Editorial conclusion

Adopt the self-hosted edition if you want web analytics, Session Replay and payment-provider revenue attribution inside your own PostgreSQL database and can accept that the baseline migration only targets an empty database. Do not adopt it if you need Google Search Console, Bing Webmaster Tools, GitHub activity or social mentions, which the README places in Talivia Cloud, or if you are trying to migrate an existing hosted Talivia database. Before trusting it with production traffic, verify the two required variables (DATABASE_URL and APP_SECRET), confirm that a visit reaches the dashboard after you paste the tracking snippet, and test one payment provider's webhook end to end behind your reverse proxy.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. talivia-group/talivia on GitHub