Matomo vs PostHog: which to choose

Matomo vs PostHog: when marketing web analytics or product analytics fits

Choose Matomo when the tool serves marketing and web analytics on a self-hosted GPL stack, and choose PostHog when the tool serves product teams that need session replay and feature flags, most often run on PostHog Cloud. The two overlap on pageviews and funnels, so the decision rests less on features than on five questions: who owns the tool, how many events you expect each month, whether self-hosting needs vendor support, whether session replay or feature flags are required, and where the data must sit. A team replacing Google Analytics for a marketing site usually starts with Matomo. A product team that wants to ship flags and watch user sessions usually starts with PostHog.

Ownership is the first filter. Matomo's On-Premise Community edition is free with unlimited users and hits, and its support is forum-based, so marketing operations can run it with an internal administrator. PostHog's self-hosted deployments are officially unsupported, and PostHog does not offer customer support for product, infrastructure or other questions on self-hosted instances. If you need a vendor or partner to answer for a self-hosted install, PostHog's own documentation tells you that route is closed. Volume is the second filter. PostHog's README says open-source deployments should scale to about 100k events per month and recommends moving to PostHog Cloud above that. Matomo's requirements FAQ sizes a single server for up to 1 million pageviews a month, so estimate your own monthly volume before choosing either.

Before you commit, confirm three things in writing. First, whether you need session recordings or heatmaps: Matomo's Heatmap and Session Recording plugin is a paid premium plugin, and the CNIL's exemption from consent is lost once such features are added, so confirm the consent position with your privacy lead. Second, whether you need feature flags, which PostHog provides and Matomo does not. Third, where the data must be stored: PostHog Cloud offers US (Virginia) and EU (Frankfurt) regions, while Matomo On-Premise keeps data in your own infrastructure. Ask PostHog for its current SSO and audit log terms, because those are sold as platform packages.

Which platform fits which team and scenario

This table maps common team situations to the platform that usually fits better and the condition that makes it true. Read each row against your own traffic, data residency rules and who will run the tool, because the answer changes with those inputs.

Scenario	Better fit	Condition that holds it
Marketing-led web analytics (campaigns, channels, goals, ecommerce)	Matomo On-Premise	The team mainly needs page and campaign reporting, and the free On-Premise edition covers its needs with unlimited users and hits, plus forum support only.
Product-led event analysis (funnels, cohorts, user paths in an app)	PostHog	Product managers need event-level analysis across an application, and the team accepts that PostHog's event model and product analytics fit its roadmap better than Matomo's page-centric reports.
Session replay on the same tool	PostHog or Matomo with a paid add-on	PostHog bundles session replay in its suite. Matomo needs the paid Heatmap and Session Recording plugin, sold per number of users under the InnoCraft EULA, and that plugin changes the consent position under the CNIL guidance in Matomo's ePrivacy FAQ.
Feature flags and experiments tied to analytics	PostHog	The engineering team wants flags and experiments alongside analytics. Matomo does not cover this use case, so it is not a like-for-like choice.
Strict EU data location and self-controlled hosting	Matomo On-Premise	Data must stay in infrastructure the organization controls. PostHog's self-hosted route is unsupported, so the team carries all operating risk. Confirm the data location of any managed option before signing.
Small pilot at low event volume	PostHog Cloud free tier or Matomo On-Premise	PostHog's pricing page lists 1 million analytics events free each month, and its README says open-source deployments should scale to about 100k events per month. Above that level, PostHog recommends its cloud, so a self-hosted pilot should be sized to stay well under that line.
Self-hosting PostHog as a production analytics store	Usually neither as a default	PostHog's self-host docs say self-hosted deployments are officially unsupported with no customer support for infrastructure questions. Choose this only if the team can staff the operations itself, and confirm what support exists before committing.

How Matomo and PostHog are built and what that means for operations

Matomo and PostHog reach a similar goal through very different self-hosted footprints. The cards below cover the stack, sizing, support status and who carries the pager, because those choices decide how much operating work lands on your team.

Matomo runs on a classic LAMP-style stack

