Liwan

Self-hosted web analytics, honestly reviewed. No marketing fluff, just what you get when you run it yourself.

TL;DR

• What it is: A privacy-first, open-source web analytics platform that ships as a single self-contained binary. No database setup required — it uses DuckDB under the hood [1][3].
• Who it’s for: Developers and self-hosters managing multiple websites who want dead-simple analytics without cookies, without Google, and without a monthly bill. Not aimed at non-technical founders [1].
• Cost: $0 for the software (Apache-2.0). You pay for a VPS — realistically $4–6/month on Hetzner or Contabo. There is no SaaS offering.
• Key strength: Genuinely minimal setup. One binary, no Postgres, no Redis, no external dependencies. Runs on a Raspberry Pi [README][1].
• Key weakness: 167 GitHub stars as of this writing. This is a young, solo-built project with almost no third-party coverage, no production track record from large deployments, and a feature set that’s useful but narrow [GitHub].
• Honest signal: The creator built this because existing tools didn’t fit their workflow across 10+ sites — and then open-sourced the result [1]. It shows: it’s opinionated and clean, not enterprise-feature-complete.

---

What is Liwan

Liwan is a lightweight web analytics platform written in Rust. You download one binary, run it, add a one-line tracking script to your website, and you get real-time dashboards showing visitors, page views, referrers, and similar standard metrics [README][3].

What makes it different from most analytics tools in this space is the deployment story. There is no Postgres to configure, no Redis sidecar, no Docker Compose file with five services. Liwan uses DuckDB — an embedded analytical database — which means the entire state lives in a single file on disk, the same way SQLite works for transactional apps [1]. That’s an unusual and deliberate architectural choice for an analytics product where query patterns are append-heavy and read-heavy.

The creator, Henry Gressmann, started building it after trying roughly ten analytics platforms over five years following their departure from Google Analytics [1]. The list of things they rejected is instructive: GoatCounter was too bare-bones and had weak multi-site support. Plausible’s open-core model was close but not lightweight enough. Fathom was a favorite until it went fully closed-source [1]. Liwan is the result of building the tool they wanted rather than compromising on one that existed.

The codebase is open-source under Apache-2.0. The dashboard is built with Astro. The backend is Rust with tokio for async I/O. As of this review, the project sits at 167 GitHub stars — a small number that honestly reflects where it is in its lifecycle: useful, functional, but not yet validated at scale by the broader self-hosting community [GitHub].

---

Why people choose it

Candid caveat first: there is almost no independent third-party coverage of Liwan. The creator’s own blog post [1] is the most detailed public write-up available. Self-Host Weekly mentioned it in passing [2]. The project’s own docs explain how to install it [3]. That’s roughly the full picture. If you’re looking for G2 reviews, Reddit threads from power users, or comparisons from dedicated analytics reviewers, they don’t exist yet for Liwan.

What does exist is a clear and consistent motivation across the creator’s writing: the privacy-compliance overhead of cookie-based analytics is painful, the SaaS alternatives keep moving to closed-source or raising prices, and single-binary deployment is undervalued in the analytics space [1].

The creator’s specific frustrations with alternatives are worth quoting because they map cleanly to the problems Liwan actually solves:

“I want to ‘own’ the data, even if the user’s data is eventually anonymized; it’s hard to trust what’s happening on a server I don’t control.” [1]

“I value a simple setup process more than the ability to hyper-scale prematurely and endlessly customize everything.” [1]

If those two sentences describe your situation, Liwan is worth evaluating. If you need team collaboration features, funnel tracking, custom events with complex property schemas, or an audit trail — Liwan isn’t there yet.

The privacy angle is not marketing language here. No cookies means no cookie banner on your site, which directly reduces GDPR compliance burden. No persistent identifiers means no fingerprinting workarounds that regulators are increasingly scrutinizing. The data never leaves your server. For a one-person operation running a blog, SaaS landing page, or portfolio sites, that’s the right tradeoff [README][1].

---

Features

Based on the README and official documentation [README][3]:

