Tianji

Website analytics, uptime monitoring, and server status in a single Docker container. No cookies, no SaaS bill, no juggling dashboards.

TL;DR

• What it is: Open-source (Apache-2.0) all-in-one observability platform combining website analytics, uptime monitoring, and server status reporting into a single self-hosted application [README][1].
• Who it’s for: Independent developers, small teams, and non-technical founders who are currently running Umami and Uptime Kuma and something else for server health — and are tired of switching between three dashboards [2].
• Cost savings: Google Analytics, Uptime Robot (paid), and a basic server monitoring SaaS can easily run $30–$80/mo combined. Tianji self-hosted runs on a $5–10/mo VPS with all three functions covered.
• Key strength: The consolidation pitch is real and honest. One install, one login, one place to see whether your traffic spiked when your server went down [2].
• Key weakness: 3,019 GitHub stars puts it well below the tools it replaces individually (Umami: 20K+, Uptime Kuma: 60K+). Cloud hosting isn’t available yet — just a waitlist. Each individual module is less mature than a dedicated specialist tool [README][1].

---

What is Tianji

Tianji is a self-hosted web application that combines website analytics, uptime monitoring, and server status into one platform. The project description on GitHub is unusually direct: “Insight into everything, Website Analytics + Uptime Monitor + Server Status. not only another GA alternative” [README].

The motivation is spelled out clearly in the README: when you’re running a website, you typically need three categories of tooling — something like Google Analytics or Umami for traffic, something like Uptime Kuma for availability, and something like Prometheus or Netdata for server health. For a solo founder or small team, the overhead of installing, configuring, and maintaining three separate stacks is real. Tianji’s bet is that most users don’t need the depth of a dedicated specialist tool — they need good enough coverage across all three categories without the operational weight [README][1].

Beyond the core three, the project has expanded to include Docker container status monitoring, public status pages, lightweight telemetry (for open-source projects tracking how many people deployed their software), surveys, a waitlist feature, UTM tracking, Lighthouse performance reports, and webhook-based hooks [README][2]. The homepage lists these as distinct modules under a single install. It’s a broader scope than the name suggests.

The project is built by a solo author (msgbyte on GitHub), is Apache-2.0 licensed, and has received contributions from the community. At 3,019 GitHub stars it’s not a large project by self-hosted standards, but it’s under active development with a visible roadmap [README].

---

Why people choose it

The clearest user story comes from the guisso.dev blog [4], written by a developer who self-hosted Tianji and ran it as their analytics stack: the appeal was getting PV/UV tracking without cookies, campaign tracking via UTM, and reliability insights — all in one place. That’s the consolidation pitch working as intended.

The Tianji team’s own blog [2] frames the value in terms of context-switching costs: “Fewer context switches: From traffic to availability without hopping across tools.” The claim is that when your analytics, uptime, and server health share the same event timeline, you can correlate a traffic drop with a server restart instead of manually cross-referencing timestamps across three separate UIs. For small teams, this is a genuine quality-of-life improvement.

The privacy angle is consistently emphasized across all sources [1][2]. Tianji collects analytics without cookies, uses IP truncation by default, and stores aggregated data rather than individual user sessions. This matters for GDPR and CCPA compliance — you don’t need a cookie consent banner for data you’re not collecting. The DB Tech Reviews install guide [1] specifically calls this out as a “significant advantage” for site owners who want analytics without the legal overhead.

The all-in-one consolidation pitch is where Tianji wins. Where it’s harder to justify choosing Tianji over specialist alternatives is on depth within any individual module. If you specifically need the full feature set of Plausible’s analytics, or Uptime Robot’s global monitoring network, or Grafana’s server dashboards, you won’t get that depth from Tianji’s implementations of those same ideas.

---

Features

Based on the README roadmap, official website, and third-party write-ups:

Website analytics:

• Pageviews, sessions, referrers, UTM cohort tracking [README][2]
• No cookie tracking — GDPR/CCPA compliant by default [1][2]
• IP truncation and geo mapping at ingestion [2]
• Configurable retention policies [2]
• Conversion funnel tracking and drop-off analysis [2]
• Content and SEO-relevant traffic insights [2]

Uptime monitoring:

• Active and passive monitor modes [README]
• Built-in public status pages [README][website]
• Notification routing via webhook, Slack, Telegram, and email [1][2]
• Reachability, latency, and error rate tracking [2]

Server status:

• CPU, memory, disk, and network reporting via a lightweight reporter agent [README][1]
• The reporter binary is downloadable directly from your Tianji instance [README]
• Threshold-based alerting [2]

Docker container status:

• Monitor Docker container health from within Tianji [website]

Additional modules:

• Telemetry system — lets open-source project authors track how many people deployed their software without collecting personal data [README]
• Surveys [README]
• Waitlist management [README]
• Lighthouse performance reports [README]
• UTM tracking [README]
• Hooks (webhook-based triggers) [README]
• Team collaboration support [README]
• OpenAPI — full REST API interface documented at /api [README][website]
• Helm chart for Kubernetes deployment [README]

