PostHog vs OpenReplay: which fits your session replay plan
If your team needs session replay on its own infrastructure and nothing else from an analytics product, OpenReplay is the narrower fit. It is built around replay, DevTools with network activity and console logs, cobrowsing with WebRTC calls, and native mobile replay for iOS, Android and React Native. Its README says a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to start self-hosting, and it lists capture-time sanitization that masks or skips data before it reaches the server. Choose it when support engineers and product teams mainly need to watch sessions, debug with devtools data and assist users live, and when you want a clear boundary around what leaves the browser.
If you also need funnels, trends, retention, feature flags, experiments or surveys alongside replay, PostHog is the broader suite. Its repository is MIT licensed except for the ee/ directory, which carries a separate license, and its README points teams that need fully free software to the posthog-foss repository. Be aware that premium features from ee/ on a self-hosted instance require a PostHog license. PostHog's self-host documentation also states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support for product or infrastructure questions on self-hosted instances. Confirm with PostHog which features you would depend on and whether they sit in ee/ before you design around them.
The decision turns on three checks. First, license scope: OpenReplay's README says most of its monorepo is AGPLv3, some directories are MIT, and everything under ee/ is under a commercial license, so map which components you will run and which Enterprise features you need. Second, analytics breadth: list the questions your team must answer beyond replay before you accept a second tool. Third, who supports the install. Neither vendor's self-hosted path comes with the operating support you may expect from a managed service, so decide whether an internal platform team, a paid support tier or an implementation partner will own upgrades, backups and incidents. Ask each vendor, in writing, what support they provide for your deployment model.
Which platform fits which scenario
This table maps common team situations to the platform that usually fits better, with the condition that makes each choice hold. Read each row against your own traffic, licensing rules and support requirements before deciding. The main takeaway is that OpenReplay is the narrower replay specialist, while PostHog is the broader analytics suite whose self-hosted path is limited.
| Scenario | Better fit | Why and the condition that holds it |
|---|---|---|
| Replay plus funnels and feature flags in one tool | PostHog | PostHog combines session replay with product analytics, feature flags, experiments and surveys. This holds if you want one tool and can run it on PostHog Cloud or accept the licensing terms of the ee directory. |
| Devtools, network logs and cobrowsing | OpenReplay | OpenReplay's README lists DevTools with network activity, console logs, JavaScript errors and cobrowsing with WebRTC calls. Confirm the depth of each feature in your own environment before committing. |
| Native mobile replay for iOS, Android and React Native | OpenReplay | OpenReplay's README lists native mobile replay across these three targets. If mobile replay is central, verify PostHog's mobile coverage against your app stack. |
| Expected high event volume | OpenReplay | PostHog's README says open-source deployments should scale to about 100k events per month and recommends moving to PostHog Cloud above that. Validate your own volume and sizing with each vendor. |
| Self-hosting with vendor-backed support | OpenReplay | OpenReplay offers a self-hosted Enterprise edition with custom pricing, a custom SLA and dedicated support. PostHog states that self-hosted deployments are officially unsupported, so choose PostHog self-hosting only if your team can carry the operational load alone. |
| Keeping all session data on your own infrastructure | OpenReplay | OpenReplay's README notes that self-hosting keeps session data in your infrastructure and that first-party tracking is not blocked by ad blockers. Confirm PostHog's self-hosted data path if you pick it. |
| A permissive license for the core product | PostHog | The PostHog repository is MIT outside the ee directory, and a posthog-foss repository exists for fully free software. This holds only if the premium features you need are not in ee, since those require a PostHog license. |
| Strong licensing terms for the replay core | OpenReplay | Most of OpenReplay's monorepo is AGPLv3, with some MIT directories and a commercial ee license. Review AGPLv3 network-use obligations with counsel before offering modified versions to users. |
How each platform is built and what that means for operations
Both platforms can be self-hosted, but they ask for very different operating models. OpenReplay offers a documented single-VM start and a Kubernetes path, while PostHog's free self-hosted route is a Docker Compose hobby install that PostHog does not support. The cards below set out what each deployment means for upgrades, monitoring and on-call effort.
OpenReplay single VM start
OpenReplay's README says a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to start self-hosting. That sizing is a starting point for a pilot or a low-volume site, not a capacity guarantee. Ask OpenReplay or your own load tests how storage grows with session volume and retention, because replay data is the component most likely to fill the disk. Plan disk alerts and a tested backup routine from day one, since a single VM is also a single point of failure.
OpenReplay Kubernetes and Helm path
For teams that already run clusters, OpenReplay lists Kubernetes with Helm as a deployment target alongside Docker and Ubuntu. Choosing this path moves the operating burden into your platform team's existing tooling for upgrades, node sizing, persistent volumes and rollback. Confirm with OpenReplay which chart version matches each release and how database and object storage migrations are handled during an upgrade. Your on-call runbooks should cover the cluster layer, not only the application.
PostHog hobby Docker Compose install
PostHog's free self-host option is a Docker Compose hobby deployment under the MIT license, installed with a deploy-hobby script. PostHog recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. Because the hobby install is officially unsupported, your team owns every upgrade, backup, restore and monitoring task. Document who runs the deploy-hobby script on each release and how you will roll back if an upgrade fails.
PostHog Kubernetes change 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 team that expected to run PostHog on its own cluster with vendor-backed charts should confirm this restriction before any design work starts. If a Compose-based install is the only supported route for new paid self-hosting, your platform team will need to decide whether a VM-based layout fits its standards. Ask PostHog in writing which self-hosted options are currently available to your organization.
Upgrades, monitoring and on-call effort
Under OpenReplay, your team operates the stack you choose, with community support on the open-source edition and dedicated support only on the paid Enterprise edition. Under PostHog's free hobby path, there is no vendor support for infrastructure questions, so every failed migration or outage routes to your own engineers. In both cases, set up uptime checks on the ingestion endpoint, watch disk usage on replay storage, and test restores before you need them. The effort is the same kind of work on both sides, but the escalation path differs.
Capabilities, licensing and privacy controls side by side
This table compares what each platform documents for session replay, developer tools, product analytics, cobrowsing, mobile, privacy controls and first-party tracking. Where a row shows a dash or says to confirm, the supplied material does not establish that capability, so verify it in a trial before relying on it.
| Capability | PostHog | OpenReplay |
|---|---|---|
| Session replay | Included as one product in a wider suite that also covers analytics, feature flags, surveys and data pipelines | Core product, with session replay as the central use case alongside DevTools and product analytics |
| DevTools, network and console logs | Confirm the depth of network and console capture against your own environment, since this was not covered in the supplied material | Documented: DevTools with network activity, console logs, JavaScript errors and more than 40 performance metrics |
| Product analytics | Core suite capability, covering product analytics and web analytics alongside replay | Documented: funnels, trends, journeys and heatmaps |
| Cobrowsing with WebRTC | Confirm before assuming availability; not listed in the supplied material | Documented: cobrowsing with WebRTC calls |
| Native mobile replay | Confirm mobile SDK coverage for your platforms; not listed in the supplied material | Documented: native replay for iOS, Android and React Native |
| Capture-time sanitization | Confirm masking and redaction options in the current SDK documentation before deployment | Documented: masks or skips data before it reaches the server, including CSS selector masking and input redaction |
| Private mode | Confirm an equivalent mode exists; not listed in the supplied material | Documented: masks all text and inputs by default |
| Feature flags and surveys | Documented: feature flags and surveys are part of the product suite | Not part of the supplied OpenReplay feature list, so confirm if your team needs them |
| First-party tracking and licensing | Hosting from your own domain is possible, but confirm the setup for first-party collection; licensing is MIT outside the ee directory, with ee features under a PostHog license | Self-hosting keeps session data in your infrastructure and first-party tracking is not blocked by ad blockers; AGPLv3 for most of the monorepo, commercial license for ee directory |
What is free, what is licensed and what is paid
PostHog's repository is licensed under the MIT Expat license, but the content in its ee/ directory falls under a separate license defined in ee/LICENSE. The split matters because the bulk of the product is MIT, while premium capabilities live in the directory with different terms. The PostHog README states that running premium features from ee/ on a self-hosted instance requires a PostHog license. Teams that need fully free software can look at the posthog-foss repository, which the README describes as purged of all proprietary code and features.
- MIT outside ee/: Code outside the ee/ directory is available under the MIT Expat license, so you can use, modify and redistribute it under those terms.
- Premium ee/ features: Using premium features from ee/ on a self-hosted instance requires a PostHog license, which is a commercial matter separate from the MIT code.
- posthog-foss for fully free code: The posthog-foss repository is described as stripped of all proprietary code and features, which is the path if you need an entirely free codebase.
- Confirm the feature map: Ask PostHog which specific features sit in ee/, because the boundary is set by the directory, not by the product name.
Before you standardize on any self-hosted build, have counsel read ee/LICENSE and the README statement on premium features, and confirm in writing which features your deployment would touch.
PostHog sells its hosted product in tiers, and some governance controls are not part of the open code path. PostHog's pricing page says SSO, audit logs, custom roles and project permissions are sold as platform packages on PostHog Cloud. 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 data retention. The first 1 million analytics events are free every month, so cost begins to matter once volumes grow.
- Platform packages on Cloud: SSO, audit logs, custom roles and project permissions are sold as platform packages rather than included in the free tier.
- Free plan limits: The Free plan includes 1 project and 1-year data retention.
- Pay-as-you-go limits: The Pay-as-you-go plan raises the allowance to 6 projects and 7-year data retention.
- Free event allowance: The first 1 million analytics events are free every month.
Check which package includes the identity and audit controls your auditors expect, and ask PostHog for the current price for the volume you forecast, because the pricing page is the only source for these tier details.
OpenReplay's README states that most of its monorepo is licensed under AGPLv3, that some directories are MIT, and that everything under ee/ (the Enterprise Edition) is governed by a separate commercial license defined in ee/LICENSE. Because AGPLv3 carries network-use obligations, the license choice affects how you can run and modify a modified version as a service. Reading the directory-level license map is the first step before you build internal processes on the code.
- AGPLv3 for most of the monorepo: Most code is under AGPLv3, which applies source obligations when you run a modified version for others over a network.
- MIT in some directories: Certain directories are MIT, so their terms are more permissive than the AGPL portions.
- Commercial ee/LICENSE: Everything in ee/ is under a separate commercial license, which is distinct from the AGPL and MIT code.
- Map the directories: Identify which directories your deployment and any custom changes will touch, since each carries different terms.
Have counsel review the AGPLv3 obligations and the ee/LICENSE terms against how your organization plans to modify and host OpenReplay.
OpenReplay offers a free open-source edition that is self-hosted with community support and self-managed retention. Its pricing page lists OpenReplay Dedicated as a fully managed instance starting at $199 per month on AWS, GCP or Azure with a 7-day trial. A self-hosted Enterprise edition is available at custom pricing on multi-year contracts. The paid Enterprise tier adds controls that many regulated teams need, but these features are not part of the free open-source edition.
- Open-source edition: Free to self-host, with community support and self-managed retention.
- Dedicated managed instance: Listed on the pricing page at $199 per month on AWS, GCP or Azure, with a 7-day trial.
- Enterprise controls: SSO and SAML, SCIM provisioning, roles and permissions, audit trail and a custom SLA with dedicated support.
- Enterprise pricing: Custom, on multi-year contracts, so the cost depends on the written scope and term.
Ask OpenReplay which controls ship in the edition you quote, and confirm whether the Enterprise terms cover the SLA and support levels your procurement team requires.
Both vendors separate free software from paid features, but the cost structure differs. With PostHog, the open code is free, while premium ee/ features and hosted platform packages carry license or subscription costs. With OpenReplay, the open-source edition is free to run, while managed Dedicated, Serverless or Bring-Your-Own-Cloud options and the Enterprise edition add vendor fees. In both cases, you still pay for the infrastructure you run and the staff who operate it, which the license does not cover.
- One-time versus recurring: Licenses and subscriptions recur, while implementation, migration and hardening work is usually one-time.
- Infrastructure stays with you: Self-hosting moves compute, storage and backup costs into your own cloud or data center accounts.
- Support is separate: PostHog states it does not provide customer support for self-hosted instances, and OpenReplay's community support differs from its Enterprise support.
- What drives cost up: Event or session volume, retention length, number of projects and the number of premium features you enable.
When you request quotes, ask each vendor to itemize license fees, support, retention and volume tiers, and ask DeployOpen to price implementation and retained support from a written scope.
What drives the running cost of each option
Both self-hosted paths cost the same kind of things: hardware, storage that grows with volume, and engineer hours to operate and upgrade. The managed and vendor-supported options swap some of those costs for subscription fees, so the quote you request should price each line on the same basis.
Infrastructure sizing at the start
OpenReplay's README says a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to start self-hosting. PostHog's self-host documentation recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage for its hobby deployment. Both figures are starting points, not capacity plans. Ask each vendor what changes at your expected session and event volume, and budget the server as a recurring line item, not a one-time purchase.
Storage growth with replay volume
Session replay is the cost driver most teams underestimate, because storage grows with every recorded session and not with the number of users. Replay data is heavier than event data, so a site with heavy traffic and long retention needs much more disk than a product analytics count suggests. Retention is set by you on self-hosted OpenReplay and is a plan limit on PostHog Cloud. Model storage with your real session count and retention period before you pick a server size.
Event volume and the scale threshold
PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends migrating to PostHog Cloud above that. That threshold sets a practical ceiling on the self-hosted PostHog path. If your analytics and replay volume is already past it, the infrastructure and engineering cost of staying self-hosted rises quickly. Ask PostHog how it sizes a self-hosted instance for your event count, and treat the 100k figure as a planning boundary, not a performance guarantee.
Engineering time to operate and upgrade
Operating either platform means someone patches the host, rotates certificates, watches disk and backs up data, then performs each upgrade. PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that new Kubernetes deployments of its paid self-hosted product are no longer supported. OpenReplay's self-hosted route is also community-supported at the open-source tier. Estimate the engineering hours per month and per upgrade cycle yourself, or with a partner against a written scope, because neither vendor's documentation supplies a figure for this.
Support options and what they cost
Both self-hosted paths rest on community support in their open-source editions. OpenReplay's self-hosted Enterprise edition adds SSO and SAML, SCIM, roles, audit trail, a custom SLA and dedicated support at custom pricing on multi-year contracts. PostHog sells SSO, audit logs, custom roles and project permissions as platform packages, and states it does not provide customer support for self-hosted infrastructure. Ask each vendor for the exact support hours, response targets and what is excluded in writing before you compare the two.
Managed options and their limits
OpenReplay Dedicated is a fully managed instance starting at $199 per month on AWS, GCP or Azure, with a 7-day trial. PostHog Cloud's Free plan includes the first 1 million analytics events every month, 1 project and 1-year data retention, and its Pay-as-you-go plan raises this to 6 projects and 7-year data retention. Managed costs recur monthly and scale with usage, so model them against your projected volume for the next two to three years. Check whether replay is included in the event count and how overage is billed.
What to ask for in a quote
Ask every vendor and partner for the same line items: server sizing for your volume, storage at your retention period, backup and restore effort, upgrade effort per cycle, and support level. Separate one-time setup and integration work from recurring hosting, subscriptions and support. Ask whether a migration from another analytics tool is included, since PostHog's managed migrations cover one year per direct import job and cannot be selectively deleted once imported. Confirm which costs change if your volume doubles.
Moving session replay history from one tool to the other
This sequence moves session replay tracking from one tool to the other without losing masking controls or leaving untracked gaps in production. It ends with the old tracker removed and a clear record of which recordings stayed in the old store.
Inventory instrumented sites and apps
List every website, single-page app, mobile app and embedded surface that loads the current replay SDK, and note the environment, owner and domain for each. Include tag manager containers and any server-side or first-party proxy paths that forward events. The output is a signed-off inventory that the migration team and product owners both agree is complete. Ask the current vendor and your engineering leads to confirm nothing is loaded outside the main release pipeline before you treat the list as closed.
Document the current masking and privacy rules
Before any new SDK is deployed, export the masking configuration from the current tool, including CSS selectors that are masked or skipped, input redaction settings and any private or full-mask modes. Record which rules apply per site and per environment. This document is the baseline you test against. It is done when a privacy or compliance reviewer has signed the baseline, since it becomes the reference for the parallel run.
Configure equivalent masking in the new tool
Set up the new tool's capture-time controls to match the baseline from the previous step. For OpenReplay, that means the sanitization rules described in its README, including masking by CSS selector, input redaction and its private mode. For PostHog, confirm the equivalent session replay masking options in the current docs for your version, because the mapping is not one-to-one and needs verification. The check is a test page with known sensitive fields, reviewed in both tools before any traffic is sent.
Run both SDKs in parallel on a controlled set
Deploy the new SDK alongside the existing one on a limited set of sites or a non-production environment, so both capture the same sessions for comparison. Keep the old tracker active until the new one has produced recordings you can review. Your engineers do this work, with the vendor's documentation as the reference. Check that page load impact, event volumes and consent behavior are acceptable in both tools. The step is complete when recordings from each tool can be matched to the same test sessions.
Confirm masking carries over in production sessions
Sample real production recordings in the new tool and check that masked fields, skipped elements and redacted inputs appear as the baseline requires. Repeat the check on each instrumented app, including mobile where applicable. Record any gap and fix the rule before rollout continues. The output is a dated test log signed by the privacy owner. Do not expand the rollout until this log shows no unmasked sensitive fields in the sampled sessions.
Decide what history stays in the old store
Work with each vendor to confirm whether existing session replay recordings can be exported, imported or retained. PostHog's managed migrations cover historical events imported from Mixpanel, Amplitude or JSONL files in S3, with a one-year limit per direct import job and no deduplication. Those imports do not cover replay recordings, so treat replay history as a separate question to confirm with PostHog. Decide, per data class and retention need, whether old recordings stay in the previous store under its retention settings or are exported. Record the decision, the owner and the retention end date.
Retire the old tracker and archive records
Once the new tool has run cleanly through production sampling and the retention decision is recorded, remove the old SDK from all sites and apps in the inventory. Confirm through a release check and a traffic review that no requests still reach the old endpoint. Archive the configuration, the masking baseline and the decision record. The sequence is complete when the old tool receives no new data, its remaining recordings follow the agreed retention plan, and the archive is stored where auditors can find it.
Where self-hosted replay projects usually run long
The longest part of a self-hosted replay project is rarely the first install. Teams that plan only for hosting and a working recorder often discover late that sanitization, SDK rollout and retention each need owners and sign-off. For OpenReplay, budget the work around capture-time sanitization: the masking rules, CSS selector masks and input redaction run in the browser before data reaches your server, so a rule missed in the SDK configuration cannot be fixed later from the stored recordings. Ask who writes those rules, who reviews them against your data classes, and whether the review happens before or after the first production session is recorded.
SDK rollout is where many projects slip. A web team can add a tracker to one application in a short sprint, but a estate of frontends, single-page apps and native mobile apps means each application needs its own integration, its own test pass and its own privacy check. OpenReplay covers iOS, Android and React Native replay, and PostHog bundles replay with feature flags, surveys and analytics, so each approach brings a different set of client libraries to version and maintain. Inventory every application that will report, decide which ones are in the first wave, and confirm with each vendor which SDK versions and platform features your mobile stack actually needs.
Identity, retention and upgrades complete the picture. Replay viewers need access controlled by the same identity provider and group model as the rest of your tooling, and the roles that decide who sees unmasked data should be documented before go-live. Retention is a policy decision, not a default: PostHog's cloud free tier and paid plans carry different retention periods, while a self-hosted OpenReplay instance keeps retention under your control. Finally, plan upgrade cadence early. Confirm the release process, backup and restore steps and the support you have for each product, because self-hosted deployments of PostHog are officially unsupported and an OpenReplay self-hosted install relies on community support unless you buy the Enterprise edition.
Questions buyers ask before choosing or hiring help
Is self-hosting PostHog officially supported?
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. The free Docker Compose hobby deployment is MIT licensed and installed with a deploy-hobby script, and the README recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. The README also says open-source deployments should scale to approximately 100k events per month and recommends PostHog Cloud above that. Kubernetes deployments of the paid self-hosted product are no longer supported. Confirm current terms with PostHog before you commit, and plan for your own operations team or a partner to own upgrades, backups and incidents.
What does a self-hosted OpenReplay need to start?
OpenReplay's README says a single virtual machine with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to start self-hosting. Supported targets include AWS, Google Cloud, Azure, DigitalOcean, Scaleway, OVHcloud, Kubernetes with Helm, Docker and Ubuntu. The starting footprint is small, but the stack still needs a TLS endpoint, backups, storage growth planning and an upgrade routine. Its latest release, v1.28, was published on September 25, 2025, so check the releases page and your own change process before you plan an upgrade. Ask whether your sizing matches your expected session volume, since the README does not give a volume ceiling for a single VM.
Can our team run either platform without outside help?
It depends on whether your engineers have time to own the platform after launch. For PostHog self-hosting, the official position is that no vendor support exists, so your team carries every incident, upgrade and backup decision. For OpenReplay, the community edition is free with community support and self-managed retention, so your team would own the same operational work with fewer vendor channels. Either platform can be run in-house by a team comfortable with Docker, Kubernetes, PostgreSQL-style data stores and on-call rotations. If that team does not exist, consider a fixed-scope engagement from DeployOpen covering installation, hardening, backup design and documentation, or a managed option from the vendor. Document the skills you need before you decide.
What drives the cost and effort of implementing either one?
The main cost drivers are infrastructure, labor and the number of systems the replay tool must integrate with. Software licensing is not the largest variable here, because the open-source editions of both products are free to use, but the paid tiers change the picture. PostHog's Pay-as-you-go plan and platform packages cover SSO, audit logs and custom roles on Cloud, while OpenReplay's enterprise edition is quoted on custom pricing and adds SSO and SAML, SCIM provisioning and audit trail. Recurring costs include hosting, storage growth, monitoring and staff time for upgrades. One-time costs include design, identity integration, sanitization rules and testing. Ask any provider for a written quote that separates these items, names what is in scope and states who is responsible for upgrades after go-live.
How long does a migration take, and what does it need from our team?
The answer depends on the source data and the scope you agree. PostHog's managed migrations can import historical events 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, events are not deduplicated, and there is no way to selectively delete event data once imported. Historical imports are free of ingestion fees when sent with the historical_migration flag, but a paid product analytics plan is required to unlock the import features. Your team must provide source credentials, decide which years to import, review duplicates and approve the tracking changes. Get a timeline in writing from any provider, because the documentation here does not give one.
When does a managed cloud option make more sense?
A managed cloud option makes more sense when you lack the staff to run upkeep, when you want the vendor to own upgrades, or when your event volume exceeds what a self-hosted hobby setup should handle. PostHog's README recommends PostHog Cloud above about 100k events per month, and PostHog Cloud offers US (Virginia) and EU (Frankfurt) regions. OpenReplay Dedicated is a fully managed instance starting at $199 per month on AWS, GCP or Azure with a 7-day trial, according to its pricing page. Bring-your-own-cloud and Serverless options also exist. Managed services shift cost from labor to subscription fees and reduce control over where data sits, so compare residency, retention and exit terms before you sign.
Does self-hosting keep session data under our control?
Self-hosting keeps data in your own infrastructure, which is the main reason regulated teams choose it. OpenReplay's README notes that self-hosting keeps session data in the operator's own infrastructure and that first-party tracking from your own domain is not blocked by ad blockers. It also describes capture-time sanitization that masks or skips data before it reaches the server, including masking by CSS selector and input redaction, plus a private mode that masks all text and inputs by default. PostHog's session replay also sits in a self-hosted stack you run, but you must configure its privacy controls yourself. Test masking on real forms in a staging environment, and ask your security team to review the design against your data classification rules.
Which license terms should legal review before rollout?
Legal should review each product's license in full before rollout. PostHog's repository is MIT licensed except for the ee directory, which has its own license, and its README says premium features from ee on a self-hosted instance require a PostHog license. PostHog points teams that need fully free software to the posthog-foss repository. OpenReplay's monorepo is mostly AGPLv3, some directories are MIT, and the ee directory is under a separate commercial license. Under AGPLv3, modified network services may carry source-disclosure duties, so ask counsel to confirm your obligations if you change the code. Confirm which features you need sit in free or licensed code before you choose.
How DeployOpen helps you choose, implement or migrate
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a session replay decision, that work can cover the parts that matter most to the choice: deciding where the replay server runs, configuring capture-time sanitization and private mode, setting up retention and access, and wiring the replay tool to your identity provider and existing monitoring. DeployOpen also runs security testing that can include the replay tool itself, including the applications and APIs that load its tracking script, so you can see what a recorded session exposes before it reaches production users.
Most engagements are fixed-scope. Before work starts, the scope, deliverables and timelines are agreed in writing, and a quote follows from that written scope rather than from a published price list. To make the quote comparable across the two platforms, ask for the components in each option: the hosting target, the Kubernetes or single-VM layout, the sanitization rules, the upgrade and backup plan, and who answers for the install after go-live. Ask the same questions of any other implementation partner you consider.
DeployOpen does not favor PostHog or OpenReplay. It is not an official partner, reseller or certified provider of either vendor, and it does not sell their licenses or hosted plans as part of this work. DeployOpen also does not issue audit reports, attestations or certifications. If your review needs evidence for a compliance assessment, DeployOpen can prepare the systems, controls and evidence, but an independent auditor or certification body makes the assessment.