Core analytics:

• Real-time dashboard — updates as visitors arrive
• Page views, unique visitors, referrers, entry pages
• Bot and crawler filtering enabled by default
• Multi-website support (the creator manages 10+ sites on one instance [1])
• Projects and Entities model for organizing multiple sites [3]

Privacy by design:

• No cookies set on visitor browsers
• No cross-site tracking
• No persistent identifiers
• All data stored on your own server [README]

Deployment:

• Single self-contained binary — download and run, no runtime dependencies
• Docker image available via GitHub Container Registry (ghcr.io/explodingcamera/liwan:latest) [README]
• Docker Compose supported [3]
• Systemd service setup documented [3]
• Reverse proxy setup documented (for SSL termination) [3]
• Tracking script is under 1KB — negligible page weight impact [README]

Technical foundation:

• Written in Rust with tokio async runtime
• DuckDB as the embedded analytics database — no external DB process [1]
• Dashboard built with Astro

What it doesn’t have (based on available data):

• Custom events or goal tracking — not mentioned anywhere in available sources
• Funnel analysis
• User session recording or heatmaps
• Team access controls or SSO
• API for programmatic data access (not documented publicly)
• Alerting or scheduled reports
• A/B test integration

The feature set is intentionally narrow. This is not a bug — it’s the creator’s explicit philosophy that focused software is better software [1]. But it does mean Liwan is an analytics replacement, not an analytics platform.

---

Pricing: SaaS vs self-hosted math

There is no Liwan SaaS. There is no paid tier, no cloud offering, no managed hosting. It’s purely self-hosted, which means your costs are:

• Software: $0 (Apache-2.0 license)
• Hosting: whatever a small VPS costs you

Realistic hosting scenarios:

Setup	Monthly cost	Notes
Hetzner CX22 (2 vCPU, 4GB RAM)	~$4–6/mo	Handles multiple sites comfortably
Raspberry Pi 4 at home	~$0/mo running cost	Electricity + the hardware you already own
Shared with other self-hosted apps	$0 marginal	Liwan is lightweight enough to run alongside other services

The creator specifically calls out the Raspberry Pi as a valid deployment target [README], which tells you something about the resource footprint. A tool that runs on a Pi has no business being blamed for adding meaningful overhead to a VPS.

For comparison, what you’d pay for alternatives:

• Plausible: $9/mo (billed annually) for up to 10K monthly pageviews, scaling to $19/mo+ beyond that. Self-hosted version is available but requires more infrastructure.
• Fathom: $15/mo for up to 100K pageviews, closed source, SaaS only.
• Google Analytics 4: Free, but you’re the product, your data lives on Google’s servers, and GDPR compliance requires a cookie banner and a Data Processing Agreement.
• Umami: Free self-hosted, similar positioning to Liwan but requires Postgres.

If you’re running a few sites and currently paying Plausible $9–19/mo, Liwan as a self-hosted replacement saves you that amount with a once-only setup cost. If you’re on Google Analytics because it’s free, the switch to Liwan costs you a VPS (which you probably already have) and an hour of setup.

The honest math: this tool saves you $9–20/mo if you’re currently paying for privacy-friendly analytics SaaS, and costs you roughly nothing if you already self-host other things.

---

Deployment reality check

Deployment is the strongest part of Liwan’s story, and the creator is not overselling it [1][3].

The minimum path:

1. Download the binary from GitHub releases
2. Run it — it starts a web server and creates its DuckDB file in the current directory
3. Add the one-line tracking script to your site’s HTML
4. Optionally put Caddy or nginx in front for SSL

That’s it for a basic setup. No apt install postgresql, no Redis, no environment variable configuration page, no database migration scripts to run manually. The DuckDB-embedded approach eliminates an entire category of “did I configure the database right” problems that trip up non-technical users on tools like Matomo [1].

For a production setup you’ll also want:

• A reverse proxy (Caddy is documented and the simplest choice [3])
• A systemd unit file so it restarts on reboot (documented [3])
• A backup strategy for the DuckDB file (just copy the file — standard file backup applies)

