Open source product analytics for SaaS companies

Open source product analytics for SaaS companies: why enterprise deals change the build

When an enterprise buyer asks where your usage data and session recordings are stored and who can open them, the answer decides whether the deal moves. Self-hosted PostHog or OpenReplay can keep event and replay data in your own cloud account, so no third-party analytics vendor holds it. The trade-off is that you take on the operations, upgrades, backups and support that a hosted service would otherwise carry. For a SaaS team, that choice is a product decision as much as an infrastructure one, because the same data that improves onboarding can expose one customer's users to another if it is not scoped correctly.

SaaS differs from other sectors in three ways that change the build. First, customer security questionnaires ask about data flows, subprocessors, access reviews and retention, and your answers must match the running system. Second, most data is tenant-level, so events, replays and feature flags need an organization identifier on every record and access rules that prevent staff or one customer's admins from seeing another tenant's activity. Third, session recordings may capture customer users and their data inside your application, so masking has to happen at capture, not later in the viewer. Treat these as requirements to write down before you pick a platform, not as details to fix after the first enterprise review.

On platforms, check licensing before you commit. PostHog's repository is MIT licensed except for the ee/ directory, which needs a PostHog license for premium features on a self-hosted instance. OpenReplay's monorepo is mostly AGPLv3, with some MIT directories and an ee/ directory under a separate commercial license. Map each feature your deal team expects, such as single sign-on, audit trails or role controls, to the license that covers it, and confirm the terms in the current LICENSE files with your legal team. Only then can you say accurately which features are free to run in your own account.

Which SaaS requirements shape the analytics stack

This table maps the main SaaS compliance and contract requirements to the evidence they create for a self-hosted analytics system and the build decisions they force. Read each row as a question to answer before choosing PostHog or OpenReplay, because the answer often decides where the system sits and who signs what.

Requirement	What it asks for	Build impact for the analytics stack
SOC 2 Trust Services Criteria (CC1 to CC9)	Security common criteria apply to every SOC 2 examination. Scope depends on whether the analytics system is inside the defined system boundary.	If the analytics system holds customer personal data or supports in-scope services, document its access controls, change management and logging as part of the system description.
SOC 2 Type 1 versus Type 2	Type 1 describes the system and the suitability of control design as of a date. Type 2 adds an opinion on operating effectiveness over a period.	Expect to show controls working over time for a Type 2, such as access reviews and retention jobs run on schedule, not only a design written once.
GDPR Article 28(3) processor terms	When a vendor or host processes personal data for you, the contract must limit processing to documented instructions, including transfers.	Self-hosting on your own cloud account keeps you as controller of the data path. If a SaaS cloud region or a support engineer touches data, obtain and review the processor terms first.
GDPR Article 32 security of processing	Appropriate technical and organizational measures, such as encryption, access control and resilience, must protect personal data processed.	Plan encryption at rest and in transit, role-based access to replays, backup and restore testing, and masking at capture so raw sensitive input is not stored.
EU Data Act switching rights	Providers of data processing services must let customers switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transitional period.	Choose an export format and keep event schemas documented so you can move data out. Ask any vendor how exports and switching are supported in writing.
Data Act ban on switching charges	From 12 January 2027, providers may not impose any switching charges. Until then, reduced charges may not exceed costs directly linked to switching.	Confirm in writing whether any exit or data export fees apply to your contract before 12 January 2027 and after it, and budget migration work separately from subscription fees.
Cyber Resilience Act reporting (Article 14)	Manufacturers of products with digital elements, including software, must meet reporting obligations for actively exploited vulnerabilities and severe incidents, applicable since 11 September 2026 for in-scope products.	If your SaaS ships software in the EU, map who receives vulnerability reports for any self-hosted component or SDK you distribute, and set a process to notify ENISA and users on time.

Which self-hosted platform fits which SaaS product

PostHog suits SaaS teams that want event tracking, funnels, retention, feature flags, experiments, surveys and session replay in one tool. Its README groups these under analytics, session replay, feature flags and experiments, and data pipelines, so a team can run feature adoption analysis and rollouts from the same data. The open-source core is MIT licensed, but content in the ee/ directory is covered by a separate license.