Matomo is a PHP application backed by MySQL or MariaDB and served through a web server such as Apache, Nginx, IIS or LiteSpeed. Matomo 6.0.0 needs PHP 8.1 or newer and MySQL 8.0 or newer or MariaDB 10.6 or newer, while the 5.x line runs on PHP 8. Your team patches the PHP runtime, the database and the web server on their own schedule, which suits teams that already run this stack. Confirm which major version you will pin before you build the image.

Matomo sizing scales with pageviews

Matomo publishes sizing tiers by monthly pageviews. A single server with 4 CPUs, 8 GB of RAM and 250 GB of SSD covers up to 1 million pageviews a month. Above that, Matomo recommends separate application and database servers, each with 8 CPUs and 16 GB of RAM, for up to 10 million pageviews a month. Scaling up is a capacity decision you own, so ask who is accountable for archiving jobs and disk growth as traffic rises.

PostHog self-host is a Docker Compose hobby deploy

PostHog's free self-host option is a Docker Compose 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. The README says open-source deployments should scale to about 100k events per month, and above that PostHog recommends moving to PostHog Cloud. Treat this as a sizing ceiling, not a growth path.

PostHog self-host carries no vendor support

PostHog states that self-hosted deployments are officially unsupported and that it offers no customer support for product, infrastructure or other questions on self-hosted instances. Patching, incident response and upgrades therefore fall to your own team or your implementation partner, with no vendor queue to call. Before you commit, decide who holds the on-call rota for the hobby stack and what your response expectation is.

Kubernetes self-host is closed to new installs

PostHog's self-host documentation notes that new Kubernetes deployments of its paid self-hosted product are no longer supported. Teams that standardized on Kubernetes for Matomo-style workloads should not plan a PostHog cluster on that basis. If you need a multi-node platform, confirm with PostHog which deployment paths are currently open before you design around them, and ask what migration path exists if you later move to Cloud.

Ownership of scaling and upgrades

A PHP and MySQL application like Matomo is a familiar workload for operations teams, and its upgrade path is a standard application release. PostHog's self-hosted product is a multi-service system with a different failure surface, so it needs engineers who can debug those services without vendor help. Map the skills you have today to each stack, then decide whether the platform team or the analytics team holds each pager.

Capabilities, data volumes and identity features compared

This table compares how Matomo and PostHog handle reporting, historical data imports, session replay, feature flags, retention, hosting regions and identity features. Read each row with your own ownership model in mind, since Matomo is typically run by a marketing or web team while PostHog's product features are often used by product and engineering teams. Where a capability is not covered by the researched facts, confirm it with the vendor before you commit.

Capability	Matomo	PostHog
Web analytics reporting	Full marketing web analytics suite on the On-Premise Community edition, with unlimited users and hits, per the pricing page	Product analytics suite that includes web analytics among its listed products, alongside session replay, feature flags and surveys
Google Analytics import	Free Google Analytics Importer plugin imports aggregated reports only, so Visitor Log, Ecommerce Log, Custom Reports and Segmentation do not work for imported data	Managed migrations import historical events from Mixpanel or Amplitude via API or JSONL files, and from Google Analytics and Heap through migration guides, with each direct import job covering at most one year
Session replay and heatmaps	Heatmap and Session Recording is a paid premium plugin priced per user under the InnoCraft EULA, with a 30-day free trial	Session replay is one of the listed PostHog products. Confirm whether it is available on your chosen self-hosted or Cloud plan and what it costs
Feature flags and experiments	Not in scope of the Matomo facts supplied. Confirm with the vendor whether any equivalent exists	Feature flags and experiments are listed products in the PostHog README. Confirm availability on your deployment type
Data retention on Cloud	Matomo Cloud plans are sized by monthly hits, from 50,000 to 10 million, so confirm retention terms on the plan you select	Free plan includes 1-year data retention, and Pay-as-you-go raises it to 7 years, per the PostHog pricing page
Hosting regions	Matomo Cloud data is stored in Frankfurt, Germany. On-Premise runs in your own infrastructure	PostHog Cloud offers US (Virginia) and EU (Frankfurt) regions. Self-hosted data stays wherever you deploy it
SSO and audit logs	Not covered by the Matomo facts supplied. Confirm with the vendor which identity and audit features are available in each edition	SSO, audit logs, custom roles and project permissions are sold as platform packages, so confirm the package and price with PostHog
Vendor support for self-hosting	Forum support is listed for On-Premise Community, and paid support options should be confirmed with the vendor	Self-hosted deployments are officially unsupported and PostHog offers no customer support for self-hosted instances

