The full Respectlytics stack is now open source. The server is published as the Community Edition under AGPL-3.0, joining the MIT-licensed SDKs. Self-host for free, audit every line, or use our managed SaaS. Nothing is held back — the Community Edition runs the same analytics engine as the managed service.
Every line of code — from the SDKs in your app to the server processing your events — is now public. Audit it, self-host it, or use our managed SaaS. Your choice.
When we launched Respectlytics, our SDKs were already open source under the MIT license. That let developers audit exactly what data leaves their app — no hidden tracking, no surprises. But the server that received that data was closed. Today, that changes. The entire Respectlytics stack — SDKs and server — is now open source.
🚀 What changed
We published the Respectlytics server as the Community Edition under the AGPL-3.0 license. This is the same analytics engine that powers our managed SaaS — session analytics, funnel tracking, behavioral analysis, automated drop-off detection, the full API. Nothing held back.
Here is what the full stack looks like now:
| Component | License | Repository |
|---|---|---|
| Server (Community Edition) | AGPL-3.0 | respectlytics/respectlytics |
| Swift SDK (iOS) | MIT | respectlytics/respectlytics-swift |
| Flutter SDK | MIT | respectlytics/respectlytics-flutter |
| React Native SDK | MIT | respectlytics/respectlytics-react-native |
| Kotlin SDK (Android) | MIT | respectlytics/respectlytics-kotlin |
🔍 Why open source the server?
Privacy claims are only as good as the code behind them. We tell developers that Respectlytics stores exactly 5 fields per event — event_name, session_id, timestamp, platform, and country. That IP addresses are processed transiently for geolocation and immediately discarded. That extra fields are silently rejected.
With open-source SDKs alone, you could verify the client side. But you had to trust us on the server side. That trust gap bothered us. Now you can read the Django models, the API views, the privacy guards. The claim is verifiable end to end.
⚙️ The open-core model
This is an open-core approach. The Community Edition includes the full analytics engine:
Community Edition — what's included
The managed SaaS adds operational features on top — automated 90-day retention purging, quota management, billing, email alerts, and EU-hosted infrastructure. These are the things you would rather not maintain yourself.
🛠️ Self-hosting in 5 minutes
The Community Edition is designed to be simple. It needs Django and PostgreSQL — no ClickHouse, no Kafka, no Redis. Here is how to get started:
git clone https://github.com/respectlytics/respectlytics.git
cd respectlytics
cp .env.example .env # edit with your secrets
docker compose up -d
That gives you the full analytics server with a PostgreSQL database. Point any Respectlytics SDK at your instance:
Respectlytics.configure(
apiKey: "your-api-key",
apiEndpoint: "https://your-server.com"
)
💡 All SDKs support self-hosted endpoints
All four SDKs — Swift, Flutter, React Native, and Kotlin — support custom apiEndpoint configuration out of the box since v2.2.0. Point them at your self-hosted instance and they work identically to the managed SaaS.
🛡️ Why this matters for privacy
Many analytics vendors display compliance badges on their marketing pages. These badges represent a vendor's promise. Open-source code is something different — it is proof.
What the full stack being open enables
This does not make Respectlytics "compliant" with any specific regulation. Compliance depends on your jurisdiction, use case, and how you deploy. But it makes the system transparent, defensible, and auditable — which is what security reviews actually need.
📄 Why MIT for SDKs and AGPL for the server?
SDKs ship inside your mobile app binary. MIT is the standard for libraries you embed — no license friction, no attribution headaches beyond keeping the license file.
The server runs on your infrastructure. AGPL-3.0 ensures that if someone modifies and deploys the server, those modifications stay open. This protects the community while still allowing private deployment for your own analytics.
The two licenses at a glance
🔑 Key takeaways
- → The entire stack is open source. SDKs under MIT, server under AGPL-3.0. Nothing is held back.
- → Self-host the Community Edition for free. Django + PostgreSQL. No complex infrastructure required.
- → Privacy claims are now verifiable end to end. Read the models, the views, the privacy guards — not just our marketing page.
- → Open-core model. Community Edition has the full analytics engine. Managed SaaS adds ops features you'd rather not maintain.
- → All four SDKs support self-hosted endpoints out of the box since v2.2.0.
❓ Frequently asked questions
Q: Is the Community Edition really free to self-host?
Yes. The Community Edition is licensed under AGPL-3.0 and free to self-host. It includes session analytics, funnel tracking, behavioral analysis, and the full API — the same analytics engine that powers our managed SaaS.
Q: What's the difference between the Community Edition and managed SaaS?
The Community Edition is the open-source server you host yourself. You manage infrastructure, updates, and backups. The managed SaaS adds automated retention purging, quota management, billing, email alerts, and EU-hosted infrastructure — so you can focus on your app instead of ops.
Q: Why AGPL-3.0 for the server and MIT for the SDKs?
SDKs ship inside your mobile app, so MIT lets you embed them without license headaches. The server runs on your own infrastructure, so AGPL-3.0 ensures improvements stay open while still allowing private deployment.
Q: Can I use the Community Edition in production?
Yes. The Community Edition runs the same Django analytics engine as the managed SaaS. It is production-ready with PostgreSQL. You are responsible for infrastructure, backups, and updates, but the analytics features are identical.
Q: What infrastructure does the Community Edition require?
Django and PostgreSQL — that is it. No ClickHouse, no Kafka, no Redis. You can deploy with Docker Compose in under five minutes. The entire stack runs on a single server for most workloads.
Q: Can I fork and modify the Community Edition?
Yes. Under AGPL-3.0, you can fork, modify, and deploy for your own use. If you deploy a modified version as a public-facing service, you must share your modifications under the same license. Private internal use requires no disclosure.
Q: Do the SDKs work with both the Community Edition and managed SaaS?
Yes. All four SDKs — Swift, Flutter, React Native, and Kotlin — support a custom apiEndpoint parameter since v2.2.0. Point them at your self-hosted server or use the default managed endpoint. The same SDK binary works with either.
Q: What data does the Community Edition store?
Exactly 5 fields per event: event_name, session_id, timestamp, platform, and country. IP addresses are processed transiently for approximate geolocation and immediately discarded. The API rejects any extra fields.
Q: Can I migrate from the managed SaaS to self-hosted (or vice versa)?
Both run the same analytics engine, so the data format is identical. Export your data from one and import into the other. The SDKs only need a config change to switch the apiEndpoint — no code changes required.
Legal Disclaimer: This announcement describes our technical architecture and licensing. It does not constitute legal advice. Privacy requirements vary by jurisdiction and change over time. Consult your legal team to determine the requirements that apply to your situation.
📚 Additional resources
- Server Repository on GitHub — Community Edition source code, Docker setup, and documentation
- Open Source Overview — Deployment options, license details, and architecture guide
- SDK Documentation — Integration guides for Swift, Flutter, React Native, and Kotlin
- Our SDK Source Code is Public — The earlier post about why our SDKs are open source