Core license: The MIT Expat license covers the repository except the ee/ directory, which carries its own license file.
Premium features: Using ee/ features on a self-hosted instance requires a PostHog license. Teams that need fully free software can use the posthog-foss repository, which removes proprietary code and features.
Volume guidance: The README says open-source deployments should scale to about 100k events per month and recommends PostHog Cloud above that.
Kubernetes: The self-host documentation states that new Kubernetes deployments of the paid self-hosted product are no longer supported.
Support: PostHog states that self-hosted deployments are officially unsupported and that it does not offer customer support for them.

Before committing, confirm with PostHog which features your roadmap needs sit in ee/, and plan internal or partner support because vendor support does not cover self-hosted instances.

How to build a tracking plan that enterprise buyers can review

This sequence turns product questions into a tracking plan that security, legal and customer teams can read before any SDK ships. The end result is an approved event dictionary, a property allowlist and a versioned change log that together show exactly what leaves the product.

Map product questions to decisions
Product, growth and customer success leads list the questions the analytics must answer, such as which steps in onboarding lose users, which features retained accounts adopt, and where enterprise accounts stall. Each question is tied to a named decision, owner and metric definition. The step is done when every planned event can be traced back to at least one question, and any event that cannot is dropped before instrumentation begins.
Define events, properties and identities
The analytics lead and an engineer agree on event names in a consistent verb-object format, the properties each event carries, and how users, accounts and workspaces are identified. Identity is decided early: which ID is the person, which is the tenant or account, and whether a distinct ID is ever derived from an email address or name. The output is a draft event dictionary with a definition, owner and trigger for each event.
Classify properties by data sensitivity
Security and privacy reviewers label every proposed property as public product metadata, internal operational data, pseudonymous identifier or prohibited content. Free-text fields, document names, message bodies, search queries, uploaded file names and any customer-entered values are marked as never sent. Reviewers confirm that the classification matches the data processing terms the company gives its customers. The step closes when each property carries one label and the prohibited list is signed off.
Pseudonymize tenant and account identifiers
Engineering replaces raw tenant and account IDs with keyed hashes or internally generated surrogate IDs before they reach the analytics server, so an analytics export cannot reveal a customer's identity on its own. The key is stored in the company's secret management system and rotated under a documented procedure. Engineering also confirms which systems can reverse the mapping and who can access them. The check is a test event inspected in the self-hosted instance that contains no raw tenant identifier.
Approve the property allowlist
The approved properties are converted into an allowlist that the SDK or ingestion layer enforces, with anything outside it dropped or rejected. Reviewers check the allowlist against the event dictionary and against the list of prohibited content categories. Where the platform supports it, the team confirms the allowlist is enforced at capture rather than only in dashboards. The output is a signed allowlist file kept in version control, with a named approver for each change.
Map events to funnels, retention and adoption
Analysts build the funnel, retention cohort and feature adoption definitions from the approved events and write each one as a short specification listing its start event, end event, time window and segment property. This shows whether every metric can be computed from allowlisted fields alone. Any metric that needs a field outside the allowlist goes back to step three. The step closes when each planned dashboard maps to documented events.
Version the plan and log every change
The event dictionary, allowlist and metric specifications are stored in a repository with a version number and a dated change log. Each entry records what changed, why, who approved it and which releases carry it. Changes to identifiers, retention or new sensitive categories trigger a fresh privacy review. The output is a plan that a customer's security team can read, compare across releases and trace from a live event back to its approval.

Deployment patterns for SaaS: single VM, Kubernetes, or bring-your-own-cloud

Each deployment pattern changes who operates the analytics stack, how much event volume it can carry, and whether customer data stays inside your boundary. The cards below cover the starting point, the Kubernetes route, the managed alternative and the configuration choices that apply to any pattern. Confirm each choice against current vendor documentation before you commit.

Single VM start with OpenReplay

