Your mobile app ships. Product wants “just add analytics.” Engineering reads the Firebase docs and realizes you are about to pipe every screen tap to Google with device identifiers you never audited. You still need to know if onboarding is broken — you just do not need a surveillance stack to learn it.
Aptabase (aptabase/aptabase) is an open-source analytics platform aimed at mobile, desktop, and web apps — not marketing websites. Privacy-first by design: session-based metrics without persistent user IDs, GDPR/CCPA/PECR-friendly positioning, SDKs for Swift, Kotlin, Flutter, React Native, Electron, Tauri, Unity, and more. Self-host via the separate aptabase/self-hosting Docker Compose setup; AGPLv3 on the server, MIT on SDKs.
What it actually does
Aptabase is app-centric analytics: events, sessions, and a built-in dashboard for the questions product teams actually ask — which builds crash onboarding, which feature gets opened, is anyone using the new settings screen — without building a data warehouse first.
Compared to Google Analytics or Firebase Analytics:
- No ad-tech identity graph — Aptabase focuses on aggregated usage, not cross-app tracking profiles.
- First-party hosting — event data lands on your Aptabase instance, not a US ad vendor’s bucket by default.
- SDK coverage — native and cross-platform clients send events to your ingest endpoint; web has aptabase-js.
It is inspired by Plausible (website analytics). If you only need marketing site stats, Plausible or Umami might fit better; Aptabase is for the app binary you ship to App Store, Play Store, or Electron auto-update.
Why self-host Aptabase?
Canadian and EU clients ask where telemetry goes. Self-hosting on a Canadian VPS gives a concrete answer: events stay in your database, behind your TLS cert, on infrastructure you patch.
App store privacy nutrition labels. Minimal collection plus your own host makes disclosures simpler than “we use Google Analytics” and hope the SDK defaults are sane.
Cost predictability. Managed Aptabase Cloud exists; self-host trades subscription for Docker ops. For a handful of apps with moderate event volume, a small VPS is often enough.
AGPL awareness. Server code is AGPLv3 — fine for internal use; if you modify the server and offer analytics as a service to third parties, understand the license obligations. SDKs are MIT for your apps.
What running it takes
Official path: clone aptabase/self-hosting, edit docker-compose.yml (secrets and SMTP are called out in comments), docker-compose up -d, UI on port 8000 by default.
First login is manual: register an account, then grab the email activation link from container logs unless you configure SMTP. Plan backups on the database volume and put nginx/Caddy in front for HTTPS before pointing production apps at it.
Resource sizing depends on event rate; start with a modest Docker host and watch disk growth on the DB. Point SDKs at your self-hosted ingest URL per docs for each platform.
Who it's for (and who should skip it)
Good fit: indie app developers, agencies shipping Flutter/React Native apps for clients, desktop tools (Tauri/Electron) that need telemetry without Firebase, teams replacing Firebase Analytics for privacy policy reasons.
Maybe skip it: marketing-site-only teams (use Plausible/Umami on the WordPress site). If you need funnel analysis with user-level IDs across web and ads, you are back in product analytics SaaS territory — Aptabase is deliberately simpler.
Hosting it in Canada
We deploy analytics sidecars on Canadian Docker hosting when clients want app telemetry in-country — TLS, SMTP for activation emails, backups, and firewall rules so the ingest endpoint is not public wider than necessary.
Tell us your apps and event volume if you want help pairing Aptabase with the same VPS that hosts your API. The SDK integration is usually easier than keeping Postgres healthy.