What can go wrong:

The project is young. The creator mentions that feature creep happened during development and they eventually released a first major version [1] — which is honest but also means early version instability is plausible. With 167 stars and no large-deployment case studies available, you’re somewhat in early-adopter territory.

The license was listed as AGPL-3.0 in the creator’s December 2024 blog post [1] but the README and website now state Apache-2.0 [README]. A license change this early in a project’s life isn’t alarming, but it’s worth noting if you’re embedding this in a commercial product and need legal clarity — verify the current repository license before committing.

There is no mention of horizontal scaling, replication, or what happens if you have genuinely high traffic. DuckDB is not designed for concurrent writes from multiple processes. For a single-server analytics tool tracking a handful of sites, this doesn’t matter. For a hosting company trying to run one Liwan instance for thousands of customers simultaneously, it’s a real architectural limit.

Realistic time estimates:

• Technical user on an existing VPS: 15–30 minutes to a working instance
• Non-technical person following the documentation from scratch: 1–2 hours including domain and SSL setup
• Someone who has never administered a Linux server: this tool is probably not the right choice, or you’ll need assistance

---

Pros and cons

Pros

• Truly single-binary deployment. No Docker required if you don’t want it. No database server to manage. Download, run, done [README][1]. This is genuinely rare in the analytics category.
• Zero-cookie, zero-fingerprint analytics. Eliminates the cookie consent banner requirement for EU visitors. Data stays on your server [README].
• Rust performance on minimal hardware. Runs on a Raspberry Pi without apparent performance concerns [README]. The resource ceiling is low, which means you can add it to an already-busy VPS without worry.
• DuckDB is a smart choice for this use case. Append-heavy, read-heavy analytical queries are exactly what DuckDB is optimized for. The embedded model removes an entire infrastructure dependency [1].
• Apache-2.0 license. Genuinely permissive. No “Fair-code” ambiguity, no commercial redistribution restrictions [README].
• Multi-site support. The creator’s own use case is 10+ sites on one instance [1] — this was a design priority, not an afterthought.
• Bot filtering by default. Crawler traffic filtered automatically [README].
• Sub-1KB tracking script. Core Web Vitals impact is negligible [README].

Cons

• 167 GitHub stars. This is a signal worth taking seriously. The project has not been validated by a large community. There are no public case studies, no high-traffic deployment reports, no independent benchmarks [GitHub].
• Almost no third-party reviews. We found one detailed write-up (from the creator themselves), one newsletter mention, and the official docs. If you need community validation before adopting a tool, that validation doesn’t exist yet for Liwan.
• Feature set is genuinely minimal. No custom events, no goals, no funnels, no session data, no heatmaps [based on all available sources]. If your analytics workflow involves anything beyond “how many people visited which pages and from where,” you’ll hit a wall.
• Solo project. The creator built this for their own use and open-sourced it. There’s no company backing it, no funding, no disclosed roadmap. If the creator loses interest, development slows or stops. This is normal for single-developer open source, but it’s a different risk profile than Umami (which has a company) or Plausible (which has a business model) [1].
• License history is slightly unclear. Creator’s blog cited AGPL-3.0 in December 2024; current README says Apache-2.0 [1][README]. Minor, but verify if license matters to your use case.
• No API documented. Exporting or querying data programmatically isn’t covered in available documentation. If you want to pipe Liwan data into a BI tool or custom dashboard, you’d be working with the DuckDB file directly.
• No team features. Single-user or technical-user tool. No roles, no shared access controls, no SAML [based on all available sources].

---

Who should use this / who shouldn’t

Use Liwan if:

• You’re a developer or technical self-hoster who wants the simplest possible privacy-compliant analytics setup.
• You’re managing multiple websites on one server and want them all tracked in one lightweight instance.
• You’re currently paying for Plausible, Fathom, or similar privacy-focused SaaS and want to eliminate that monthly cost.
• You’re comfortable on a Linux command line and the idea of “one binary” is exciting rather than alarming.
• You value early-adopter simplicity over feature completeness and don’t mind occasional rough edges.