OpenReplay's README says a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to begin self-hosting. That fits a pilot on one product, not a multi-product SaaS estate with enterprise customers watching data flows. Ask the vendor how storage grows with session volume and retention settings, and plan a second environment before production traffic arrives. Confirm the sizing against the current deployment documentation.

Hobby Docker Compose for PostHog

PostHog's self-host documentation offers a free Docker Compose hobby deployment under the MIT license, installed with a deploy-hobby script. The same documentation recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. Treat this as a development or evaluation footprint. PostHog states that self-hosted deployments are officially unsupported, so your team carries the operations burden.

Kubernetes with Helm for OpenReplay

OpenReplay lists Kubernetes with Helm among its supported deployment targets, which suits SaaS teams that already run clusters and want standard upgrade and rollback tooling. The trade-off is that your platform team owns storage classes, ingress, backups and capacity planning for session data. Confirm the supported Helm chart version, the Kubernetes versions it targets and the upgrade path from your current release before you commit to this route.

PostHog Kubernetes deprecation for paid self-hosting

PostHog's self-host documentation states that new Kubernetes deployments of its paid self-hosted product are no longer supported. A SaaS team that planned a paid PostHog self-hosted cluster on Kubernetes needs to revisit that design early. Ask the vendor which deployment options remain for paid self-hosting, whether existing Kubernetes installs are affected, and which features in the ee directory require a PostHog license.

First-party domain for tracking

OpenReplay's README notes that first-party tracking served from your own domain is not blocked by ad blockers, which matters when product analytics feeds decisions about onboarding and activation. Route the ingestion endpoint through a subdomain you control, then test that SDK requests reach your collector in each browser and with common blockers enabled. Document the subdomain and DNS records as part of your data flow inventory.

Separate production and staging projects

Keep staging and production events in separate projects or instances so that test traffic, synthetic accounts and replay recordings from pre-release builds never mix with customer behavior data. This separation also keeps retention and access rules distinct for each environment. Ask your implementation partner how project permissions and API keys are scoped per environment, and confirm which project-level controls your chosen edition provides.

OpenReplay Bring-Your-Own-Cloud option

OpenReplay's README lists Bring-Your-Own-Cloud on AWS, GCP or Azure as a managed alternative, alongside Serverless and Dedicated options. It can reduce operations work while the data stays in a cloud account you control. Ask who holds the cloud account, who can access the data plane, how upgrades are applied, and where backups and logs are stored. Compare this option with self-hosting on your own infrastructure before choosing.

When event volume makes self-hosting stop being practical

At what event volume does PostHog recommend moving to PostHog Cloud?

PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends moving to PostHog Cloud above that level. Treat 100k as a planning threshold, not a hard limit. Your real ceiling depends on the hardware, the ClickHouse sizing and how many events each user generates. Measure your current monthly event count across all projects and add the growth you expect over the next 12 months before you decide. Ask your implementation partner to load test with your own event schema, because event size and property count change the result more than the raw count.

How does PostHog Cloud's free first million events change the comparison?

PostHog's pricing page states that the first 1 million analytics events are free every month. For a team below that level, the subscription line in a build-versus-SaaS comparison is zero, so the self-hosted option has to justify itself on data control, licensing or residency rather than on fees. Above that level, the comparison moves to per-event charges against your infrastructure, staff time and support. The Free plan includes 1 project and 1-year data retention, while the Pay-as-you-go plan raises this to 6 projects and 7-year retention. Compare those retention periods with your own policy before you assume the free tier covers your needs.

How do OpenReplay storage and retention settings affect disk growth?

Disk growth in a self-hosted OpenReplay instance follows three levers: how many sessions you record, how much of each session you capture, and how long you keep recordings. The README says a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to start, which is a starting point for evaluation, not a sizing for production traffic. Sampling rates, masking choices and retention windows are the settings to model. Shorter retention caps the total stored volume, while longer retention multiplies it. Ask your partner for a storage model based on your session volume, average session length and retention policy, and rerun it after each release that changes capture behavior.

When should a SaaS team add a warehouse-based analytics design?