Which license and edition each platform actually gives you

Matomo's core code is published under the GNU General Public License version 3 (GPLv3), as stated in the LICENSE file on its 5.x-dev branch. The On-Premise Community edition is free to run, with unlimited users and hits and forum support. Paid add-ons and the hosted service are separate purchases, so the licensing question is mostly about which features your team will depend on.

Free core: The On-Premise Community edition is free forever, with unlimited users and hits. Your costs are the server, the database, storage and the staff who run it.
Premium plugins: The Heatmap and Session Recording plugin is sold per number of users under the InnoCraft EULA rather than the GPL. It comes with a 30-day free trial, so you can test it before any license decision.
Free importer: The Google Analytics Importer is a free download for On-Premise under GPL v3 or later. It imports aggregated reports only, so raw-data views such as the Visitor Log do not work for imported data.
Matomo Cloud: Cloud plans start at 29 per month (excluding tax) for tiers from 50,000 to 10 million hits a month. Cloud data is stored in Frankfurt, Germany.

Check whether the premium plugins you need are priced per user at your headcount, and ask InnoCraft for the terms that apply to your use before you rely on them.

How consent rules change which analytics tool a team can run

The consent question decides more of this comparison than most feature tables do. Matomo's ePrivacy FAQ says France's CNIL recognizes some audience measurement trackers as exempt from consent, but only when they are limited to purposes such as performance measurement, collect anonymous statistics and exclude marketing measurement. The same FAQ states that adding features such as User ID, heatmaps or session recordings removes that exemption. A team that wants a consent-exempt Matomo setup should therefore treat the exemption as a configuration profile to be kept intact, not as a default that survives every plugin decision.

PostHog's session replay and feature flags sit outside that exemption profile. Session recording captures user behavior at the level of individual sessions, and feature flags are typically used for targeting and experimentation rather than performance measurement. A team that runs PostHog for product analytics with these components enabled should assume the consent-exempt position described for Matomo does not carry over, and should plan for a consent banner and a lawful basis review before go-live. Check which PostHog features are enabled per project, since a deployment that only uses event analytics will sit in a different position from one that records sessions.

Before choosing either tool for an EU-facing site, confirm the position with your data protection officer and the relevant national authority, including whether your country follows the CNIL approach or has its own rules. Document which features you enabled, which identifiers you collect and where the data is stored. Matomo Cloud stores data in Frankfurt, and PostHog offers US and EU Cloud regions, so hosting location is a separate question from consent. Self-hosting changes who operates the processing, but it does not by itself change the consent analysis.

What drives the running cost of each platform

Running cost for Matomo and PostHog comes from the same few places: the servers you size, the people who operate them, the paid add-ons you need and the upgrades you take. The cards below separate what is one-time from what recurs, and list what to request in a quote before you commit to either tool.

Server sizing and hosting

Matomo's requirements FAQ sizes a single server with at least 4 CPUs, 8 GB of RAM and 250 GB of SSD for up to 1 million pageviews a month, with separate app and database servers of 8 CPUs and 16 GB each for up to 10 million. PostHog's hobby deployment recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage, but its README says open-source deployments should scale to about 100k events a month. Ask the quote to price the server tier that matches your actual monthly volume, not the minimum, and to include backups and storage growth.

Staff skills to operate

Matomo runs on PHP with MySQL or MariaDB behind a web server, so the operator needs database administration and PHP upgrade skills. PostHog's self-hosted product is a larger multi-service stack, and its self-host documentation says Kubernetes deployments of its paid product are no longer supported, which narrows the platform choices your team can use. Price the internal hours or the partner hours for each tool, and confirm who owns patching, incident response and data retention.

Paid plugins and platform packages

Matomo On-Premise Community is free with unlimited users and hits, but the Heatmap and Session Recording plugin is a paid premium plugin sold per number of users under the InnoCraft EULA, with a 30-day free trial. PostHog's SSO, audit logs, custom roles and project permissions are sold as platform packages. Both costs recur, so ask each vendor for the per-user or per-package price in writing and the renewal terms.

