Countly server: self-hosted analytics where the data stays on your hardware

The problem Countly server solves: analytics without handing over the raw events

Most product analytics arrives as a hosted service. You send events to someone else's cluster and read them back through a dashboard. That is convenient, and it is also the reason some organisations cannot use those tools at all: the raw event stream, including user identifiers and device properties, leaves the network. Countly's answer is to ship the server side as software you run. The README states that unlike SaaS-only analytics tools, Countly can be deployed on-premises or in a private cloud, giving you control over data, infrastructure, compliance and security. The repository is the server: event collection, storage, dashboards, APIs and plugins. The SDKs that send data are separate projects, and the README notes they are identical across editions. The audience is therefore specific. It is teams that already run Linux servers and MongoDB, that have a reason to keep event data inside their own perimeter, and that are willing to take on the operational cost in exchange. It is not aimed at someone who wants to paste a script tag and see a chart five minutes later.

How the pieces fit: SDKs write, the API stores, the frontend reads

The architecture visible in the repository is a three part split. Mobile, web and desktop SDKs send data into the write API. The api/ directory holds the server processes that accept those writes and persist them to MongoDB, which the README lists as the datastore, alongside Node.js as the runtime and Linux as the target operating system. The frontend/ directory serves the dashboard, and the README makes a point that matters for anyone building on top of it: the dashboard is built using the read API, so anything visible in the UI can be fetched through the API instead. That is a real design commitment, not marketing, because it means the UI has no private data path. Around the core sits a plugin system. Plugins are enabled by name through the COUNTLY_PLUGINS environment variable, and the Dockerfile and docker-compose.yml both show long comma separated lists of them, covering crashes, push, views, compliance-hub, remote-config, dashboards and more. A deployment is therefore defined as much by its plugin list as by its code version. The consequence is that two Countly installations can behave quite differently, and a plugin you rely on is a component you have to keep in that list through every upgrade.

Installing Countly server on Ubuntu or CentOS

The README is explicit about the target: the installation script assumes a fresh Ubuntu, CentOS or RHEL Linux with no services listening on port 80 or 443, and those ports open to incoming traffic. It then installs every library and service Countly needs. The shortest path is the one liner the README gives first.

wget -qO- https://c.ly/install | bash

This downloads and runs the installer. Because it is piped straight into bash, read the script before running it on a machine you care about. If you prefer to see the file first, the README points to bin/countly.install.sh inside a stable release from the releases page. After installation the dashboard is served on the host, and the first thing you do is create an administrator account. The README does not document that first login flow in detail; it links to the server installation guide for the steps.

The Docker route avoids the fresh machine requirement. The repository ships a docker-compose.yml with a mongodb service, a countly-api service and a countly-frontend service on a shared network, and the API service reads its configuration from environment variables.

services:
  countly-api:
    image: 'countly/api:latest'
    environment:
      - COUNTLY_PLUGINS=mobile,web,desktop,plugins,density,locale,browser,sources,views,logger,systemlogs,populator,reports,crashes,push,star-rating,slipping-away-users,compare,server-stats,dbviewer,times-of-day,compliance-hub,alerts,onboarding,consolidate,remote-config,hooks,dashboards,sdk,data-manager
      - COUNTLY_CONFIG__MONGODB_HOST=mongodb
      - COUNTLY_CONFIG_API_API_WORKERS=4

Two details in that snippet are worth pausing on. COUNTLY_CONFIG_API_API_WORKERS is annotated in the file as the CPU core count, so it is a sizing decision rather than a default you can ignore. And the plugin list is duplicated between the API and frontend services, which means the two must be kept in step by hand. The README also notes that Countly Lite has Docker support through the official registry image, and the compose file carries commented Enterprise image lines for the paid edition.

Where Countly server is the wrong choice

The honest limitation is operational, not functional. You are running MongoDB, Node.js, nginx and a plugin set on your own hardware, and the README's installation assumptions are narrow: a fresh Ubuntu, CentOS or RHEL host with ports 80 and 443 free. If your environment already has a web server on those ports, the one line installer is not going to work as written. If you are on Debian, Alpine or a container platform with an opinionated ingress layer, you are adapting the setup yourself. The Docker path reduces the host requirements but does not remove the underlying services or the MongoDB volume you now have to back up. There is a second, sharper boundary. The README describes Countly Lite as free to use under an open-source, non-commercial license. That is a licence restriction, not a feature tier, and it is the single fact most likely to disqualify the free edition for a commercial product. The repository's licence file is named AGPLv3 and the GitHub metadata reports the licence as NOASSERTION, so the exact terms are something you read in LICENSE.md rather than infer from a label. Finally, if your need is a handful of page views on a brochure site, the cost of running this stack exceeds the value of the data. A hosted tool is the better answer there.

Countly compared with a hosted analytics service

The real alternative for most teams is a hosted product analytics service, and the difference is not the chart types. It is where the data lives and who operates the pipeline. With a hosted service you get an ingest endpoint, a managed datastore, and someone else on call for the storage layer. With Countly server you get the same shape of capability, but the ingest endpoint is a process you started, the datastore is a MongoDB instance you sized, and the upgrade window is one you schedule. That trade is the whole product. The README leans into it with the phrase full data ownership and deployment flexibility, and the repository backs the claim structurally: there is a Dockerfile, a docker-compose.yml, a Vagrantfile and an install script, all of which exist because the operator is expected to run this. A second alternative sits inside Countly itself. The README lists Countly Flex, a managed SaaS option with dedicated servers and region-based hosting, and Countly Enterprise, available self-hosted or as managed private cloud. So the choice is not only Countly versus another vendor; it is also which Countly edition matches your compliance requirements and your appetite for running MongoDB. The SDKs stay the same across editions, which means moving between them does not force a client rewrite.

Upgrades, maintenance and what the licence actually gates

Maintenance is active: the repository is not archived, and the last push was on 2026-09-15. Releases follow a two track pattern visible in the release list, with an LTS line such as 25.03.53-LTS alongside a non-LTS line such as 24.05.53, both published on 2026-09-03. That matters for planning. An LTS line implies a longer support horizon and a slower cadence, and the README does not document the support window for either track, so confirm it with the vendor if it drives your upgrade schedule. Upgrades themselves are handled by a documented process: the README links to an upgrading guide rather than describing the steps inline, and it does not document rollback. Treat that as a gap you plan around, because MongoDB schema changes during a major version jump are the usual reason a rollback is wanted. On licensing, the practical implication is that the free edition's non-commercial restriction is a scope question, not a technical one. Nothing in the code stops a commercial deployment; the licence does. If you are evaluating Countly for a commercial product, resolve the licence question before you invest in the deployment, and read LICENSE.md and AGPLv3 directly rather than relying on the repository's licence label.

Editorial conclusion

Adopt Countly server if you need analytics and engagement data to stay on infrastructure you control, and if you accept running MongoDB, Node.js and the plugin set yourself. Do not adopt it if you want a managed service with no operational work, or if you intend to use the free edition commercially: the README describes Countly Lite as free under an open-source, non-commercial license, so verify the exact terms in LICENSE.md and AGPLv3 against your use case before you commit. Verify first that your target host is a fresh Ubuntu, CentOS or RHEL machine with nothing listening on ports 80 and 443, because the installation script assumes exactly that.

Frequently asked questions

Official sources

1. Countly/countly-server on GitHub
2. Issues
3. Project website
4. README
5. Releases