Countly Community Edition

Last reviewed Sep 13, 2026 · 808 words

Countly answers "which users who installed the app in June still open it, and where do they drop out of onboarding". It does not answer "how many people read this page", and if that second question is yours, the analytics category has four lighter tools that will serve you better. For the first question, Countly Community Edition is a 2012-vintage, AGPL-licensed, MongoDB-backed product analytics platform with the best mobile SDK coverage in open source, and its main job in 2026 is justifying itself against PostHog.

Product analytics is a different discipline from web analytics

Web analytics counts pageviews and referrers. Product analytics tracks identified users through custom events: signed up, completed tutorial step 3, made a purchase, crashed on screen X. From those events you build funnels (what fraction of users who did A went on to do B), retention cohorts (of users who started in week 1, how many were active in week 4), and per-user timelines. Countly's data model is built around this from the ground up, with user profiles, custom properties, session tracking, and crash reports tied to the same identity. Plausible and GoatCounter do not attempt any of it, and Matomo bolts a subset on.

MongoDB is the operating cost

The stack is a Node.js API server, a Node.js dashboard process, Nginx, and MongoDB. That last one is why the minimum RAM is 2 GB and why a real install wants 4 GB or more: MongoDB holds working sets in memory and event-heavy apps generate a lot of documents. Backups are mongodump on a schedule rather than copying a file, upgrades have to respect MongoDB version compatibility, and if you have never run Mongo before, this is the part of the install you will spend the most time on. The official countly/countly-server Docker image and the compose file in the repository bundle all of it, which is the right way to start; a bare-metal install on Ubuntu with the project's script is the alternative for a dedicated VM.

git clone https://github.com/Countly/countly-server.git
cd countly-server
docker compose up -d

The dashboard comes up on port 80 (443 with a certificate) and the first visit creates the admin account.

Check the feature matrix before assuming what is free

Countly has moved features between Community and Enterprise editions more than once over its history. As of this writing, custom events, sessions, user profiles, funnels, retention, crash analytics, and the core dashboards are in Community, while some attribution, A/B testing, and advanced segmentation plugins are Enterprise-only. The feature matrix on countly.com is the authority; read it for the specific plugin you need rather than trusting a forum post from three years ago. The AGPL licence also matters if you are embedding Countly into something you distribute; for a company running it internally for its own apps, it changes nothing.

The mobile SDKs are the reason to pick it

iOS, Android, Flutter, React Native, Unity, web, and Node SDKs are all first-party, maintained, and documented, with consistent event and user-property APIs across them. Crash reporting with symbolication for native mobile crashes is included, which is the feature that keeps mobile teams on Countly when a web-first tool would otherwise win. If your product is a mobile app and you are trying to get off Mixpanel or Firebase Analytics, this SDK coverage is the concrete advantage, and it is a real one.

PostHog is the default for most new teams

PostHog does product analytics plus session replay, feature flags, experiments, and surveys, on ClickHouse instead of MongoDB, with a much larger community and faster development. It is heavier still, wanting 4 GB of RAM at minimum and closer to 8 GB to be comfortable, and its self-hosted edition is explicitly positioned for smaller deployments while the company steers larger ones to its cloud. For a web or SaaS product, PostHog is where I would start. For a mobile-first product where crash analytics and native SDKs matter most, Countly holds its ground. Matomo is the middle path if you want strong web analytics with some product-style events on a PHP and MySQL stack you may already know how to run.

What I'd do

Mobile app, small team, and a VM with 4 GB to spare: Countly Community Edition via the official compose file, mongodump nightly to object storage, Community features only, and a hard look at the feature matrix before promising anyone funnels on a specific dimension. Web product or anything with a signup flow: PostHog. A blog or a marketing site: neither of them, because product analytics on a site with no logged-in users is a 2 GB way to count pageviews.