Support options

Matomo's pricing page lists forum support for the On-Premise Community edition. 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. Either way, a production install needs a named support path, so ask whether you are buying a retainer, a paid support contract or only community help, and what response you can expect in writing.

Upgrade effort and version churn

Matomo 6.0.0 is in beta and requires PHP 8.1 or newer with MySQL 8.0 or newer or MariaDB 10.6 or newer, so a move to the next major version can mean changing the PHP and database stack, not just the application. PostHog's self-hosted installs are unsupported, which leaves upgrades and rollbacks with your team. Budget upgrade testing as a recurring cost, and ask any implementer to state in the scope whether upgrades, rollbacks and regression tests are included.

Cloud tiers and the self-hosting break-even

Matomo Cloud plans start at 29 (excluding tax) per month for tiers from 50,000 to 10 million hits a month, with data stored in Frankfurt. PostHog Cloud gives the first 1 million analytics events free each month, with paid plans beyond that. Compare the monthly cloud bill at your real volume against server, staff and plugin costs for self-hosting. Note that PostHog's README recommends moving to its cloud above about 100k events a month, which is a useful threshold to test against your own numbers.

Moving data and tracking from Matomo to PostHog or back

This sequence moves tracking and history between Matomo and PostHog in a controlled order, so each team knows what was copied, what was rebuilt by hand and what was left behind. Done well, it leaves one tool as the system of record with a documented fallback.

Inventory tags, events and reports
The analytics owner and a developer list every Matomo site, tag, custom event, goal, ecommerce setup, custom dimension and saved report, then mark which ones the business still uses. Map each Matomo event to a planned PostHog event name and property, and note any consent or cookie behavior that must be reproduced. The step is done when the list is signed off by both the marketing owner and the engineer who maintains the tracking code.
Decide the target volume tier
Before any data moves, the platform owner estimates monthly event volume from current Matomo reports and compares it with PostHog's published tiers and self-host guidance. PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends its Cloud above that, and its self-host docs say the hobby deployment is officially unsupported. Matomo's requirements FAQ gives sizing for up to 1 million and 10 million pageviews a month. The decision is recorded in writing with a named owner for hosting, support and upgrades.
Run both tools in parallel
Deploy the target tool and add its tracking alongside the existing Matomo tag, with both receiving the same pages and events for a fixed observation window agreed in writing. Compare visit counts, key conversions and event totals in a shared spreadsheet, and record each difference with its likely cause, such as bot filtering, consent handling or tag timing. The step closes when the analytics owner signs off that the two sources agree within the tolerance the business accepted.
Import historical data the vendor tool supports
Use only the import paths each vendor documents. PostHog's managed migrations can import historical events from Mixpanel or Amplitude through API credentials, or from JSONL files in an S3 bucket, but each direct import job covers at most one year and events are not deduplicated, so overlapping runs will double count. Historical imports are free of ingestion fees when sent with the historical_migration flag, yet a paid product analytics plan is required, and imported event data cannot be selectively deleted. For Matomo, the Google Analytics Importer brings aggregated report data only. The step is done when row counts and totals for the imported period are reconciled against the source.
Rebuild reports, funnels and segments
Rebuild the dashboards and segments that matter in the target tool, since the Google Analytics Importer does not bring visitor logs, custom reports, ecommerce logs, segmentation or some reports such as funnels. Confirm which items are rebuilt from raw events and which are only available as aggregates. Record any report that cannot be reproduced so stakeholders know the history stops at a given date. The step is complete when each business-critical report has an owner and a matching check.
Confirm consent and privacy settings
The privacy owner reviews the tracking configuration in the target tool before cutover. Matomo's ePrivacy FAQ says that features such as User ID, heatmaps or session recordings can remove a CNIL consent exemption, and PostHog's session replay and feature flags raise similar questions. The review checks what is collected, where it is stored (PostHog Cloud offers US and EU Frankfurt regions) and whether the banner logic matches the configuration. The step closes with a signed record of the settings and the legal basis.
Cut over and plan the fallback
Switch the primary tag and dashboards to the target tool, then keep the source tool running in read-only mode for an agreed retention period. Document the rollback steps, the owner who can trigger them and the export path for any data that must be kept. The step is done when the cutover has a dated runbook, the source is marked as the fallback, and the team confirms that reports and alerts behave as expected.