Add a warehouse-based design when product events must be joined with billing, CRM or support data, when several teams need the same metrics in SQL, or when the event volume outgrows a single self-hosted analytics database. In that design, events are collected through an open-source pipeline into a warehouse such as ClickHouse or PostgreSQL, and funnels and retention are modeled in SQL. This adds components to operate, including the pipeline, the warehouse, the dashboard layer and the access controls on each. It is a larger build than running PostHog or OpenReplay alone, so decide on the business requirement first. Confirm the design with your engineering and data teams before any engagement is scoped.

What does migrating from Mixpanel or Amplitude into PostHog involve?

A migration from Mixpanel or Amplitude involves four constraints you should plan for:

Each direct import job covers at most one year of historical data, so older history needs several jobs.
Events are not deduplicated, so re-running an import can create duplicate records.
Once events are imported, there is no way to selectively delete event data.
A paid product analytics plan is required to unlock the import features, although historical imports sent with the historical_migration flag are free of ingestion fees.

Also check which source fields map to PostHog properties before you start. Ask your partner for a written migration plan that covers the dry run, the deduplication approach and the sign-off on what is loaded.

Does the self-hosted PostHog free edition come with vendor support?

No. PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support for product, infrastructure or other questions on self-hosted instances. Teams running the MIT-licensed Docker Compose hobby deployment or a larger installation therefore need their own operations capability, or a partner under a written support agreement. Ask any partner what happens during an upgrade, a failed ingestion job and a storage incident, who is on call and what the response expectations are. Confirm that the scope of support is written into the agreement rather than assumed.

Which PostHog features require a license on a self-hosted instance?

PostHog's README states that using premium features from the ee directory on a self-hosted instance requires a PostHog license. The core repository is under the MIT Expat license, but content in ee/ is covered by a separate license. If you need fully free software, PostHog points teams to the posthog-foss repository, which is purged of proprietary code and features. Before you commit to a feature set, list every capability you need, such as SSO, audit logs or custom roles, and check each against the license terms. PostHog's pricing page notes that SSO, audit logs, custom roles and project permissions are sold as platform packages, so confirm these with your legal and procurement teams.

Can DeployOpen run self-hosted analytics at higher event volumes?

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. That work can cover the sizing, deployment, storage and retention configuration, backup and upgrade planning for analytics stacks at larger volumes. Engagements are generally fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. DeployOpen does not publish a price list, so the quote follows from the written scope. Ask for a scope that states the expected event volume, the retention policy and the hosting model.

Migrating historical data from Mixpanel, Amplitude or Heap without losing trust

Before anyone imports history, settle three decisions in writing: whether duplicate events matter for your retention metrics, whether the import should carry the historical_migration flag, and how you will document the source and date range for auditors. PostHog's managed migrations pull historical events directly from Mixpanel or Amplitude using API credentials, or from JSONL files in an S3 bucket. Each direct import job covers at most one year of data, and events are not deduplicated. If your team has been sending the same events through both the old tool and PostHog during a parallel run, the overlap will inflate counts and distort cohort retention curves unless you filter it out before the import. Confirm the exact date boundary between the old and new pipelines so the two datasets meet cleanly.

The historical_migration flag matters for cost and for reporting. PostHog's migration documentation says historical imports sent with this flag are free of ingestion fees, but a paid product analytics plan is still required to unlock the import features. Ask your vendor or partner to confirm current plan terms in writing before you schedule jobs, because the cost of a multi-year history depends on how many one-year jobs you need. Tag every imported batch with its source tool, export date and date range, and keep the export job logs. Auditors reviewing a SOC 2 or data protection assessment will ask where analytics data came from and whether it was complete, and a dated source record answers that question far better than a memory of the project.

The step that cannot be reversed is deletion. PostHog's documentation states there is no way to selectively delete event data once it has been imported, so you cannot later remove one user's events or trim a bad batch without affecting the rest. Therefore, set your retention period, your erasure process for data subject requests and your rules for which properties may be sent before the first import runs. Strip or hash identifiers and free-text fields that you would not want to keep for years, and test the mapping on a small date range first. If the historical data includes events from users who later asked for erasure, decide now whether you will exclude them from the import, because you will not be able to remove them afterward.

