Why self-hosted mobile analytics and replay need a different plan
A mobile product or platform lead who wants native usage data and session replays without sending device data to a third-party vendor should plan for a mobile-specific stack from the start. OpenReplay's README lists native mobile replay for iOS, Android and React Native, and PostHog's README lists event tracking across its product analytics suite, so most teams pair the two or choose one based on whether replay or event analytics is the primary need. Confirm which mobile SDKs each platform currently ships and whether the mobile replay feature set matches the web feature set before you commit, because the README describes the capability at a summary level only.
Mobile differs from web in four ways that change the build. First, the SDK is packaged inside the app binary, so every analytics change ships through an app store release cycle rather than a single deployment, and a broken masking rule can stay live on user devices until the next build is adopted. Second, app store review requires accurate privacy disclosures for the data the app collects, so the team must map each SDK's collected data types to the store's declarations and keep that mapping current when the SDK updates. Third, users go offline on trains, in basements and on flights, so the SDK needs to buffer events locally and send them later. Confirm how each candidate SDK queues, caps and retries offline events, and what happens to a buffer if the app is force-closed. Fourth, device identifiers such as advertising IDs and install IDs carry personal data meaning in many jurisdictions, so the team must decide which identifiers are collected, whether they are reset, and how they link mobile and web sessions for the same user.
Decide these four items before writing tracking code: the SDK version policy, the store disclosure owner, the offline buffering limits and the identifier design. Each decision changes the masking tests, the retention settings and the self-hosted infrastructure you need. Ask any implementation partner to demonstrate the offline path and the masking path on real test devices, and to show where the data lands in your own environment.
Which requirements shape a self-hosted mobile analytics build
This table sets out the requirements that most affect a self-hosted mobile analytics and replay build, and what each one changes in the architecture. Read each row as a question to answer before choosing an SDK, a backend topology or a retention policy. The main takeaway is that most of the hard work sits in the app and the release process, not only in the server.
| Requirement | What it asks for | Build impact |
|---|---|---|
| App store privacy disclosures | Accurate declarations of the data types collected, their purposes and whether they are linked to users, in Apple's privacy nutrition labels and Google Play's data safety section | Every SDK field, event property and replay setting must be inventoried so declarations match the shipped app. Confirm current store requirements directly with each store before release. |
| Capture-time masking of inputs and screens | Sensitive fields, screens and text are masked on the device before any data leaves it | Masking rules must be set in the native SDKs as well as the web layer. Test masking on each release, since new screens can expose data that old rules missed. |
| Offline event buffering | Events and replay chunks are stored locally when the device has no connection and delivered in order when it reconnects | Local storage limits, batch sizes and retry behavior must be set. Confirm how the chosen SDK handles dropped, duplicated or delayed events, and how long unsent data stays on the device. |
| Data residency for the self-hosted backend | Event, replay and device identifiers are stored in a region and account the organization controls | Choose the hosting region before the app ships, since moving stored replays later is harder. Document where ingestion, storage and backups sit. |
| Retention limits | Defined periods for raw events, replay recordings and backups, each with a deletion method | Retention is set on the server, but backups and exports may hold data longer. Build deletion jobs and confirm how replays are removed from storage. |
| Access control for replays | Only named roles can view recordings, with logging of who viewed what and why | Replays need role-based permissions, audit trails and single sign-on for staff. Enterprise features for these controls may sit in a paid edition, so confirm licensing first. |
| First-party ingestion from the operator's domain | Analytics traffic is sent to a domain the organization controls, so it is not blocked as third-party traffic | A custom ingestion domain or proxy must be set up for each app build and environment. Plan certificates, DNS and routing as part of the mobile release process. |
Which platform fits which mobile team
OpenReplay fits teams whose first question is what users did on the screen before a crash or drop-off. Its README lists native mobile replay for iOS, Android and React Native, alongside DevTools with network activity, console logs and JavaScript errors, so engineers and product staff can review the same session. Self-hosting keeps recordings in your infrastructure, and the README describes capture-time sanitization that masks or skips data before it reaches the server.
- Native replay coverage: confirm which SDK versions and OS releases your app targets are covered before committing.
- Sizing reference: the README says a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to start self-hosting. Treat this as a starting point for a test environment, not a production sizing.
- Enterprise features: the Enterprise edition adds SSO and SAML, SCIM provisioning, roles and permissions, audit trail, a custom SLA and dedicated support. These are paid, custom-priced and tied to a multi-year contract.
- Licensing: most of the monorepo is AGPLv3, some directories are MIT, and the ee/ directory is under a separate commercial license.
- Release cadence: the latest release listed on the GitHub releases page is v1.28, published September 25, 2025, so check current versions before planning.
Before you choose, confirm how your app's native masking rules map to OpenReplay's capture settings and who in your organization owns the upgrade cycle.",
PostHog fits teams that need product analytics, funnels, retention and feature flags in one tool, with session replay as a companion. Its repository is MIT licensed except for the ee/ directory, and its self-host documentation describes a free Docker Compose (hobby) deployment installed with a deploy-hobby script. That path suits evaluation and small volumes, not an enterprise production commitment.
- MIT self-host path: the hobby deployment is MIT, but premium features from the ee directory on a self-hosted instance require a PostHog license.
- Volume guidance: the README says open-source deployments should scale to approximately 100k events per month and recommends migrating to PostHog Cloud above that.
- No vendor support on self-host: PostHog states self-hosted deployments are officially unsupported and it does not offer customer support for self-hosted questions. Budget internal or partner support accordingly.
- Kubernetes limit: new Kubernetes deployments of the paid self-hosted product are no longer supported, so plan the hosting model before design.
- Sizing reference: PostHog recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage for its self-host setup.
Confirm your expected monthly event count from mobile SDK usage and whether the MIT-only feature set covers the flags and surveys you need.",
A combined stack runs mobile and web analytics in one self-hosted deployment so that a user's journey across app and website lands in one data model. This is useful when marketing and product teams work across both channels and want consistent event names, identities and consent handling. It also concentrates risk, because one deployment holds all behavioral data and one set of access controls must cover it.
- Shared identity: decide early how anonymous and logged-in identifiers are joined across app and web, and document the rule.
- Consent in one place: a single consent gate must govern both SDKs, including app-level permissions on mobile.
- Platform fit: OpenReplay covers replay for mobile and web, while PostHog covers events and flags, so a combined design may use both tools with clear ownership.
- Data location: confirm that both the web and mobile SDKs send data only to your own endpoint, including any third-party CDNs they load.
- Operational load: a single deployment is simpler to back up and patch, but any outage affects both channels.
Ask your implementation partner to show how a sample user journey appears in the chosen stack before you commit to a combined design.
Some mobile teams choose their platform by governance requirements first, such as identity integration, audit evidence and vendor support terms. The distinction between community and enterprise editions decides much of this, and it should be checked in writing with the vendor rather than assumed from marketing pages. This tab covers the questions that change once the analytics stack holds regulated or customer-facing data.
- OpenReplay Enterprise: the pricing page lists SSO and SAML, SCIM, roles and permissions, audit trail, a custom SLA and dedicated support, at custom pricing on multi-year contracts.
- PostHog platform packages: SSO, audit logs, custom roles and project permissions are sold as platform packages, so confirm which tier your deployment falls under.
- Evidence trail: map who can view replays, export events and change capture rules, and where those actions are logged.
- Support boundary: write down who answers a production incident on each tool, whether that is the vendor, your team or a partner.
- Licence review: have counsel confirm the AGPL, MIT and commercial terms that apply to your build and any modifications.
Check what your identity provider and audit tooling need from each option, and get the support scope in writing before procurement.
Integration points and deployment pattern for mobile analytics
A self-hosted mobile stack touches the app, the ingestion path, the storage layer and the release pipeline. Each card below is a component to confirm with the SDK vendor and your own environment, not a feature we guarantee. Treat them as the checklist to walk through before any SDK ships to an app store.
Ingestion endpoint on a custom domain
Route SDK traffic to a collector hosted on your own domain instead of a vendor default host. This keeps events flowing through infrastructure you operate and reduces the chance that content blockers drop the calls. Confirm the exact host each SDK posts to, whether the hostname is configurable at build time, and how TLS certificates are rotated. Also confirm which SDK versions still reach a self-hosted endpoint after a release, since older app builds may keep calling the previous host.
Masking configuration shipped with each release
Masking rules for mobile screens and inputs travel inside the app binary or its remote configuration, so they must match each build. Confirm where the masking settings are defined, whether they can be changed without an app store review, and how a rule for a new screen is applied. Ask whether the SDK masks by view type, accessibility identifier or both, and whether fields are masked before frames leave the device.
Offline buffering and batch upload
Phones lose connectivity on trains, in basements and on roaming networks, so the SDK queues events and uploads them in batches later. Confirm the maximum queue size, what happens when storage is full, whether events are dropped or kept, and whether an app restart flushes the queue. Test these behaviors per SDK on iOS, Android and React Native, because buffering limits and retry logic differ between platforms and between SDK versions.
Identity linking between mobile and web
A user who signs in on a phone and later on a browser should appear as one person in funnels, otherwise conversion figures split across two profiles. Confirm which identifier the SDKs send, how an anonymous device ID is merged into a known user after login, and whether the merge is applied to replays as well as events. Decide what identifier is allowed to leave the device, since an email address or account number can turn analytics into personal data.
Storage and retention sizing
Replay recordings are much larger than event rows, so storage cost follows session volume and replay length more than event count. Confirm the minimum host specification for your chosen platform, the retention setting you need for each data type, and how deletion runs on expired sessions. Ask for a sizing estimate based on your own monthly sessions and average session length, and check whether backups include replay storage.
CI test of masking after each release
A masking rule that worked in the last build can fail after a redesign, a new form or a library upgrade, and the failure may be invisible until a recording exposes data. Add a pipeline step that runs scripted screens with sample sensitive values, captures the output and fails the build if any test value appears in a recording or network payload. Confirm with your vendor which test hooks the SDK exposes and whether the check can run against a self-hosted collector in a staging environment.
Rollout phases and the output of each
The sequence moves from a data inventory and hosting design through a staging trial, platform-by-platform masking checks and offline testing, into a controlled production cutover and a handover your team can run. Each phase closes with a named deliverable, so you can confirm progress before the next phase starts.
Inventory data and define the event catalog
DeployOpen works with your product, engineering and privacy leads to list the screens, user journeys and events to track on iOS, Android and React Native, and to decide which screens are in replay scope and which are excluded entirely, such as sign-in, payment and health or banking screens. Each event gets a name, owner, purpose and the properties it may carry, with no free-text fields that could hold personal data. The output is a signed event catalog and a replay scope register that lists excluded screens and the reason for each.
Design hosting and network paths
The team maps where the self-hosted OpenReplay or PostHog services will run in your cloud account, data center or private network, how mobile SDKs reach the ingestion endpoint, and how mobile traffic is routed through your own domain. The design also covers storage sizing, backups, access paths for administrators and the boundary between mobile analytics and any third-party SDKs already in the app. The output is an approved architecture diagram and a network and sizing note that your security team has reviewed.
Deploy staging with a test app
DeployOpen installs the chosen platform in a staging environment that mirrors production controls, using the vendor's documented deployment path for your target. A test build of each mobile app, with dummy accounts and synthetic data, sends events and replays so the team can confirm ingestion, dashboards, retention settings and role-based access work end to end. The output is a staging environment with a test log showing events and replays arriving from each platform, and a list of defects resolved before production.
Integrate SDKs and verify masking per platform
Engineers add the SDKs to iOS, Android and React Native builds, configure capture-time masking for sensitive views, and run the test app through every screen in the replay scope. Each platform is checked separately because native views, webviews and cross-platform components mask differently, and a masked field on one platform can be visible on another. The output is a per-platform masking test report with screenshots or recorded evidence showing that sensitive fields never reach the server, plus a sign-off from the privacy lead.
Test offline and poor connectivity behavior
The team tests event buffering on devices that lose network connectivity, switch between Wi-Fi and cellular, enter airplane mode, or are force-quit during a session. The goal is to confirm that events queue locally, flush in order when the connection returns, and do not duplicate or drop data, and that replay upload behaves predictably under a weak connection. The output is an offline test matrix with pass or fail results per device and network condition, and documented limits the product team must know about.
Align store disclosures with legal
Before production, your legal and privacy team compares the events and replay data the app actually collects with the privacy details you declare in the Apple App Store and Google Play Console, including any tracking, identifiers and data types. DeployOpen supplies an accurate inventory from the event catalog and SDK configuration to support that review, but the disclosures are your legal team's decision. The output is a reviewed disclosure statement for each store, a record of who approved it, and a plan for updating it when the SDK or event catalog changes.
Cut over to production and set retention
DeployOpen promotes the tested configuration to production through a change window agreed with your team, switches the SDK endpoints in a new app build, and monitors ingestion, storage and error rates during the first releases. Retention periods, deletion jobs, backup schedules and access roles are set to match the records you documented earlier. The output is a production cutover record, a retention configuration matching the approved policy and a monitored go-live checklist signed by the platform owner.
Hand over operations and runbooks
DeployOpen transfers operating knowledge to your platform and mobile teams through runbooks covering upgrades, SDK version changes, masking regression checks after each app release, backup restores and incident response. Your team is trained on the admin console and on what to re-test when the event catalog or app changes. Support after handover depends on the scope agreed in writing, including whether a retainer for upgrades and continuous testing applies. The output is a signed runbook set, a trained operator list and a support boundary document.
Evidence a privacy or security reviewer will ask for
This table lists the evidence a privacy or security reviewer usually asks for when mobile app analytics and replay are self-hosted, and which component produces each item. Read it as a preparation list: DeployOpen prepares this evidence from your configuration and testing, but it does not issue audit reports, attestations or certifications, which independent auditors and certification bodies provide.
| Evidence item | What the reviewer checks | Component that produces it |
|---|---|---|
| Data flow diagram | Which device data leaves the app, which SDK sends it, and that every endpoint is inside your infrastructure | Your architecture documentation, mapped against the OpenReplay mobile SDK and PostHog SDK configuration |
| Masking test results per release | Passwords, card fields and personal identifiers are masked in native replay on each iOS and Android build | Test scripts run against each app build, with screenshots and replay samples retained by the test team |
| Retention configuration export | Replay and event retention periods match the approved policy for each project | OpenReplay self-managed retention settings or PostHog project retention, exported from the admin console |
| Access logs and role definitions | Who can view replays, which roles exist, and that access to recordings is logged | OpenReplay Enterprise or PostHog platform packages for SSO, audit logs and roles, where licensed; otherwise confirm the built-in controls |
| Records of processing entry | Purpose, data categories, recipients, retention and security measures for app analytics | Your privacy team, drafted from the data flow diagram and retention export |
| Store disclosure answers mapped to SDK behavior | Each App Store and Google Play data answer matches what the SDKs collect and send | Release engineering, checked against SDK versions and the event schema in each build |
| Offline buffer and upload behavior | Queued events and recordings are encrypted or cleared as documented when devices go offline | Mobile SDK configuration and a documented test on a device with the network disabled |
What do teams ask before running mobile analytics on their own servers?
What drives the cost of self-hosted mobile analytics and replay?
The main cost lines are infrastructure, implementation work, ongoing operations and internal staff time. Infrastructure is the cloud or data center spend for the replay and analytics servers, storage and backups, and it grows with session volume and retention. Implementation covers SDK integration in iOS, Android and React Native apps, masking configuration and testing, and identity and access setup. Operations recurs: upgrades, monitoring, backups and on-call. Ask any quote to split one-time work from recurring work, and to state which retention period and event volume it assumes. Note that the OpenReplay Dedicated managed tier starts at $199 per month on AWS, GCP or Azure according to its pricing page, which gives one published reference point for a managed alternative.
How long does it take to get the first mobile replay running?
The timeline depends on how many apps you have, whether the team already runs the server, and how much masking review is required before any recording is allowed. A single app with an existing server is far quicker than a multi-app estate that needs identity integration and a privacy sign-off. OpenReplay's documentation describes a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage as enough to start self-hosting, so the server itself is rarely the constraint. Ask any implementation partner for a fixed-scope timeline in writing, and confirm that it includes a test build with masking verified before production release.
What does our internal team need to provide?
Your team needs to provide cloud or data center access, a named owner for privacy and retention decisions, and engineers who can build and release the iOS, Android and React Native apps. Security should supply the identity provider, network rules and logging standards. Product owners must define the event tracking plan, because most avoidable cost comes from collecting events nobody uses. Legal or privacy staff should confirm consent handling and retention periods for mobile users. Ask a partner to list these inputs in the written scope so gaps are visible before work starts.
Can our own engineers run this without outside help?
Yes, a capable platform team can deploy OpenReplay or PostHog from their public documentation, and both projects publish self-hosting guides. The harder work is the parts that carry risk: capture-time masking for card, balance and health data, SDK configuration in each app build, offline buffering behavior on poor networks, and app store privacy disclosures. Most teams underestimate the testing needed after each front-end or app release. Decide early which of these you will own, and whether you need a retainer for upgrades and continuous testing.
How does PostHog's free self-host differ from paid support?
PostHog's free Docker Compose hobby deployment is MIT licensed and installed with a deploy-hobby script, but its self-host documentation says self-hosted deployments are officially unsupported and that PostHog does not offer customer support for them. Its README points teams that need fully free software to the posthog-foss repository. Premium features in the ee directory require a PostHog license. Its documentation also states that new Kubernetes deployments of its paid self-hosted product are no longer supported. Support, upgrades and incident response for a self-hosted stack therefore have to come from your team or a partner.
At what event volume does self-hosting stop making sense?
PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends moving to PostHog Cloud above that level. PostHog Cloud's pricing page states that the first 1 million analytics events are free every month, so the cost comparison changes sharply once volume is measured. Replay storage adds to this, and OpenReplay's retention settings are the main lever for its cost. Model your monthly events and replayed sessions for each app before choosing, and ask a partner to show how the design scales beyond the hobby tier.
Questions to put to an implementation partner
Start by asking which SDK versions the partner will ship for each platform, and in writing. For iOS, Android and React Native, ask for the exact OpenReplay mobile SDK version and the PostHog SDK version for each app, the minimum OS versions supported, and how the React Native bridge is handled when the native layer changes. Ask who owns the decision to upgrade when a platform vendor changes its rules, and what the partner does when an SDK release lags behind a new OS release. Confirm the answer against the vendor's own release notes, since the supplied facts do not establish SDK version numbers for this topic.
Next, ask how masking is tested after every release. A credible answer names the specific screens that hold card numbers, balances, health data or identifiers, and describes a repeatable test that records a session on a test device, checks that masked fields never reach the server, and runs again after each app build. Ask whether the test covers network payloads and offline buffered events, because data can leave the device through either path. Also ask who signs off the result and where the evidence is stored. Under a fixed-scope engagement, these checks should appear as named deliverables, not as general best effort.
Finally, ask how store disclosures are mapped to SDK behavior and how the scope will be written. Request a table that links each data type in the Apple App Store privacy details and the Google Play Data safety form to the event or replay field that collects it, with the owner of each entry. Ask how offline buffering is verified, including what happens to queued events after a device is offline for days and when the app is force-quit. On licensing, ask the partner to confirm whether the features required sit in the open-source edition or the separately licensed ee/ code, and who holds the license. On support, ask what happens after go-live, since PostHog states that self-hosted deployments are officially unsupported. Insist that scope, deliverables, acceptance tests and any retainer terms are agreed in writing before work starts.
How DeployOpen scopes and supports mobile analytics
This sequence turns a mobile analytics requirement into a written, fixed-scope plan, a self-hosted stack inside your own infrastructure, and an operating model your team can run after go-live. Each step ends with a document or check you can review before the next one starts.
Confirm the apps, platforms and data flows
DeployOpen reviews which iOS, Android and React Native apps are in scope, which web properties must share the same analytics stack, and where events, session recordings and crash-related data would flow today. Your engineering and privacy leads confirm the list of SDKs already in each app and any third-party tools they call. The output is a scope note that names each app, platform version range, data flow and owner, and it closes once your team signs off on it.
Agree the fixed scope in writing
Most engagements are fixed-scope, so DeployOpen drafts deliverables, responsibilities, exclusions and acceptance criteria before any build work begins. The scope covers which platform and edition are being deployed, which mobile SDKs and native replay features are included, the masking rules that apply, and what the client's team will provide. A quote follows from this written scope. The step closes when both parties sign the scope document.
Design the hosting and data boundary
DeployOpen designs the hosting layer inside your cloud account, data center or air-gapped network, including network paths from devices to the ingestion endpoint, storage location, backup approach and access paths for administrators. The design records where each data class lives, which accounts can reach it and how it is isolated from other environments. The output is an architecture document and a data flow diagram that your security and compliance reviewers can check against your own policies.
Configure SDKs, masking and event plans
DeployOpen implements the mobile SDK integration for each app, sets event naming and property standards, and configures capture-time controls for native replay so that sensitive screens and inputs are masked or excluded before data leaves the device. Event buffering for offline use is tested on real device conditions. The output is a tested build for each app, a documented event dictionary and a masking configuration that the product team has reviewed.
Test masking, security and the app store disclosures
DeployOpen runs security testing against the mobile apps and the APIs that receive analytics traffic, checks that masking holds across screens and after front-end releases, and reviews the data each SDK sends so that disclosure statements for the App Store and Google Play match actual behavior. Your privacy lead compares the findings with the disclosure forms. The step closes with a test report, a list of remediated findings and a sign-off on the disclosure wording.
Harden, back up and document the stack
DeployOpen applies the hardening baseline agreed in the scope, configures backups and restore procedures, sets retention and access roles, and writes runbooks for installation, upgrades, incident response and SDK changes. Documentation is written so that your internal team and any compliance assessor can follow the controls and evidence trail. The step closes with a restore test on the backup and a documentation handover package.
Hand over and set the support model
DeployOpen trains the owners on the runbooks, walks through the dashboards and replay review process, and agrees how post-go-live work is handled. Ongoing support, upgrades and continuous testing are available as retainers, which you can compare with keeping the work in-house. The handover closes when your team confirms the runbooks and the support terms are in place and the open items are assigned to named owners.