Where Matomo and PostHog implementations usually run long

Implementation overruns on the Matomo side tend to come from the work around the analytics server, not from the tracking code itself. Hardening the PHP and web server layer, setting up separate application and database servers, and defining backup and restore for the MySQL or MariaDB database all take planning. Plugin selection is the second source of drift: a premium plugin such as the Heatmap and Session Recording plugin is sold under the InnoCraft EULA rather than the GPL, so the licensing review has to happen before the tag manager work starts, not after. Tag manager integration and consent configuration are where projects most often run long. Each new tag, User ID field or recording feature can change the consent position under the ePrivacy rules Matomo describes, so a configuration that was accepted in one review may need a second one. Confirm with your privacy counsel which national authority applies to your audience before fixing the consent settings.

On the PostHog side, the largest overruns usually come from event schema design and from running the self-hosted stack itself. An event taxonomy that changes after launch affects dashboards, feature flags, experiments and any historical comparison, and changes are expensive to unwind because PostHog's documentation notes there is no way to selectively delete event data once imported. Self-hosted operation is the second risk. PostHog's self-host documentation describes self-hosted deployments as officially unsupported, so the team that runs the Docker Compose hobby deployment or any paid self-hosted install owns upgrades, capacity and incident response. Identity integration through SSO, audit logs and custom roles is sold as platform packages, so confirm the package and its entitlements before designing access. Migration validation is the last common overrun: direct imports from Mixpanel or Amplitude cover at most one year per job and are not deduplicated, so reconciliation counts need to be checked against source data before cutover.

Scope and timelines for either platform should be agreed in writing before work starts. DeployOpen plans and implements self-hosted platforms inside your own infrastructure and most engagements are fixed-scope, so the written scope should name the server hardening, backup targets, plugin list, consent decisions, event schema, identity design and migration checks as separate deliverables. Ask any provider to state which changes trigger a scope revision, such as a new event category or a new consent position, and who signs off on each. Quotes follow from that written scope, so the more precisely the taxonomy, consent and migration work is defined up front, the fewer surprises appear in the middle of the project.

Questions buyers ask before choosing Matomo or PostHog

Is Matomo On-Premise really free, and what recurs?

Yes, the On-Premise Community edition is listed as free forever with unlimited users and hits, under GPL-3.0. The license fee is zero, but the recurring costs sit elsewhere: the servers, storage and database that run it, the people who patch PHP, MySQL or MariaDB and apply Matomo upgrades, and any premium plugins you add. The Matomo pricing page lists forum support only for Community, so any paid help is a separate contract. Premium plugins such as Heatmap and Session Recording are sold per number of users under the InnoCraft EULA, with a 30-day free trial. Ask any implementation partner for a written scope that lists which plugins, upgrades and hosting duties are included.

Is PostHog self-hosting supported by the vendor?

Not for the free deployment. 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 under MIT is installed with a deploy-hobby script, and the README says open-source deployments should scale to about 100k events per month before moving to PostHog Cloud. Premium features in the ee directory need a PostHog license on a self-hosted instance, and new Kubernetes deployments of the paid self-hosted product are no longer supported. Confirm with PostHog in writing which support terms, if any, apply to your deployment.

What server size does each tool need at my event volume?

Start from your monthly volume and the vendor sizing guidance. For Matomo, the requirements FAQ sizes a single server with at least 4 CPUs, 8 GB of RAM and 250 GB of SSD for up to 1 million pageviews a month, and recommends separate app and database servers with 8 CPUs and 16 GB of RAM each for up to 10 million pageviews a month. For PostHog, the hobby deployment is recommended on a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage, and PostHog advises moving to Cloud above about 100k events a month. Count pageviews and events separately, since they are not the same unit, and ask for a load test on your own traffic before you buy hardware.

Can we run Matomo or PostHog without outside help?

