Replace Flurry: self-hosted

▸Example Flurry call (the "before")

swift Respectlytics

import Flurry_iOS_SDK

let builder = FlurrySessionBuilder.init()
    .withAppVersion("1.0")
    .withLogLevel(FlurryLogLevelAll)
    .withCrashReporting(true)
Flurry.startSession(apiKey: "YOUR_FLURRY_KEY", sessionBuilder: builder)

Flurry.log(eventName: "Purchase", parameters: [
    "user_id": userId,
    "value": String(price),
    "currency": "USD",
])

Regulated industries — telehealth, fintech, government, defence — frequently require that analytics data never leave operator-controlled infrastructure. Respectlytics's self-hosted option (AGPL-3.0 server + MIT-licensed SDKs) lets you run the entire analytics stack on your own hardware. The SDK is the same; only the API endpoint changes.

☑Remove Flurry cleanly

1
Remove pod 'Flurry-iOS-SDK/FlurrySDK' from Podfile
2
Remove implementation 'com.flurry.android:analytics:...' from build.gradle
3
Remove react-native-flurry-analytics from package.json if used
4
Remove Flurry.builder().build(...) initialisation and Flurry.logEvent(...) call sites
5
If you used Flurry's Configuration Provider for remote config, plan a separate migration (e.g., Firebase Remote Config, GrowthBook)
6
Delete the Flurry app entry once events stop flowing (the dashboard may already be sunset by the time you migrate)

⇋Flurry vs Respectlytics — self-hosted deployment

	Flurry	Respectlytics
Self-hostable	— see tool note above (typically no)	Yes (AGPL-3.0 server)
Operator-managed database	— typically no	Yes (you choose Postgres deployment)
Air-gapped deployment possible	No	Yes
SDK license	— varies	MIT (permissive)
Server license	— typically closed	AGPL-3.0 (source-available)

❓Frequently asked questions

What's the AGPL-3.0 obligation in practice?

If you modify the server source AND offer the modified server as a service to third parties over a network, you must publish your modifications under the same license. Internal self-hosting for your own apps does NOT trigger publication obligations. Consult your legal team for specific applicability.

What infrastructure do we need?

A Linux host (or container) running Python 3.12 + Postgres 14+ + a reverse proxy (nginx / Caddy). The default configuration scales to ~10 million events/day on a 4-vCPU / 8 GB box; larger deployments scale horizontally. See the public README for hardware sizing guidance.

Do we get updates automatically?

No — self-hosted deploys pull the latest source and run migrations on a cadence you control. We publish release notes for each version. No auto-update; you decide when to upgrade.

Are the SDKs AGPL too?

No — SDKs are MIT-licensed. Fork and modify freely with no copyleft obligation. Only the server is AGPL.

⇢Related migration guides

Replace Flurry: no att prompt Same tool, No ATT prompt Replace Flurry: no pii collected Same tool, No PII collected Replace Flurry: no phi collected Same tool, No PHI collected Replace Flurry: 5-field event schema Same tool, 5-field event schema Replace Flurry: ram-only event queue Same tool, RAM-only event queue Replace Flurry: fewer third-party sdks Same tool, Fewer third-party SDKs Replace Flurry: smaller app binary Same tool, Smaller app binary Replace Flurry: faster cold start Same tool, Faster cold start Replace Flurry: eu data residency Same tool, EU data residency Replace Flurry: open-source sdk + server Same tool, Open-source SDK + server Replace Firebase Analytics: self-hosted deployment Same outcome, Firebase Analytics Replace Google Analytics for Firebase: self-hosted deployment Same outcome, Google Analytics for Firebase

Replace Flurry with self-hosted analytics