Talivia: admin/admin, talivia/talivia, and a placeholder secret that satisfies its own guard

Three defaults ship in the repository, and the guard only checks one of them

Start with what a fresh checkout gives you. The sign-in page at `http://localhost:3000` accepts `admin` and `admin`, and the instruction is to change it immediately under Settings and Account. The Compose file hardcodes the database credentials in plain text, with the user, the password and the database all named talivia. And the environment template ships like this:

# Required
DATABASE_URL=postgresql://talivia:talivia@localhost:5432/talivia_oss
APP_SECRET=replace-with-a-long-random-value

# Optional crypto conversion. The product remains usable without this key.
COINGECKO_API_KEY=

The Compose file requires the secret with a shell-style guard, `${APP_SECRET:?Set APP_SECRET in .env}`, which aborts only when the variable is unset or empty. Copy the template verbatim, do not edit it, and the guard passes with the literal string `replace-with-a-long-random-value`.

That value signs sessions and encrypts saved provider credentials, according to the configuration table. It is worth treating the placeholder as a deployment blocker rather than a cosmetic default. The account handling is otherwise careful: administrators can create other username and password accounts and change roles on the same page, password hashes are never shown, and every user changes their own password.

There is no migration path from Talivia Cloud, and the MCP split follows the same line

One sentence does the most damage in the whole file: the baseline migration is for an empty database only, and there is no migration path from a hosted Talivia database.

So the boundary between the product and this repository is not just about features, it is about data. A team already on the hosted service cannot lift their history into a self-hosted install by any documented route.

The feature split follows the same shape. The self-hosted edition carries core web analytics, Session Replay, website collaborators, shared analytics, import and export, and customer revenue from Stripe, LemonSqueezy, Polar, Dodo, Yolfi or a manual payment API. Google Search Console, Bing Webmaster Tools, GitHub activity and social mentions from X, Reddit and TikTok are named as Cloud additions.

The MCP story repeats it. The hosted endpoint at `https://talivia.com/mcp` connects to Talivia Cloud, and the self-hosted edition does not expose that OAuth endpoint. Locally, agents get a stdio server instead:

npx -y @talivia/agent mcp

Webhook URLs are derived from the request origin, so the proxy decides where payments land

Payment provider webhooks are how revenue gets attached to visits, and this is the one place the README warns about its own behaviour: webhook URLs are generated from the incoming request origin, and when Talivia runs behind a reverse proxy you are told to forward the original `Host` and `X-Forwarded-Proto` headers.

That is a single line of deployment advice carrying a lot of weight. Get it wrong and the provider posts its events to a URL derived from whatever origin the proxy presented. Nothing in the request fails, because the provider's request succeeds against a host that is not the one you configured. What you lose is revenue: subscription lifecycle events, refunds and disputes stop attaching to the sessions they belong to, along with the first-touch and last-touch attribution the project otherwise retains.

Six revenue inputs are supported, from Stripe and LemonSqueezy through Polar, Dodo and Yolfi to a manual payment API for anything without a connector, and revenue is connected per website under Website settings and Payments.

The manual API is also the escape hatch for the whole feature: whatever cannot be connected automatically can be posted in.

The build scripts mention ClickHouse, the docs and Compose do not

The stated local requirements are Node.js 22 LTS or 24 LTS, pnpm 10 and an empty PostgreSQL database. The Compose file defines two services, the application and `postgres:17-alpine`, and nothing else.

The package manifest tells a different story. An `update-db` script fans out to `prisma migrate deploy` and, alongside it, `update-db-clickhouse`, which runs `tsx scripts/migrate-clickhouse.ts`. There is a `build-db-schema` script that pulls the schema, and the repository root carries both a `db/` directory and a `prisma/` directory, with a `prisma.config.ts` and a separate `tsconfig.prisma.json`.

So there is a second database in the tooling that has no service, no environment variable and no documentation. Following the README you install and run against PostgreSQL and never meet it, which is fine. The day you run a script that touches it, you are working from a configuration the project does not describe.

