Heap or PostHog: when each fits and what the decision turns on
A Heap renewal is the usual trigger: the quote arrives, session-based pricing is hard to forecast against your traffic, and the Contentsquare merger raises questions about the product's direction. A managed Heap contract fits teams that have already invested in Heap's autocapture, have analysts who rely on retroactively defined events, and want to keep operating effort low. PostHog fits teams that need cost they can predict from event volume, a choice between PostHog Cloud's US (Virginia) and EU (Frankfurt) regions, or full control of data through self-hosting. Heap's pricing is not published, so ask for the session counts behind any quote before comparing it with PostHog's event-based figures.
PostHog's Free plan includes the first 1 million analytics events each month, 1 project and 1-year data retention, and its Pay-as-you-go plan raises this to 6 projects and 7-year retention. Self-hosting is a different trade. PostHog's hobby deployment is a free Docker Compose setup under the MIT license, installed with a deploy-hobby script, and it is sized from a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. Self-hosted instances are officially unsupported, PostHog does not provide customer support for them, and its README recommends moving to PostHog Cloud above roughly 100k events per month. Features in the ee directory also need a PostHog license, and SSO, audit logs and custom roles are sold as platform packages. Confirm which of these features your team actually needs before you choose a deployment model. For the current plan and region details, see PostHog pricing.
Four questions decide the choice. First, data history: list the reports and cohorts that need more than one year of history, because Heap's retention terms and PostHog's 1-year and 7-year options must both cover them. Second, exports: confirm in writing that your Heap plan includes Heap Connect or a full JSON export, since PostHog's direct import from Heap is limited to one year per job and cannot delete imported events selectively. Third, the Contentsquare roadmap: Heap announced its agreement to join Contentsquare in 2023, so request the product, support and pricing commitments for your renewal term in writing. Fourth, operating capacity: if no one on your team can run, patch and back up a self-hosted stack without vendor support, PostHog Cloud is the realistic PostHog option. Before the renewal date, export a sample of events and test whether your dashboards can be rebuilt from that export.
Which platform fits which scenario
This table matches common buyer situations to the platform that usually fits better and the condition under which that advantage matters. Read each row against your own session volumes, residency rules and team capacity, because the answer changes when those inputs change. The main takeaway is that PostHog's self-hosting and feature flag bundle favor teams that can run infrastructure, while Heap's managed model favors teams that want a vendor to operate it.
| Scenario | Better fit | Why it matters |
|---|---|---|
| Renewal with unpredictable session counts | PostHog Cloud or self-hosted PostHog | Heap prices on sessions, which are hard to forecast for some products. PostHog's Cloud model is event-based, and self-hosting removes the vendor meter, though you then carry infrastructure cost. Ask Heap for session history before renewal. |
| Data residency in the EU | Self-hosted PostHog in your EU infrastructure | PostHog Cloud offers an EU (Frankfurt) region. Self-hosting keeps every event inside your own accounts and data centers. Confirm the Heap data region options with Heap before deciding. |
| Team with no platform engineers | Heap or PostHog Cloud | Self-hosting is unsupported by PostHog and the Docker Compose deployment still needs someone to run upgrades, backups and monitoring. A managed option removes that operating load even though it costs more to run. |
| Need for feature flags next to analytics | PostHog | PostHog groups product analytics, session replay, feature flags, experiments and surveys in one product. Heap is focused on analytics and session data, so flags and experiments usually need a second tool. |
| Long data history requirement | Confirm against both plans before choosing | Heap's data history limits depend on plan, and extending history costs more. PostHog's Pay-as-you-go plan lists 7-year data retention. Check the exact retention you need against current plan terms for each vendor. |
| Contentsquare roadmap concern | PostHog, if you want a stable product direction | Heap agreed to become part of Contentsquare in 2023. Ask Heap and Contentsquare in writing what happens to the Heap product, pricing and Heap Connect terms. PostHog is an independent company whose open-source core you can keep running if its cloud terms change. |
How Heap's autocapture and virtual events compare with PostHog's autocapture and actions
Heap and PostHog both capture interactions automatically, but they differ in when you decide what an interaction means. Heap records clicks, form submissions and page views without custom instrumentation, and its virtual events let a team define a named event after the fact, by selecting an element or rule against data already stored. The definition applies to history that was captured before the event existed, so a team can often ask a new question about last quarter without redeploying tracking code. PostHog also provides autocapture, and its actions group captured events under a name using rules you configure. An action is a filter over events PostHog has already received, so it helps most when the events you need were captured with enough detail to match.
The trade-off follows from that difference. Retroactive definition is strongest when your data is already captured and your schema is still changing, because you can refine a definition without losing the events that would have matched it. PostHog actions depend on the captured events matching the rule at the time of the query and on the properties being present in those events. If a button's text, selector or page path changed before you wrote the action, you may need to adjust the rule, and you should confirm how far back PostHog applies a changed action in your own project. Ask whether your key journeys depend on element selectors that your front-end team changes often, and whether any event you need is captured only through custom code.
Treat both products' current behavior as something to verify, not something to assume from older documentation. Run a trial on your own site with a staging copy of your most important funnel. Define the same three or four events in each tool, change one selector in the staging build, and check what each product returns for history before and after the change. Record how each handles unmatched elements, identity merging and property capture on dynamic pages. The result tells you how much re-instrumentation a migration would involve, which is often the largest effort item.
Capability comparison from documented facts
This table sets PostHog's documented capabilities, licensing, hosting and plan terms against Heap's features, with unverified Heap items marked for confirmation. Use it to shortlist questions for Heap and PostHog before you rely on any row. Where a row says to confirm, ask the vendor in writing rather than assuming a match.
| Capability | Heap | PostHog |
|---|---|---|
| Product analytics | Event-based product analytics with autocapture; confirm current feature set with Heap | Product analytics is a named product in the PostHog README alongside web analytics and session replay |
| Autocapture | Captures interactions automatically; confirm capture scope and definition workflow with Heap | Autocapture is available; confirm which events are captured by default in your SDK version |
| Retroactive definitions | Heap's virtual events apply new definitions to captured data; confirm how far back they apply and any plan limits | Actions are defined on captured events; confirm whether definitions apply to history in your plan |
| Session replay | Session recording is offered; confirm whether it is included in your plan and its retention | Session replay is a named PostHog product in the README |
| Feature flags and experiments | Not a core Heap offering; confirm with Heap before assuming a match | Feature flags and experiments are named PostHog products in the README |
| Surveys and data pipelines | Heap Connect exports data to a warehouse; confirm the plans that include it | Surveys and data pipelines are named PostHog products in the README |
| Licensing | Commercial, closed-source SaaS; no self-hosted option is documented in the supplied facts | MIT Expat for most of the repository; ee/ directory under a separate license; posthog-foss is purged of proprietary code |
| Hosting options | Heap hosted by Heap; confirm regional options and whether a dedicated deployment exists | PostHog Cloud in US (Virginia) and EU (Frankfurt), or self-hosted via Docker Compose (hobby) |
| Data history on free tier | Confirm the history limit for your plan with Heap in writing | Free plan includes 1-year data retention; Pay-as-you-go includes 7-year retention (PostHog pricing page) |
| Enterprise controls | Confirm SSO, audit logs and roles with Heap for your contract | SSO, audit logs, custom roles and project permissions are sold as platform packages |
| Support model | Confirm support tiers and response terms in your Heap agreement | Self-hosted deployments are officially unsupported; PostHog Cloud support follows its plans |
Where the data lives and who controls it
Heap is a managed SaaS product. Customers send events to Heap's hosted platform, and Heap operates the collection, storage and query infrastructure. Heap announced on September 28, 2023 that it had agreed to become part of Contentsquare, so the operator relationship and contract terms for Heap should be confirmed with Contentsquare as part of any renewal. The data location, sub-processors and transfer mechanisms are set out in Heap's own documentation and contract, and they should be read directly rather than assumed.
- Data location: Confirm the hosting region for your Heap environment in writing, since it determines which transfer rules apply to your data.
- Operator: Heap runs the platform, so your team does not manage servers, upgrades or backups.
- Support model: Support runs through Heap's commercial plan, and the level of support depends on the contract you hold.
- Corporate change: The Contentsquare merger may affect roadmap, product packaging and data processing terms, so ask for the current processing agreement.
- Export path: Data leaves Heap through Heap Connect or a one-time export, so the exit route depends on the plan you hold.
Before renewal, ask Contentsquare to confirm the hosting region, sub-processors and the data processing addendum that now applies to your account.
PostHog Cloud is PostHog's hosted service, offered in two regions: US (Virginia) and EU (Frankfurt). PostHog operates the infrastructure, so your team sends events to a chosen region and does not run databases or collectors. Choosing the EU region keeps storage in Europe, but the company operating the service is still a US entity, so onward access and sub-processing should be reviewed. The European Commission's adequacy decision for the EU-US Data Privacy Framework, adopted on July 10, 2023 (decision 2023/1795), allows personal data to flow freely from the EU to US companies that participate in the framework. Whether PostHog participates, and whether that covers your processing, should be verified by counsel.
- Data location: Pick the US (Virginia) or EU (Frankfurt) region when you create the project, and confirm that choice in your data map.
- Operator: PostHog operates the platform, including upgrades and availability.
- Support model: Support is part of the paid Cloud plans, and SSO, audit logs, custom roles and project permissions are sold as platform packages.
- Volume guidance: PostHog's README points teams to Cloud above roughly 100k events per month, which is the threshold it gives for leaving open-source deployments.
- Transfers: Evaluate whether any US-based access triggers transfer rules and whether consent is needed under the CNIL analytics conditions for your use case.
Ask PostHog for its current sub-processor list and confirm the region and data processing terms before you send production events.
Self-hosting keeps events, person profiles and session data on servers you control, in your cloud account, data center or private network. Your team, or a partner you engage, operates the deployment. PostHog's self-host documentation offers a free Docker Compose (hobby) deployment under the MIT license, installed with a deploy-hobby script, and recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. PostHog states that self-hosted deployments are officially unsupported and that it does not offer customer support for product, infrastructure or other questions on self-hosted instances. New Kubernetes deployments of its paid self-hosted product are no longer supported.
- Data location: Events stay in your environment, so no PostHog-operated region is involved.
- Operator: Your team owns upgrades, backups, scaling, monitoring and security patching.
- Support model: No vendor support is offered for self-hosted instances, so support comes from your staff, the community or a paid implementation partner.
- Kubernetes: New Kubernetes deployments of the paid self-hosted product are not supported, so plan the architecture on Docker Compose or another supported path.
- Volume guidance: Open-source deployments are expected to handle roughly 100k events per month, and the README recommends migrating to PostHog Cloud above that level.
Confirm the deployment target, the sizing for your expected volume and who will be on call before choosing this model. Counsel should still review your own transfer and consent obligations, since self-hosting changes the operator but not the controller's duties.
What PostHog's license means for a self-hosted deployment
PostHog's license is split by directory, and that split decides what a self-hosted deployment can do without a paid agreement. The core repository is under the MIT Expat license, but everything in the ee/ directory is covered by a separate license in ee/LICENSE. The PostHog README states that using premium features from ee/ on a self-hosted instance requires a PostHog license. For a team that plans to self-host, this means the features it needs, not the platform as a whole, determine whether a license is required. Before committing, read the PostHog LICENSE file and the ee/LICENSE file, then map each feature on your requirements list to the directory that contains it.
The consequence for feature parity is that a self-hosted PostHog can differ from PostHog Cloud. Premium capabilities such as SSO, audit logs, custom roles and project permissions are sold as platform packages on the pricing page, so a team that expects them on a self-hosted instance should confirm, in writing, which of them come from ee/ and what license they require. Do not assume that the MIT label covers the whole product. Teams that want fully free software can point to the posthog-foss repository, which the README describes as purged of all proprietary code and features. That repository is a different build with a narrower feature set, so test the analytics, session replay and feature flag workflows you depend on against it before choosing that path.
Plan the license review as part of the evaluation, not after the deployment is live. Ask PostHog which features your use cases depend on, which directory each one lives in and whether a license is needed for a self-hosted instance. Record the answers with the date and the version you tested. Then ask your legal and procurement teams to review ee/LICENSE against your internal use, including any future change to the hosting model. Keep in mind that the license terms are a separate question from support: PostHog's self-host documentation states that self-hosted deployments are officially unsupported, so the license review should be paired with a plan for who operates and patches the instance.
Cost components on each side and what drives them
This table lists each cost component on the Heap side and the PostHog side, whether it is one-time or recurring, who gets paid, and what pushes it up. Heap does not publish prices, so use the drivers and the quote questions to compare the two sides on your own event volumes and data retention needs.
| Cost component | One-time or recurring, and who is paid | What drives it up or down, and what to request |
|---|---|---|
| Heap subscription | Recurring. Paid to Heap on a session-based plan that Heap does not publish. | Session volume, plan tier and data history length. Request the plan price per session band, the included data history and renewal terms in writing, and confirm how Contentsquare ownership affects terms. |
| Heap Connect add-on | Recurring. Paid to Heap as a separate add-on on plans that do not include it. | Whether warehouse sync is in your plan and how many destinations you export to. Ask Heap which plans include Heap Connect and what it costs on your plan. |
| Data history extension | Recurring. Paid to Heap if you need history beyond your included window. | How far back you need data for trend and cohort analysis. Ask what history is included, what extension costs, and whether a one-time JSON export is offered before exit. |
| PostHog Cloud usage billing | Recurring. Paid to PostHog on usage above the free tier, per PostHog's pricing page. | Event volume above the first 1 million analytics events each month, which the pricing page makes free, plus features sold as platform packages. Request a usage estimate from your real event counts before committing. |
| Self-hosted infrastructure | Recurring. Paid to your cloud provider or data center for servers, storage and backups. | PostHog's self-host documentation recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage for the Docker Compose hobby deployment. Event volume, retention length and replica counts raise storage and compute needs. |
| Engineering and upgrade time | Recurring. Paid as internal staff time or to an implementation partner for patching, upgrades and monitoring. | Number of PostHog versions to track, the choice between Docker Compose and Kubernetes, and how often you upgrade. PostHog states that new Kubernetes deployments of its paid self-hosted product are no longer supported, so confirm which deployment path applies to you. |
| Support | Recurring if bought. Heap support is part of the subscription. PostHog does not offer customer support for self-hosted instances, so any support is paid to a third party. | Severity of incidents and the uptime you need. Ask Heap what support tiers are included, and for self-hosting, budget a retainer or internal on-call coverage. |
| Migration work | One-time. Paid as internal time or to a partner for export, conversion and dashboard rebuilding. | Number of events, users and identities to alias, and the Heap plan needed to export data. PostHog's Heap guide uses Heap Connect or a one-time JSON export, so confirm which path your plan allows before planning. |
What running PostHog yourself asks of your team
Self-hosting PostHog moves every operational duty to your team, from the first install to the last backup restore. The cards below describe each duty, the conditions under which it stays manageable, and the signs that outside help is worth the cost.
Installing with the hobby path
PostHog offers a free Docker Compose deployment under the MIT license, installed with a deploy-hobby script. It is a sound way to evaluate PostHog on your own servers, but it is a starting point, not a production design. Check which components the Compose file runs, where data volumes live, and how you will change secrets and domains before any real traffic arrives.
Sizing and storage growth
The self-host documentation recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. Event volume, not user count, drives growth, so storage and database load can climb faster than expected once session replay and multiple products are enabled. The README suggests open-source deployments are meant for roughly 100k events per month and recommends PostHog Cloud above that. Model your event volume and retention before choosing hardware.
Upgrades and security patching
Your team owns every release, dependency update and security fix, and must schedule them against your change windows. Track the PostHog release notes and the license scope, since premium features in the ee directory need a PostHog license on self-hosted instances. Confirm whether the features you rely on sit in MIT code or in ee code before you commit to an upgrade cadence.
Backups and disaster recovery
Event data, Postgres and ClickHouse-style analytics stores, and object storage for replays must each have tested backups and a documented restore procedure. A backup that has never been restored is not evidence of recovery. Define a recovery point and recovery time you can meet with your own hardware, and rehearse a restore on a separate host at least once before go-live.
On-call and monitoring
Someone must notice when ingestion stalls, a queue backs up or disk fills, because lost events are rarely recovered later. Build alerts on ingestion lag, container health, disk space and certificate expiry, and assign a named on-call rotation. Teams that already run Prometheus, Grafana or similar stacks can reuse them, which lowers the new effort but still needs an owner.
No vendor support on self-hosted
PostHog states that self-hosted deployments are officially unsupported and that it does not offer customer support for product, infrastructure or other questions on self-hosted instances. Your engineers, or a partner you contract, carry every incident. If your organization needs a named party to answer for uptime, budget for internal expertise or an outside implementation and support agreement, and check the terms in writing before you start.
How a move from Heap to PostHog runs at a high level
The sequence moves Heap's behavioral history into PostHog and proves the reports match before tracking is switched over, so the cutover does not leave gaps in the data.
Confirm the Heap plan and data history limits
The analytics owner checks the current Heap contract for the plan tier, the data history window, and whether Heap Connect is included or sold as an add-on. Ask Heap in writing what history is retained and what export options apply to your account. The step is done when the team has a written list of what can be exported and by when it must be pulled, since history limits set the scope of everything that follows. See the page on how to export your data from Heap for the export terms to check.
Export events and users from Heap
The data owner pulls the export through Heap Connect into your warehouse or requests a one-time JSON export from Heap support. Chart CSV downloads are not a substitute, because they summarize results rather than keep the event-level records needed for replay into PostHog. The step closes when the export files or warehouse tables are complete, you have checked row counts for key events against Heap, and the export is stored in a location your security team approves.
Review PostHog's Heap migration guide
The engineering lead reads PostHog's documented Heap migration path and confirms which steps apply to your export format. PostHog's managed direct imports cover Mixpanel and Amplitude, not Heap, so a Heap move relies on the scripted route described in that guide. The step is done when the team has a written plan that names the export format, the import method, and the owners for each stage.
Convert events, users and identities
Engineers map Heap's per-event tables and user properties to PostHog event names, properties and person records, then set up identity aliasing so anonymous and identified sessions join correctly. Keep a mapping file in version control so each conversion can be reviewed. The step closes when a sample of users shows the same identity in both systems and the property types match, which confirms the aliasing logic works before any bulk load.
Load history and check the imports
Engineers run the scripted import into a dedicated PostHog project for the migrated history. Note that imported events are not deduplicated, so re-running a load adds duplicates, and there is no way to selectively delete imported event data. Test loads in a separate project first. The step is done when the record counts per event match the export and the team has agreed that the migrated project is the one to keep.
Validate key reports against Heap
The analytics owner rebuilds the core funnels, retention charts and conversion reports in PostHog and compares them with the same reports in Heap for the overlapping period. Small differences from definitions such as session timeouts or bot filtering are expected, but each one should be explained and written down. The step closes when stakeholders have signed off the reports that drive decisions, and the open differences are documented.
Run both tools in parallel
Teams keep Heap and PostHog tracking side by side for a period agreed in advance, so live traffic can be compared between the two. Confirm with your Heap contract how long you must keep the subscription and whether session billing continues during the overlap. The step is done when live event volumes and key metrics in PostHog match the expected behavior of Heap, and no critical events are missing.
Cut over tracking and retire Heap
Engineers switch the SDK and tag configuration so new events go only to PostHog, then remove the Heap snippet and autocapture from the production sites and apps. Archive the export files and the migration mapping under your retention policy before the Heap account closes. The step is complete when production tracking runs only in PostHog, the Heap code is removed from the release, and the archive is verified.
Questions buyers ask before switching from Heap
How much does it cost to switch from Heap to PostHog?
The switch cost is driven by what you already pay Heap, what you need to export, and how much engineering time the move takes. Heap's pricing is not published, so the starting point is your current renewal, including any Heap Connect add-on. On the PostHog side, the Free plan includes the first 1 million analytics events each month according to PostHog's pricing page, and a self-hosted deployment adds server, storage, backup and staff time. One-time costs include export work, event and identity mapping, and dashboard rebuilding. Recurring costs include hosting or Cloud usage, and any paid platform packages such as SSO or audit logs. Ask Heap for a written export quote and ask PostHog for a usage estimate based on your actual monthly event volume.
How long does a Heap to PostHog migration take?
The duration depends mainly on how much history you need, how many events and properties you track, and how much of your reporting depends on Heap-specific features. Heap's autocapture and retroactive virtual events need to be mapped to PostHog's autocapture and actions, which takes review of each definition. PostHog documents a scripted migration from Heap through Heap Connect, and the Heap plan you are on determines whether you can get the data out in the first place. Identity aliasing also takes time because it affects user counts and funnels. Plan an overlap period where both tools run, and confirm the export scope and timeline with your team and the vendors before committing to a date.
Can our own team migrate from Heap without outside help?
A capable engineering team can migrate alone if it has time, data engineering skills and a clear list of the dashboards and funnels that matter. PostHog documents the Heap migration path, so the core export and conversion steps are well described. The work that usually needs the most judgment is event and property mapping, identity aliasing, validating counts against Heap before cutover, and rebuilding stakeholder reports. PostHog's self-hosted product is officially unsupported and PostHog does not offer support for self-hosted infrastructure questions, so the operational owner must be in-house or contracted. Teams that want a fixed-scope implementation can ask DeployOpen for a written scope covering planning, implementation, hardening and documentation.
Is self-hosting PostHog worth it under 100k events per month?
Self-hosting can make sense at low volume, but the decision rests on operating effort more than on event fees. PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends PostHog Cloud above that level. PostHog's hobby Docker Compose deployment under the MIT license is installed with a deploy-hobby script, and its self-host documentation recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. Cost components include that server, backups, upgrades, monitoring and the staff time to run them. Compare these with PostHog Cloud usage charges at your volume, and note that Cloud is available in US (Virginia) and EU (Frankfurt) regions.
What happens to our Heap history if we do not export it?
Heap history that is not exported stays only in Heap, subject to your plan's data history limit, and it cannot be recovered in PostHog later. Export options differ by plan: Heap Connect syncs to a warehouse on plans that include it, while a one-time JSON export is obtained from Heap support. Chart CSV exports do not carry the underlying event data. Before your contract ends, confirm in writing what history you can access, the format, and the deadline for requesting it. Also check whether any history beyond your data history limit can be extended, and at what cost. Once data is imported into PostHog, its documentation notes there is no way to selectively delete imported event data, so review what you import.
How does Contentsquare ownership affect Heap's roadmap?
Heap agreed to become part of Contentsquare, as announced on September 28, 2023, and Contentsquare has since merged Hotjar into its platform. Public statements describe the combination, but they do not give a product roadmap for Heap as a standalone tool. Treat the future of Heap as unknown until it is confirmed in writing. Ask Heap and Contentsquare to state in writing whether Heap will remain a separate product, what happens to pricing and data history terms at renewal, whether Heap Connect will continue, the data residency options and the notice period for any product changes. Those answers should drive your exit timeline.
Does PostHog cover the features Heap users depend on?
PostHog covers product analytics, web analytics, session replay, feature flags, experiments and data pipelines, which overlap with much of what Heap teams use. The gaps are in details you must test: how autocapture behaves on your frontend, how retroactive definitions are rebuilt as PostHog actions, and whether your funnel, retention and cohort reports match. Some capabilities, including SSO, audit logs, custom roles and project permissions, are sold as platform packages. Self-hosted use of premium features in PostHog's ee directory requires a PostHog license, while the posthog-foss repository contains no proprietary code. Build a feature inventory from your Heap dashboards and check each item against a test environment.
How DeployOpen helps evaluate, implement and migrate PostHog
DeployOpen is a Chainscore Labs company. We plan, implement, integrate, harden, back up, upgrade and document self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Heap to PostHog move, that means helping you decide between PostHog Cloud (US or EU region) and a self-hosted deployment, then building the stack you choose. We do not hold partner or reseller status with PostHog or Heap, and we do not publish prices. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. The migration work is where the Heap comparison becomes concrete. It typically covers confirming what your Heap plan lets you export, choosing between Heap Connect and a one-time JSON export, mapping per-event tables to PostHog events, aliasing identities so users are not split in two, and reconciling event counts between Heap and PostHog for the periods you need. We also validate that the tracking matches your consent position, including the retention setting in PostHog and any cookie or identifier changes, and we check dashboards and feature flags against the expected numbers before you cut over. Ask any implementation partner to show you the validation plan in writing. Security testing covers both the tracking and the self-hosted stack. That includes reviewing what the snippet and SDK send, testing the ingestion endpoint and admin interfaces, checking access roles and network exposure, and confirming backup and restore for the PostHog data store. Because PostHog states that self-hosted deployments are officially unsupported and that it does not provide customer support for self-hosted infrastructure, a retainer for upgrades, monitoring, patching and continuous testing is often the decision point for teams that choose self-hosting. Retainers are scoped separately and quoted from their own written terms.
Use this section to shortlist questions for any partner, including DeployOpen: who performs each validation step, what evidence you receive at handover, how upgrades are tested before rollout, and what happens to the stack when the engagement ends. We prepare systems, controls and evidence for compliance assessments, but we do not issue audit reports or certifications, so your independent auditor or certification body remains responsible for those conclusions.
