You outgrew “how many people opened the app today.” Marketing wants push. Support wants crash stacks with symbols. Legal wants consent logs and export requests in one place. Firebase bundles all of that — and ships the telemetry to Google’s cloud unless you read every SDK toggle twice.
Countly (Countly/countly-server) is the other end of the spectrum from lightweight app analytics: a full product analytics and engagement platform you can run on your own Linux box or private cloud. Sessions, funnels, crashes, push, remote config, in-app ratings, compliance tooling — plugin architecture on top of MongoDB and Node.js. The open-source edition is Countly Lite (self-host, non-commercial license); bigger orgs often move to Enterprise for SLA and advanced modules, but the same SDKs talk to your server either way.
What it actually does
Countly collects behavior from mobile, web, desktop, and IoT-style clients via official SDKs (iOS, Android, Flutter, React Native, Unity, JavaScript, Node, and more) or the write API for anything custom. The dashboard is not a single chart — it is a modular control room:
- Analytics core — sessions, views, events, segmentation, custom dashboards, email reports.
- Quality — crash and error reporting with platform-native SDK hooks.
- Engagement — push notifications, remote configuration, in-app rating prompts.
- Governance — Compliance Hub for consent and data-subject workflows; Data Manager to tame event schemas.
- Integration — read/write APIs, webhooks, hooks to forward data elsewhere if you need a hybrid pipeline.
Large brands have run Countly for years (automotive, banking, telco — often because they need on-prem or regional hosting, not because they lack budget for SaaS). The GitHub repo is the server side; ~5.9k stars reflects a mature codebase, not a weekend side project.
If you only need privacy-friendly event counts for a indie mobile app, we have written about Aptabase — much smaller footprint. Countly is for teams that want Firebase-class breadth without renting Google’s analytics plane.
Why self-host Countly?
Data stays yours. Self-hosted Countly keeps raw events and profiles on infrastructure you administer. For Canadian operators, that means you can point auditors at a VPS in Canada instead of a US vendor’s subprocessors list.
Regulated and high-trust products. Financial, health-adjacent, and enterprise apps often cannot use US-only SaaS analytics as the system of record. Countly’s pitch — privacy-first, deploy where you choose — matches that buyer, not the hobby blogger tracking page views.
One stack instead of five tools. Crashes in Sentry, pushes in OneSignal, analytics in something else adds cost and GDPR surface area. Countly tries to collapse product telemetry and engagement into one self-hosted install (accepting the ops tradeoff).
License clarity. Server code is AGPL-3.0 (with Countly’s modified Section 7 — read their LICENSE). Countly Lite is explicitly non-commercial OSS; running it as a paid multi-tenant analytics service to strangers is not the intent. Internal company use and learning fit Lite; commercial resale usually means talking to Countly about Enterprise.
What running it takes
Countly is heavier than a single-container analytics toy. Expect MongoDB, Node services, and a proper Linux host. Official paths:
- One-liner on fresh Ubuntu/CentOS:
wget -qO- https://c.ly/install | bash(expects ports 80/443 free). - Release tarball plus
bin/countly.install.shfrom GitHub releases. - Docker image
countly/countly-server— common for teams already standardized on Compose.
Plan disk for Mongo growth, backups before upgrades, and TLS in front of the dashboard. High event volume wants RAM and sharding conversations early; Lite on a small VPS is fine for staging or modest production apps, not “billions of events” without architecture work.
SDK setup is well documented on Countly’s support site; point clients at your server URL and lock down the admin UI with strong passwords and network ACLs — you are holding end-user behavior data.
Who it's for (and who should skip it)
Good fit: product teams shipping mobile + web with crashes and campaigns in scope, agencies building apps for clients who demand on-prem analytics, orgs replacing or complementing Firebase/Mixpanel with owned infrastructure.
Maybe skip it: marketing-site-only analytics (look at Plausible or our Plausible post). Solo devs who just want “did anyone use v2?” without Mongo — Aptabase or Umami-class tools win on simplicity.
Hosting it in Canada
We run Countly-style stacks on Canadian Docker hosting when clients need engagement plus analytics in-country: Mongo backups, SMTP for alerts, reverse proxy hardening, and firewall rules so the ingest endpoints are not wider open than they need to be.
Tell us your MAU and event rate if you are weighing Lite on one VPS versus Enterprise — sizing Mongo and upgrade paths is usually the conversation before SDK work.