Skip it if:

• You need custom events, conversion goals, or funnel tracking — the basics aren’t there yet.
• You want community validation and case studies before adopting. There aren’t enough yet to provide confidence.
• You’re a non-technical founder who doesn’t manage your own server — the deployment is simple, but it still requires a server.
• You’re running a high-traffic site with concurrent write spikes — DuckDB’s embedded single-writer model hasn’t been stress-tested publicly at scale.
• Your team needs shared access with role-based permissions.

Consider alternatives instead if:

• You want a solo-developer tool but with an active community: GoatCounter or Umami are further along.
• You want privacy-first analytics without self-hosting at all: Plausible cloud or Fathom.
• You need full-featured analytics including session replays and funnels: PostHog (open-source, but heavy).

---

Alternatives worth considering

• Umami — The most direct competitor. Similar privacy-first positioning, also self-hostable, more GitHub stars (24K+), requires Postgres. More feature-complete, more complex to deploy. Good choice if you want more community backing.
• GoatCounter — What the creator evaluated and rejected [1]. Extremely lightweight, embedded database, good privacy. Weaker multi-site support and UI than Liwan. Actively maintained single-developer project.
• Plausible Analytics — The polished privacy-friendly option. Beautiful UI, good event tracking, strong community. Self-hostable (requires Postgres + Clickhouse), or SaaS at $9–19/mo. If you want the cleanest non-Google experience without fighting infrastructure, Plausible is the answer.
• Matomo — The “enterprise self-hosted” option. Feature-complete but heavy (requires MySQL/Postgres + PHP). Good if you’re migrating from GA and need feature parity.
• PostHog — Open-source, full product analytics platform with session recordings, feature flags, A/B tests. Dramatically more powerful than Liwan, dramatically more complex to run. Wrong tool if you just want pageview analytics.
• Fathom — Privacy-focused, excellent UI, but closed-source SaaS only. No self-hosting option.
• Pirsch — Privacy-first SaaS, cookieless, no self-host option. Starts at $5/mo.

For a developer running personal or small business sites who wants maximum simplicity: the realistic shortlist is Liwan vs GoatCounter vs Umami. GoatCounter if you want the most battle-tested minimal option. Umami if you want more features and a larger community. Liwan if the single-binary, no-external-database approach is specifically what appeals to you.

---

Bottom line

Liwan is exactly what it says it is: a simple, privacy-first, single-binary analytics tool built by a developer who couldn’t find what they wanted and built it themselves. The technical decisions — Rust, DuckDB, no external dependencies — are genuinely good choices for the use case. The privacy model is honest and comprehensive. The deployment story is the cleanest in its class.

The honest limit is the project’s current maturity. 167 GitHub stars, one developer, almost no third-party coverage, and a feature set that’s intentionally minimal means you’re adopting early-stage software. That’s fine if you’re a developer who can tolerate rough edges and wants something simple that respects your users’ privacy. It’s not the right call if you need production guarantees, a feature roadmap, or community support at 2am when something breaks.

For the specific audience of technical self-hosters who want to eliminate the Plausible or Fathom monthly bill and don’t need custom events or funnel analysis — Liwan deserves a genuine look. For everyone else, Umami or Plausible self-hosted are the more proven paths.

---

Sources

1. Henry Gressmann — “Lightweight Web Analytics with Liwan” (Dec 18, 2024). https://blog.henrygressmann.de/2024/liwan/
2. Self-Host Weekly — Issue May 16, 2025 (brief mention). https://selfh.st/weekly/2025-05-16/
3. Liwan Official Docs — Getting Started. https://liwan.dev/getting-started/

Primary sources:

• GitHub repository and README: https://github.com/explodingcamera/liwan (167 stars, Apache-2.0 license)
• Official website: https://liwan.dev
• Live demo: https://demo.liwan.dev/p/liwan.dev