Evidence enterprise customers and auditors ask for

This table maps each piece of evidence that enterprise buyers and SOC 2 auditors typically request to what it proves and the platform or process component that produces it. Use it to plan evidence collection before a security questionnaire arrives. Your auditor decides which items fall in scope, and DeployOpen prepares the evidence without issuing any report.

Evidence item	What it proves	Component that produces it
Access logs for analytics and replay consoles	Who viewed or exported recordings and events, and when	Platform audit logs, reverse proxy logs, retained in a central log store
SSO and role configuration export	Only approved staff can sign in, and access follows job roles	Identity provider configuration, SCIM or role mappings, the enterprise edition permissions model
Retention settings and deletion records	Recordings and events are deleted on the documented schedule	Platform retention configuration, scheduled cleanup job logs, storage lifecycle rules
Masking test results	Passwords, card data and personal fields are excluded before data leaves the browser	Automated masking tests run after each front-end release, with saved selector and payload samples
Tracking plan change records	Every event and property was reviewed and approved before it went live	Version-controlled tracking plan, pull request approvals, release notes
Data processing agreement and sub-processor list	Contractual terms bind each processor to documented instructions and security measures	Signed agreements with cloud providers, SDK vendors and any managed support provider
Architecture diagram and data flow map	Where events and recordings are stored, processed and which regions they touch	Current deployment diagram, network boundaries, third-party script inventory
Backup and restore test records	Analytics data can be recovered and the restore procedure works as documented	Backup job reports, dated restore test logs, recovery time notes from each test
Vendor license records for enterprise features	Licensed features in use match the license terms for the self-hosted instance	License file review, purchase records and a list of ee/ directory features enabled

How a SaaS team rolls out self-hosted analytics in phases

The sequence moves from requirements and licence review to a hosted, masked and validated analytics stack that customers can audit, then into a supported run state. Each phase closes with a written output the team can check before the next one starts.

Scope requirements and agree the fixed scope
The SaaS product, data and security leads list the events, funnels, retention questions and feature adoption metrics the business needs, along with the questions enterprise buyers ask about data location. DeployOpen maps these to a written scope with deliverables, exclusions and a timeline, and nothing starts until both sides sign it. The output is a signed scope document and a requirements list that names the owner of each decision.
Choose the platform and check the licence
The team compares PostHog and OpenReplay against the requirements, including product analytics, session replay and mobile needs. PostHog's README states that premium features in its ee directory need a PostHog license on a self-hosted instance, and OpenReplay's enterprise code sits under a separate commercial license, so the licence review confirms which features the company can run without a paid agreement. The output is a platform and edition decision record signed by legal and engineering.
Build the hosting in your cloud account
DeployOpen provisions the analytics stack inside the company's own cloud account, data center or private network, with access controls, network boundaries, backups and logging set to the company's standards. Sizing follows the vendor's published guidance and the expected event volume, and the team confirms it with the vendor where documentation is unclear. The output is a documented environment with an architecture diagram, access list and a tested backup restore.
Write the tracking plan and masking rules
Product, engineering and privacy stakeholders agree on each event name, its properties and its owner, and they mark which fields can never be sent, such as account identifiers, free-text inputs and payment data. DeployOpen configures capture-time masking by CSS selector, input redaction and any private-by-default settings, and sets retention periods per data type. The output is an approved tracking plan and a masking configuration that matches it line by line.
Validate tracking and masking in staging
Engineers instrument the staging application against the tracking plan and check that events arrive with the right properties and that masked fields never reach the server. Test cases are repeated after each front-end release, because a new form or component can expose data that the earlier configuration did not cover. The output is a test report listing each masking case, its result and the owner who signed it off.
Cut over to production on a first-party domain
The team switches the production application to the self-hosted endpoint served from its own domain, which reduces the chance that ad blockers stop collection, as OpenReplay's README notes for first-party tracking. DeployOpen runs the cutover with a rollback plan, monitors ingestion and confirms that no third-party analytics script remains on pages that handle sensitive data. The output is a cutover record showing live event flow, the rollback steps and the removed scripts.
Assemble the enterprise evidence pack
Enterprise buyers and their security reviewers ask where data is stored, who can access it, how masking works and how long data is kept. DeployOpen assembles architecture documents, access reviews, masking test results, retention settings, backup records and the processor terms the company will offer customers. Independent auditors and certification bodies, not DeployOpen, decide what any assessment concludes. The output is a versioned evidence pack the company can share under its own confidentiality terms.
Move into run-state support
After go-live, the company chooses whether to run the stack internally or to add a support retainer covering upgrades, monitoring, backups and masking regression testing after releases. Self-hosted PostHog deployments are officially unsupported by PostHog itself, so the support model must be agreed in writing with whoever carries the operational responsibility. The output is a run book, an agreed support model and a named owner for each upgrade and incident path.

