Aptabase is self-hostable analytics for mobile, desktop and web apps

Two ways in: a hosted service or your own server

The README splits the offering cleanly, and the split is about who carries the operational burden rather than about features.

The managed cloud path is described as the easiest and quickest route, a fully managed service run by the people who wrote the software, where updates and patches are handled for you. The self-hosted path is free, and the README is explicit that maintenance and updates become your responsibility. Setup instructions for that path are not in this repository at all; they live in a separate project, aptabase/self-hosting, linked from the README.

That split is worth pausing on. Nothing in this repository gives you a production deployment recipe, so the self-hosted route is a two-repository task from the start: this one for the code, the other for the operating instructions.

The primary language is C#, and the repository root makes the shape of the system visible: `Aptabase.sln`, `src/`, `tests/`, `docs/`, `tools/`, `scripts/`, a `Dockerfile`, a `docker-compose.yml` and a `Makefile`. It is not archived and the last push was on 2026-10-13, though the repository publishes no GitHub releases, so there is no tagged version stream to pin against.

Postgres for identity, ClickHouse for events, one container at the end

The architecture is visible in the two repository files worth reading: the compose file and the Dockerfile.

The development compose file brings up three services with fixed ports. A `postgres:15` service publishes `5432:5432` and creates a database user and password for the application. A `clickhouse/clickhouse-server:23.8.4.69` service publishes `8123:8123`, stores its data in a named volume, and raises the `nofile` soft and hard limits to 262144, which is the usual sign that the event store is expected to take a lot of file descriptors. A `dockage/mailcatcher:0.8.2` service publishes `1025:1025` and `1080:1080` so outbound mail does not leave the machine during development. Both database services use named volumes (`pgdev-data`, `clickhousedev-data`) with the local driver, and both set `restart: always`.

  clickhousedev:
    container_name: aptabase_clickhousedev
    image: clickhouse/clickhouse-server:23.8.4.69
    restart: always
    ports:
      - "8123:8123"
    environment:
      CLICKHOUSE_USER: aptabase
      CLICKHOUSE_PASSWORD: aptabase_pw

The split of responsibilities is the standard one for this class of product: PostgreSQL holds accounts, apps and app metadata, while ClickHouse holds the event stream that the dashboard queries. Note that the compose file is explicitly a development setup: it hardcodes credentials and publishes the databases on the host network, so copying it into production unchanged is a mistake.

The build is a three-stage Dockerfile. It compiles the server on `mcr.microsoft.com/dotnet/sdk:10.0`, copying only `Aptabase.csproj` first so the `dotnet restore` layer caches independently of source changes, then publishes with `-c Release -o /work/publish /p:UseAppHost=false`. It builds the web frontend separately on `node:22` with `npm install` and `npm run build`. The final image is `mcr.microsoft.com/dotnet/aspnet:10.0`, and the entrypoint is a single command:

ENTRYPOINT ["dotnet", "Aptabase.dll"]

The `COPY ./etc/clickhouse` and `COPY ./etc/geoip` steps into the server build stage are the two data inputs the server ships with. GeoIP in particular tells you the dashboard resolves countries from request data, and it also tells you the license question you inherit from that database. The container copies the LICENSE file into the image.

MIT SDKs, AGPL server, and eleven targets to integrate

The licence split is the single most important fact for an adopting team. The README states it directly: Aptabase itself is open source under AGPLv3, you may use it for free, but you must share any changes you make to the code. The SDKs are MIT licensed and, in the README's phrasing, can be used on your apps without any restrictions.

That means a mobile app can ship the SDK in a closed-source product with no obligation, while anyone who modifies and hosts the Aptabase server itself has to publish those changes. This is a licence observation about scope, not advice about how to deploy it.

The SDK list is where the project's positioning becomes concrete. There are separate repositories for Swift, Android with Kotlin, React Native, Flutter, Tauri, .NET MAUI, Electron, web apps via `aptabase-js`, Unreal Engine and Unity, plus NativeScript, which is maintained inside the nstudio plugins repository rather than as its own repo. The README also points to a wiki guide on building your own SDK for platforms not on that list, which is the honest answer for anything else.

The claim to check when you compare products is the measurement model. The README says Aptabase collects minimal usage data without unique identifiers and focuses on monitoring sessions, and that it is built for Mobile, Desktop and Web apps rather than for pages. No unique identifiers is a privacy property, and it is also an analytical limitation, which the next section addresses.

Local development runs the Vite server and dotnet watch side by side

The Makefile is short enough to read in full, and it explains the split between the dashboard front end and the API.

dev: vite-dev dotnet-dev

vite-dev:
	cd ./src && npm run dev

dotnet-dev:
	cd ./src && DOTNET_WATCH_RESTART_ON_RUDE_EDIT=1 dotnet watch

The default target runs two processes: a Vite dev server for the web dashboard and `dotnet watch` for the server, both from `src/`. The `DOTNET_WATCH_RESTART_ON_RUDE_EDIT=1` variable makes the watcher restart on file save in the .NET editor, which speeds up the edit loop at the cost of restarting more often.

Between the Makefile and the Dockerfile, the front end is a Vite plus npm project living in `src/` alongside the .NET project, and it is compiled into `wwwroot` for the final image. There is no separate deployment artifact for the dashboard: one container serves both.

What the repository does not document is worth noting too. There is no environment variable list in the README, no port for the production server, no configuration schema, and no database migration or upgrade procedure. Those belong to the self-hosting project, so anyone planning an upgrade path has to read that repository before committing.

What Aptabase does not do, and how it differs from Plausible

Aptabase credits Plausible as its inspiration and points readers to Plausible for privacy-friendly website analytics.

Aptabase is built around mobile, desktop and web apps, with a session-oriented model and SDKs for multiple application platforms.

The consequences follow from the missing identifiers. Without unique identifiers you cannot build a reliable cross-device user graph, so features that depend on deduplicating one person across sessions are the first thing you lose. Aptabase does not present itself as a Firebase or Google Analytics replacement feature for feature; the README describes it as an open-source alternative to those, and the AGPL self-hosting option is what makes it a real alternative to a vendor product at all.

It is also not an event pipeline you can bend. The README describes a built-in dashboard for essential metrics rather than a query interface, custom dimensions or data export, and none of those appear in the documentation here. If you need raw event export or your own analysis on top, the ClickHouse instance is part of the system and reachable, but the project does not commit to that as a supported interface.

Editorial conclusion

Choose Aptabase when your product is a shipped app on Apple, Android, Flutter, React Native, Electron, Tauri, MAUI, NativeScript, Unity or Unreal, because that is exactly the surface its SDK set targets, and pass on it if you want per-campaign, per-referrer and conversion reporting for a website, since the project's own inspiration is a web analytics tool but its measurement model is session and install oriented rather than attribution oriented. Before deploying the server yourself, read the separate aptabase/self-hosting repository the README points to for the actual setup, and confirm the AGPLv3 obligations on your side: the SDKs are MIT and unrestricted in your app, but the server you modify must be shared.

Frequently asked questions

Official sources

1. aptabase/aptabase on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README