The same block has a small redundancy: the documented setup tells you to run `pnpm exec prisma migrate deploy` yourself, and `pnpm dev` has a `predev` hook that runs a check of the environment, the database updates and the client build first.

build-app and build-app-docker are the same command with two names

The manifest defines separate build steps for the tracker and the session replay recorder, each with its own Rollup configuration at the repository root. That maps onto the two browser artefacts this product ships, and it is the right shape for them.

Then there are two application builds. `build-app` runs `next build --webpack`, and `build-app-docker` runs `next build --webpack`. The two script names exist to be referenced from different pipelines, and their bodies are identical, so the Docker build path carries a distinct name for a step that does nothing different.

The dev script makes the opposite distinction. `dev` runs Next with the turbo flag, while both build scripts pass `--webpack`, so the development server and the production build do not use the same bundler. That is a legitimate choice and it does mean a problem can appear only in the built output.

The rest of the toolchain is one file per concern: `vitest.config.ts` with `test` set to `vitest run`, `tsup.config.js`, `postcss.config.js`, `next.config.ts` and a `biome.json` for linting. There is also a `pnpm-workspace.yaml` and a `package.components.json`, with a `build-components` step that bumps a version before running tsup, so the component package is versioned on its own.

The README says pnpm 10+ and the manifest says pnpm 10 only, and below 11

The requirements line reads Node.js 22 LTS or 24 LTS, pnpm 10 and an empty PostgreSQL database. The manifest is narrower on both counts: the engine block asks for Node `^22.12.0 || >=24.0.0` and pnpm `^10.10.0 <11`.

So the documented pnpm 10 range includes a major version the manifest rejects, and the documented Node 22 includes releases below 22.12 that the manifest also rejects. Neither gap is dangerous on its own. Both mean a machine that satisfies the prose can fail the install, and the failure will look like an engine complaint rather than a documentation problem.

The container is stricter than both. It pins the pnpm version to 10.10.0 through a build argument and the Node image to 22-alpine, matching the low end of the engine range rather than the top. The build stage sets a placeholder PostgreSQL URL pointing at localhost and disables Next telemetry, so nothing in the image build reaches a real database. The runtime stage creates a system user with uid 1001, adds curl, and the Compose healthcheck polls `/api/heartbeat` every five seconds, giving up after twenty tries with a thirty second grace period.

One release, two days before the last push, and the documentation on the website

There is a single GitHub release, v1.0.0, published on 24 September 2026, and the default branch was pushed on 26 September. So the tag is two days behind the tip of the branch, which is a very short window for a project at version one.

Documentation is the other half of this. Product and integration guides are not in the repository; they are at talivia.com/docs, on the same site as the hosted product. What the repository carries in prose is two readmes, one in English and one in Simplified Chinese, plus `SECURITY.md` for vulnerability reporting and deployment guidance and `CONTRIBUTING.md` for the development workflow. The readme is otherwise unusually complete about limits, which is what makes the absence of a migration path stand out.

The agent integration lives in a separate repository entirely, `talivia-group/agent`, which is where the tooling for installing tracking, generating framework-specific setup plans and verifying live analytics events is kept.

One more positioning detail, and it is in the repository description rather than the readme: Talivia is presented as a DataFast alternative.

Editorial conclusion

Judgment: this is a serious piece of software for a specific job, joining traffic analytics to payment data in one place, and the honest scope is the open-source subset, which covers web analytics, replay, collaborators, shared analytics, import and export, plus six revenue providers. Four things to settle before you run it anywhere real. Change the bootstrap `admin` password and replace the placeholder `APP_SECRET`, because that value signs sessions and encrypts stored provider credentials, and the Compose guard checks only that the variable is non-empty. Decide what to do about webhook URL derivation, since a reverse proxy that drops the `Host` and `X-Forwarded-Proto` headers will send payment events to the wrong address and the failure will look like missing revenue rather than an error. Read the ClickHouse references in the build scripts and work out which database you are actually running, because the documentation and the Compose file only describe PostgreSQL. And if you have an existing Talivia Cloud account, there is no migration path out of it.

Frequently asked questions

Official sources

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