What to ask an implementation partner before signing

Start by asking the partner to map every feature in your planned build to a license before any work begins. The PostHog repository places content in the ee/ directory under a separate license, and its README says premium ee features on a self-hosted instance require a PostHog license. OpenReplay similarly covers its ee/ directory under a commercial license defined in ee/LICENSE. Ask for a written list of which modules, SSO, audit logs, roles or permissions you would touch, which license governs each, and whether the open-source edition (or the posthog-foss repository) covers your requirements. Ask who carries the license cost and who signs for it.

Ask how masking will be tested after every front-end release, not only at go-live. Ask for the selectors or fields covered by capture-time masking (CSS selector masking, input redaction and private mode in OpenReplay), the test cases used to prove that card fields, account identifiers and customer names never reach the server, and whether those tests run in your release pipeline. Then ask who supports the stack after go-live. PostHog states that self-hosted deployments are officially unsupported and that it does not provide customer support for infrastructure questions on them, so confirm the partner's support hours, upgrade method, incident response path and retainer terms in writing.

For SaaS tenants, ask how access to customer event and replay data is restricted: which roles can view recordings, how tenant data is separated, how access is logged and reviewed, and who at the partner can reach production data. Ask for the evidence pack they deliver, such as system descriptions, access reviews, change records and test results, and confirm that it is prepared for your auditor rather than issued by the partner. Finally, ask how the fixed scope is written, including what is excluded, and how the exit path works. Under the EU Data Act, providers must allow switching to another provider or to on-premises infrastructure, and from 12 January 2027 switching charges are prohibited, so require the partner to describe the export format and migration steps. Ask for references from SaaS tenant deployments, and confirm them directly.

What self-hosted SaaS product analytics costs and what it needs from your team

What does self-hosted product analytics cost a SaaS company?

The cost has four parts: infrastructure, implementation, support and internal staff time. Software licensing is often zero for the community editions, but the Enterprise features that enterprise buyers ask about are sold separately. PostHog states that SSO, audit logs, custom roles and project permissions are sold as platform packages, and OpenReplay lists SSO and SAML, SCIM provisioning, roles, audit trail and a custom SLA under its self-hosted Enterprise edition at custom pricing. Infrastructure is paid to your cloud provider and recurs monthly. Implementation is a one-time fee for scope, setup and hardening, quoted from a written scope. Support and internal time recur. Ask each vendor for the license terms for the features you need before you compare totals.

Which product analytics costs are one-time and which recur?

One-time costs include the event tracking plan, SDK integration, masking configuration, migration of historical data, security review and initial hardening. Recurring costs include servers, storage, backups, upgrades, monitoring, on-call coverage, license renewals and the time engineers spend on dashboards and new events. Self-hosted community software receives no vendor support, since PostHog states that self-hosted deployments are officially unsupported and it does not offer customer support for infrastructure questions on them. That makes the recurring operations line the one most often underestimated. Ask any quote to split one-time and recurring amounts in separate lines so you can compare it with a managed subscription over several years.

What drives the cost of self-hosted analytics up or down?

Event volume, session replay volume, retention and the number of environments matter most. PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends its cloud above that. Its self-host documentation recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage for the hobby deployment, and OpenReplay says a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to start. Retention drives storage cost directly: PostHog's Free plan lists 1-year retention, and self-hosted retention is set by you. Session replay consumes far more storage than event tracking, so separate its retention from product events. Ask for sizing assumptions in writing, with events per month, replay minutes and retention days.