A team with Linux, web server, database and container skills can run either tool in-house, but the work does not stop at installation. For Matomo, the team must keep PHP, MySQL 8.0 or MariaDB 10.6 (for Matomo 6.0.0) and the web stack current, plan backups and handle upgrades, since Matomo 6.0.0 is still in beta. For PostHog, there is no vendor support on the free deployment, so your team owns every fault and upgrade. If you lack that capacity, a fixed-scope engagement can cover installation, hardening, backup and documentation, with ongoing support available as a retainer. Get the written scope before work starts.

How long does a migration take, and what drives it?

The duration depends on the volume of history, the source tool and how much of the data you need to keep. PostHog's managed migrations import historical events from Mixpanel or Amplitude using API credentials, or from JSONL files in an S3 bucket, and 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. Importing historical events also requires a paid product analytics plan. Matomo's Google Analytics Importer copies only aggregated report data, so Visitor Log, Ecommerce Log, Custom Reports and Segmentation do not work for imported reports, and some reports such as Funnels are not imported. Ask each vendor for the exact limits that apply to your source and retention period before you commit to a schedule.

Which team should own Matomo, and which should own PostHog?

Matomo fits marketing and digital teams that need web analytics reports, campaign tracking, ecommerce and goals, with a platform or IT team running the server. PostHog fits product and engineering teams that need product analytics, session replay, feature flags and experiments tied to their releases. Both may run in the same company, but the cost of running two stacks is real. Assign one owner for hosting, backups and upgrades, and one business owner for the reports. Note that session recording and heatmaps in Matomo are premium plugins, and PostHog's session replay sits in the same suite as its feature flags, so the consent position may differ between them. Confirm the consent and data location requirements with your privacy lead before you decide.

Do the free tiers cover our data retention needs?

Check retention before you commit to a hosted tier. PostHog's pricing page lists a Free plan with 1 project and 1-year data retention, and a Pay-as-you-go plan with 6 projects and 7-year data retention, with the first 1 million analytics events free every month. PostHog Cloud is offered in US (Virginia) and EU (Frankfurt) regions, and SSO, audit logs, custom roles and project permissions are sold as platform packages. Matomo On-Premise has no hit limit, so retention is set by your own storage. Matomo Cloud plans start at 29 (excluding tax) per month for tiers from 50,000 to 10 million hits a month, with data stored in Frankfurt, Germany. Ask each vendor which retention and region terms apply to your contract.

Does Matomo's consent exemption carry over to PostHog?

Not automatically. Matomo's ePrivacy FAQ says France's CNIL recognizes some audience measurement trackers as exempt from consent only when they are limited to purposes such as performance measurement, collect anonymous statistics and exclude marketing measurement. Adding User ID, heatmaps or session recordings removes that exemption. PostHog's product suite includes session replay and feature flags, so a PostHog deployment would need its own legal assessment. Ask your data protection officer to review the configuration, the data location and the processing purpose before you deploy either tool on a consent-free basis.

How DeployOpen helps teams choose, implement or migrate analytics

DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Matomo vs PostHog, we start with the decision you need to make, then scope the work that follows from it, whether that is running Matomo On-Premise, self-hosting PostHog, or moving data between them.

How we scope

We confirm which team owns the tool, which sites and apps need tracking, and which consent rules apply to each.
We size the server and database tiers against your expected pageviews or events, and state which figures must be confirmed with each vendor.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work starts.

How we build

We install and configure the chosen platform in your infrastructure, with the reverse proxy, database and backup settings documented.
Where a migration is in scope, we plan historical imports, record which report types do not carry over, and test the results against a reference set.
We test tracking accuracy, consent configuration and access controls before any production traffic is switched over.

How we hand over

You receive written documentation covering architecture, configuration, upgrade steps and the data flows that involve personal data.
We prepare the evidence your compliance or privacy team needs, while independent auditors remain the ones who issue any audit report.
Operators are walked through routine tasks such as upgrades, backups and restore testing, so your team can run the platform after handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers once the scope closes.
Retainers can cover version upgrades when a new Matomo or PostHog release changes requirements or hosting needs.
Our support covers the platform we deployed, so questions about the vendor's own cloud product go to that vendor.

Matomo vs PostHog