Tianji

Last reviewed Sep 13, 2026 · 763 words

Tianji replaces the pair of containers most self-hosters run, Umami for site analytics and Uptime Kuma for monitors, with one, and adds server metrics and a status page. On a small VPS where you resent every extra Postgres, that consolidation is real. The cost is that each piece is younger and shallower than the dedicated tool it stands in for, and the project only dates from 2023, so you are trading two mature codebases for one that is still filling in.

What the single container contains

Website analytics with a tracker script that records pageviews, referrers, devices and custom events, in a UI that visibly borrows from Umami's layout. Uptime monitors for HTTP, TCP, ping, DNS and a handful of service-specific checks, with notification channels. Server status from a small tianji-reporter agent you install on each host, which pushes CPU, memory, disk and network to the hub. Telemetry, a pixel-and-badge feature for counting views on things you cannot put a script on, such as a GitHub README. Status pages that combine the monitors. Application tracking for mobile apps, feed channels for aggregating webhooks, and a lightweight survey feature have been added along the way, which is where the "jack-of-all-trades" con in the catalogue comes from.

Deployment: one image, one Postgres

services:
  tianji:
    image: moonrailgun/tianji:latest
    restart: unless-stopped
    ports:
      - "12345:12345"
    environment:
      - DATABASE_URL=postgresql://tianji:change-me@postgres:5432/tianji
      - JWT_SECRET=replace-with-64-random-chars
      - ALLOW_REGISTER=false
      - ALLOW_OPENAPI=true
    depends_on:
      - postgres
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      - POSTGRES_DB=tianji
      - POSTGRES_USER=tianji
      - POSTGRES_PASSWORD=change-me
    volumes:
      - ./pgdata:/var/lib/postgresql/data

The server-status half needs the reporter on each monitored host. It is a single static binary that you run with your Tianji URL and a workspace ID copied from the dashboard, typically as a systemd service; it pushes a metrics sample every few seconds over HTTP, so hosts behind NAT report fine and nothing needs an inbound port. Uninstalling is deleting one binary and one unit file.

First login is admin / admin; change it before the proxy goes live. ALLOW_REGISTER=false closes signup, which matters because the default is open. The app listens on 12345. The 512 MB minimum is for the app alone; Postgres adds its own, and a hub with 20 monitors and 3 reporting servers sits around 700 MB total in my experience, close to what Umami plus Uptime Kuma would use separately.

Where it is weaker than the tools it replaces

Analytics: no funnels or retention, fewer filter dimensions than Umami, and a smaller set of integrations for pulling data out. Uptime: monitor types cover the common cases, but the notification catalogue is a fraction of Uptime Kuma's 90-plus providers and the status page is plainer. Server status: enough to see that a box is swapping, not a replacement for Prometheus and node exporter if you want history and alert rules on metrics. The Gatus vs Uptime Kuma piece explains what a dedicated monitor adds if that side matters to you.

The upside is that everything shares one login, one database and one notification setup, and a status page can show "site up, server healthy, traffic normal" from a single source. For a person running 3 side projects who wants one tab, that integration is the reason to pick it.

Maintenance signals

Releases are frequent, the changelog is active, and the maintainer answers issues. The project is at 3,084 stars and growing, Apache-2.0, and driven by a small team, which means features arrive fast and occasionally rough. Updates are usually painless with docker compose pull since migrations run on start, but read the release notes before major-version jumps and keep a Postgres dump from before each one. Back up the Postgres volume; that is the entire state.

What I'd do

If you have one or two personal sites and a couple of servers, and today you have nothing: run Tianji, put the reporter on each box, add both the snippet and the monitors, and enjoy a single dashboard. If you already run Umami and Uptime Kuma and they work, do not migrate; you would lose depth in both and gain a tab. If your traffic is something you report to other people, or your uptime alerts are what wake you up, use the dedicated tools from the analytics category and the monitoring one instead. Tianji is the right first tool and the wrong final one.