One thing worth noting: the feature list has grown significantly from the original three-pillar pitch. Whether that breadth is a strength (more value per install) or a weakness (unfocused) depends on how much of it you actually use.

---

Pricing: SaaS vs self-hosted math

Tianji self-hosted:

• License cost: $0 (Apache-2.0) [README]
• Unlimited users, unlimited storage, self-controlled data [pricing page]
• Docker Compose deployment on a VPS you already own or rent for $5–10/mo

Tianji Cloud:

• Not available yet — the pricing page shows “Coming Soon” with a waitlist [pricing page]
• The listed cloud tier description says “Pay as you need, one click to online” but no actual pricing is shown

What you’d replace with a $5–10 VPS running Tianji:

Website analytics: Google Analytics is free but surveillance-based. Plausible Analytics starts at $9/mo. Fathom starts at $14/mo. Umami Cloud starts at $9/mo (or self-host separately).

Uptime monitoring: Uptime Robot free tier covers 50 monitors with 5-minute checks. Paid plans start at $7/mo for 1-minute checks and more monitors. Better Uptime starts at $20/mo.

Server status: Datadog starts at $15/host/month. New Relic has a free tier with limits. Grafana Cloud has a free tier. Netdata Cloud has a free tier for basic use.

If you were paying for even modest tiers across all three categories, you could easily spend $30–$60/mo. A $6 Hetzner VPS running Tianji covers all three for $6/mo. The consolidation savings are real — though you’re also accepting less depth and less reliability SLA than the dedicated paid tools.

Data on Tianji-specific savings numbers is not available beyond this framework, since there are no published case studies or user cost breakdowns in the reviewed sources.

---

Deployment reality check

The DB Tech Reviews install guide [1] walks through a Docker Compose setup in detail, which is about as close to a real-world deployment account as these sources get. The core setup is:

services:
  tianji:
    image: moonrailgun/tianji:latest
    ports:
      - "12354:12345"
    environment:
      DATABASE_URL: postgresql://tianji:tianji@postgres:5432/tianji
      JWT_SECRET: replace-me-with-a-random-string
      ALLOW_REGISTER: "false"
    depends_on:
      - postgres
  postgres:
    image: postgres:15.4-alpine

The quickstart from the official blog [2] is even simpler: two commands — wget the compose file, docker compose up -d. Default credentials are admin/admin, which you change immediately.

What you actually need:

• A Linux VPS with ~2GB RAM minimum
• Docker and docker-compose
• A domain name and reverse proxy (nginx or Caddy) for HTTPS
• PostgreSQL — bundled in the default compose file

What can go wrong:

The DB Tech Reviews guide [1] notes the setup has some gotchas that burned early users: the Docker Compose file in circulation at the time included unnecessary build commands that caused failures when running from the published image. If you’re following an older guide, compare it against the current compose file from the repository.

The default port (12345 internally, mapped to whatever you choose) isn’t 80 or 443 — you need a reverse proxy configured if you want HTTPS, which you do [1].

The reporter agent for server status monitoring needs to be installed separately on each server you want to monitor — it’s not a passive agent, it’s a binary you download from your Tianji instance and run as a service [README]. This is a separate setup step beyond the main install.

Realistic time estimate: For a developer comfortable with Docker and a VPS: 20–45 minutes to a working instance. For a non-technical founder following a guide step by step: 2–4 hours including domain setup and HTTPS configuration. Installing the server reporter on a second machine adds another 15–30 minutes.

---

Pros and cons

Pros

• Real consolidation value. If you’re running three separate monitoring tools today, replacing them with one Docker Compose file and one login is a genuine operational improvement [README][1][2].
• No cookie tracking, GDPR/CCPA compliant by default. IP anonymization and cookie-less collection baked in — no consent banner required [1][2].
• Apache-2.0 license. Permissive, no commercial restriction, no fair-code fine print [README].
• Active development with a visible roadmap. The README roadmap shows checked items across all modules, and the project shipped Lighthouse reports, surveys, waitlists, and Docker status monitoring beyond the original scope [README].
• OpenAPI. Full REST API documented and exposed — you can integrate Tianji data into your own tooling [README][website].
• Helm support. If you run Kubernetes, there’s a chart [README].
• One-click deployment options. Buttons for Hostinger, Sealos, RepoCloud, Render, and ClawCloud are in the README for users who want managed hosting now rather than waiting for the official cloud [README].
• Lightweight setup. Docker Compose, PostgreSQL, done. No Kafka, no distributed components, no minimum cluster size [1][2].

Cons