How long does a self-hosted product analytics rollout take?

Duration depends on the number of products instrumented, the existing tracking debt and how much of the stack is in your own accounts. A basic install on a test host can be quick, but a production rollout includes tracking plan agreement, SDK work in each front end and mobile app, masking tests, access setup, backup and monitoring. Migration from Mixpanel or Amplitude adds time, because PostHog's managed migrations import at most one year of data per direct import job and events are not deduplicated. We do not publish a fixed timeline. Ask for a written scope with phases, dependencies on your release calendar and the acceptance criteria for each phase.

Can an in-house team run self-hosted product analytics alone?

A capable platform team can run it alone if it has time, production operations experience and clear ownership. The harder part is not the first install but the ongoing work: upgrades across releases, storage growth, backup restore tests, incident response and keeping masking rules correct after front-end changes. OpenReplay publishes its latest release as v1.28, published on September 25, 2025, so you should plan a regular upgrade cycle and check the release notes each time. Many teams split the work: an implementation partner delivers the initial build and runbooks, and the internal team owns daily operations. Decide which side owns each task before you choose the platform.

What does self-hosted analytics need from engineering and security teams?

Engineering owns the tracking plan, SDK integration, event naming, feature flags for rollout and the infrastructure code. Security owns the data classification, capture-time masking rules, access roles, encryption, logging and vendor and sub-processor review. Both teams should agree on what is never collected, such as form inputs, identifiers and payload data. Under GDPR Article 28(3), if a third party processes personal data on your behalf, the contract must bind it to documented instructions and Article 32 security measures. Self-hosting keeps that processing in your own infrastructure, but your records of processing and your data protection impact review still need the same evidence. Ask any partner which deliverables, such as masking tests and runbooks, will be handed to your staff.

When do the EU Data Act switching rules matter for exit planning?

They matter when you plan to change platforms or move the analytics stack to on-premises infrastructure. Under the EU Data Act, Regulation (EU) 2023/2854, which has applied since 12 September 2025, data processing service providers must let customers switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transitional period. From 12 January 2027, providers may not impose any switching charges. These rules govern commercial data processing services, so they apply to a managed analytics subscription you may leave, not to open-source software you run yourself. Build exit planning into the design anyway: keep your event schema documented, export procedures tested and data retention defined. Ask your vendor whether it is a data processing service in scope before you rely on these rules.

What should a quote for self-hosted analytics include?

A usable quote lists the written scope, deliverables, acceptance criteria and exclusions, with each line marked as one-time or recurring. It should name the products covered, such as PostHog or OpenReplay and their editions, the hosting account, the number of environments, the event and replay volume assumed, the retention periods and the migration sources. It should also state support terms after go-live, handover documents, and who holds credentials and backups. DeployOpen works on fixed scope agreed in writing before work starts, and does not publish a price list, so the quote follows from that scope. Ask any partner to show how each assumption changes the price.

How DeployOpen works on this

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted analytics inside your own cloud accounts, data centers or air-gapped networks. For SaaS product teams, that means event tracking, funnels, retention and session replay run on infrastructure you control, with a written scope agreed before work starts.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
The written scope covers the event tracking plan, funnels, retention views and feature adoption reports you need
Scope also records the hosting target, edition choice and where session data is stored and who can access it

How we build

We deploy PostHog or OpenReplay in your own environment and configure event schemas and identity handling
Session replay capture settings are tested for masking and input redaction before recordings are enabled
We integrate the analytics stack with your product, SSO requirements and existing data flows as the scope defines

How we hand over

You receive documentation of the deployed architecture, event catalog, masking configuration and access model
Runbooks cover backups, upgrades, retention settings and the steps for adding a new tracked feature
Compliance evidence is prepared for your own assessors, which DeployOpen does not issue or certify

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after go-live
Retainers can cover version upgrades, masking regression checks after front-end releases and capacity reviews
Ask us to confirm response terms and which components sit inside the retainer before signing