▸Install the React Native SDK
npm install @respectlytics/react-native
# or
yarn add @respectlytics/react-nativeJavaScript-only — no native modules, no auto-linking, no New Architecture migration concerns. Bundle size: ~14KB minified+gzipped. Works in any Expo project (managed or bare) without expo prebuild.
▸Initialize Respectlytics in React Native
// App.tsx (or App.js)
import { useEffect } from 'react';
import Respectlytics from '@respectlytics/react-native';
export default function App() {
useEffect(() => {
Respectlytics.configure({ appKey: '<YOUR_APP_KEY>' });
}, []);
return <YourApp />;
}Initialize once in your top-level component. No native config; no Info.plist or AndroidManifest changes. The SDK is Hermes- and JSC-compatible.
✦Privacy & implementation notes
AGPL-3.0 is a common license for SaaS-as-source projects (Plausible, Matomo, GitLab Community Edition). The license design is to prevent vendors from forking the project, modifying it privately, and offering their fork as a competing closed-source SaaS — but it does not impede internal self-hosting at all. For most enterprise self-hosters, the license is a non-issue.
Self-hosted Respectlytics is operated by the same management commands and Django infrastructure as our cloud — the deployment difference is purely the database hostname and the network egress profile. If you can run a Django + Postgres app on your infrastructure, you can run Respectlytics.
The React Native SDK is JavaScript-only — no Objective-C/Swift bridging on iOS, no Java/Kotlin bridging on Android. Side effects: no react-native link, no auto-linking, no New Architecture migration concerns, no platform-channel exception surfaces. Trade-off: no access to platform-only metadata (which we don't want to collect anyway).
Works in Expo managed workflow without expo prebuild. No config plugin is required. EAS Build users: nothing to configure. This is the smoothest integration path on RN — most analytics SDKs require ejecting from managed.
⇋How this compares to other analytics SDKs
| Self-hosting | Firebase Analytics | Mixpanel | Amplitude | Respectlytics |
|---|---|---|---|---|
| Self-hostable | No | No | No (cloud-only) | Yes (AGPL-3.0 server) |
| SDK license | Apache 2.0 | Apache 2.0 | MIT | MIT |
| Server source available | No | No | No | Yes (public repo) |
| Operator-managed database | No | No | No | Yes (you choose) |
| Air-gapped deployment possible | No | No | No | Yes |
❓Frequently asked questions
What infrastructure do we need to self-host?
A Linux box (or container) running Python 3.12, Postgres 14+ (managed or self-managed), and a reverse proxy (nginx / Caddy / similar). The default configuration scales to ~10 million events/day on a 4-vCPU / 8 GB box; larger deployments scale horizontally. Hardware requirements are documented in the public README.
What's the AGPL-3.0 obligation?
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 — it's only when you offer the server to others over a network. Consult your legal team for specific applicability; the FSF's AGPL FAQ is the canonical reference.
Are SDK changes also covered by AGPL?
No. The SDKs (Swift, Kotlin, RN, Flutter) are MIT-licensed — fork and modify freely with no copyleft obligation. Only the SERVER is AGPL.
Do self-hosted instances get our updates automatically?
No — you upgrade by pulling the latest source and running migrations. We publish release notes for each version. There's no auto-update; self-hosting means you control the deployment cadence.