• Smaller project than the tools it replaces. 3,019 stars vs. Umami’s 20K+ and Uptime Kuma’s 60K+. Fewer battle-tested deployments, less community-contributed documentation [README].
• No cloud hosting yet. The pricing page shows cloud hosting as “Coming Soon” with a waitlist — if you need managed hosting right now, you’re on your own or using an unofficial one-click option [pricing page].
• Each module is less mature than specialist alternatives. The analytics won’t match Plausible’s funnel depth. The uptime monitoring won’t match Uptime Robot’s global probe network. The server metrics won’t match Grafana/Prometheus. If you need depth in any one area, a dedicated tool is a better fit [1][2].
• Solo maintainer risk. The project is primarily maintained by one person (msgbyte). This isn’t a red flag — plenty of excellent self-hosted tools run this way — but it’s a different longevity bet than a tool backed by a company or large contributor base.
• Reporter agent must be manually installed per server. There’s no auto-discovery or agent manager — you download and configure the binary on each server you want to monitor [README].
• No documented SSO or LDAP. Team collaboration is supported but user management details are sparse in the available documentation.

---

Who should use this / who shouldn’t

Use Tianji if:

• You’re currently running Umami (or another analytics tool) plus Uptime Kuma plus some server monitoring separately, and the operational overhead of three separate tools is bothering you.
• Privacy-first analytics without cookie banners is a priority for your site.
• You want lightweight observability with a single install and single dashboard.
• You’re an indie developer or small team without a dedicated DevOps person — the setup is simple and the footprint is small.
• You want an Apache-2.0 licensed tool you can embed in a client’s stack without license complications.

Skip it (use specialist tools) if:

• Your primary need is deep product analytics with cohort analysis, A/B testing, or revenue attribution — use Plausible or Mixpanel.
• You need uptime monitoring with global probe nodes across multiple continents and sub-minute check intervals — use Uptime Robot paid tier or BetterStack.
• You run infrastructure at a scale where you need alerting rule complexity, metric cardinality, and dashboards that Prometheus + Grafana provides.
• You need SSO or enterprise team governance — the current feature set doesn’t address this.

Stay on Google Analytics if:

• You’re not concerned about GDPR/cookie consent compliance and you want the depth of GA4’s reporting without self-hosting anything.

---

Alternatives worth considering

• Umami — analytics specialist, MIT license, larger community, Umami Cloud available. Better analytics depth, no uptime or server monitoring. Use if analytics is your primary need.
• Uptime Kuma — uptime monitoring specialist, MIT license, ~60K stars, very mature. Better monitoring depth. Use if uptime monitoring is your primary need.
• Plausible Analytics — privacy-first analytics SaaS with self-host option, AGPL-3.0. More polished analytics UI, larger team behind it, paid cloud starts at $9/mo.
• Netdata — server monitoring specialist with a generous free cloud tier. More granular metrics, larger community. No website analytics or uptime monitoring.
• Grafana + Prometheus stack — the power-user monitoring setup. Far more capable for server metrics, significantly more complex to configure and maintain.
• GoatCounter — analytics only, ultra-lightweight, MIT, no cookie tracking. Single-purpose but extremely lean.

For a non-technical founder who wants to stop running three tools: the realistic choice is Tianji (all-in-one, simpler) vs. running Umami + Uptime Kuma separately (more mature, more stars, more community help). Both paths are free to self-host. Tianji wins on operational simplicity. The individual tools win on depth and community.

---

Bottom line

Tianji’s pitch is honest and the problem it solves is real. If you’re managing multiple monitoring tools because there was no lightweight way to consolidate them, Tianji is a reasonable answer. The no-cookie analytics, GDPR compliance by default, and single-install footprint are genuine strengths. The trade-off is equally honest: you’re betting on a smaller project with a sole primary maintainer, each module has less depth than a dedicated specialist tool, and the cloud hosting product isn’t live yet. For an indie developer or small team that needs good enough across website analytics, uptime, and server health without the overhead of three separate stacks, Tianji earns its place on a $6 VPS. For anyone who needs serious depth in any one of those three areas, the specialist tools are still the answer.

If the setup is the blocker, that’s exactly what unsubbed.co’s parent studio upready.dev deploys for clients — one-time fee, you own the infrastructure.

---

Sources

1. DB Tech Reviews — “Unleashing the Power of Tianji: Your Comprehensive Guide to Docker Analytics and Monitoring” (January 8, 2025). https://dbtechreviews.com/2025/01/08/unleashing-the-power-of-tianji-your-comprehensive-guide-to-docker-analytics-and-monitoring/
2. Tianji Official Blog — “2 posts tagged with ‘Self-host’” — privacy-first analytics and all-in-one observability guides. https://tianji.dev/blog/tags/self-host
3. guisso.dev — “Open source site analytics” — personal account of self-hosting Tianji (December 6, 2025). https://guisso.dev/en/blog/
4. selfh.st — “This Week in Self-Hosted (27 September 2024)” — community self-hosting news roundup. https://selfh.st/weekly/2024-09-27/

Primary sources:

• GitHub repository and README: https://github.com/msgbyte/tianji (3,019 stars, Apache-2.0 license)
• Official website: https://tianji.dev
• Pricing page: https://tianji.dev/pricing
• OpenAPI documentation: https://tianji.dev/api