Plausible vs Umami: when to choose each for self-hosting
Choose Plausible Community Edition when your team can run a ClickHouse-backed stack and accepts its release rhythm. The community edition is licensed under AGPL-3.0 and is installed with Docker and Docker Compose, and the repository requires a CPU with SSE 4.2 or NEON support and at least 2 GB of RAM. Plausible publishes Community Edition as a long-term release twice a year, supported by the community only, and security fixes arrive only when your operator applies the release. Choose Umami when you want a lighter footprint on a familiar stack: it is MIT licensed, runs on Node.js (version 18.18 or newer for a source install) and PostgreSQL (supported from version 12.14), and ships a Docker Compose file that bundles PostgreSQL. Umami's MIT license also places fewer obligations on you if you modify the code and offer it to internal users.
The decision turns on four questions. First, data volume: Plausible is built around ClickHouse for analytical queries, so check your expected pageview growth against your team's willingness to operate a columnar database. Second, Plausible-only features: the self-hosted page lists marketing funnels, user journeys, ecommerce revenue goals, single sign-on, the Sites API, the Looker Studio connector and advanced bot filtering as missing from Community Edition, so if any of these are requirements, Umami or a Plausible Cloud subscription must be weighed instead. Third, ClickHouse operations: upgrades, backups and capacity for that database become your responsibility, and you should name an owner before you commit. Fourth, GA4 history: Plausible's wiki documents a Google integration and a GA4 historical import, which imports daily aggregates up to the first native visitor, supports up to 5 GA properties per site and cannot import ecommerce revenue. Confirm whether Umami offers an equivalent import for your data before you assume parity.
Which platform fits which scenario
This table matches common buyer situations to the platform that fits better, and states the condition that makes each choice right. Read each row against your own team, data volume and tooling, since the better fit often flips when one condition changes. Both tools are cookieless and self-hostable, so the decision usually turns on feature needs, database standards and whether a managed option is likely later.
| Scenario | Better fit | Condition that makes it the better fit |
|---|---|---|
| Small team wants the simplest self-hosted install | Umami | The team wants a single Docker Compose file with a bundled PostgreSQL database and no ClickHouse to operate. Plausible Community Edition also runs on Docker, but it needs a CPU with SSE 4.2 or NEON and at least 2 GB of RAM for ClickHouse. |
| Team needs marketing funnels, user journeys or SSO | Plausible | Funnels, user journeys and single sign-on are listed as missing from Community Edition, so these needs point to Plausible Cloud or to Umami only if the team confirms the feature in its current edition. |
| Team migrating historical GA4 data into the new tool | Plausible | Plausible Community Edition documents a GA4 historical import of daily aggregates, up to 5 properties per site, but cannot import ecommerce revenue. Confirm what Umami supports for imports before choosing it for a migration. |
| Platform group already standardizes on PostgreSQL | Umami | Umami runs on PostgreSQL from version 12.14, so it adds no new database engine. Plausible Community Edition adds ClickHouse, which the platform team must patch, back up and monitor separately. |
| Team expects to move to a managed cloud option later | Either, with a trade-off | Plausible Cloud plans and Community Edition data export and import to Cloud make a later move straightforward. Umami Cloud offers a similar path, but confirm its data import process before committing. |
| Team needs security updates without a long wait | Umami | Umami publishes releases on its GitHub releases page at a frequent cadence. Plausible Community Edition is a long-term release published twice per year and gets security fixes only when the operator applies them. |
| Team needs ecommerce revenue goals or the Looker Studio connector | Plausible | Ecommerce revenue goals and the Looker Studio connector are listed as Cloud-only, so self-hosted Plausible cannot meet these needs. Confirm whether Umami offers equivalent reporting in its self-hosted build. |
How each platform is built and what that means for operations
Both tools are self-hosted analytics products with cookieless tracking, but they ask for different runtime stacks and different amounts of day-to-day attention. The cards below describe the components each team would install and maintain, and what each component means for upgrades, backups and patching.
Plausible Community Edition stack
Plausible Community Edition runs on Docker and Docker Compose, and its repository requires a CPU with SSE 4.2 or NEON support because ClickHouse depends on those instruction sets. The stack also needs at least 2 GB of RAM. Before you commit, confirm that your hypervisor or cloud instance type exposes those CPU flags, since a host that lacks them will fail at the database layer rather than at install time. ClickHouse is a columnar database, so plan for its storage growth as pageview volume rises.
Umami stack and deployment options
Umami runs on Node.js, and a source install requires Node.js 18.18 or newer. It stores data in PostgreSQL, which Umami supports from version 12.14. For most teams the faster path is the prebuilt Docker image and the Docker Compose file, which starts Umami with a bundled PostgreSQL database. Teams that already run a managed PostgreSQL service should decide early whether to use the bundled database or point Umami at their own instance, because that choice determines who handles database backups and version upgrades.
Who runs upgrades and backups
On both platforms the operator carries the work. Plausible states that Community Edition operators manage installation, upgrades, capacity, uptime, backups and security themselves. Umami's self-hosted model places the same responsibilities on your team, and the Cloud plans are the only path where the vendor runs the service. Before choosing, ask who owns the ClickHouse or PostgreSQL backup and restore test, who schedules upgrades across Docker images, and who is on call when ingestion stops. Written answers to those questions matter more than the install guide.
Security patching under each release model
Plausible Community Edition is published as a long-term release twice per year, is supported by the community only, and receives security fixes only when the operator applies the release. Plausible Cloud ships updates multiple times per week. Its v3.2.1 security release on May 15, 2026 shows why this matters: a self-hosted team must watch the releases page and apply fixes promptly. Umami publishes frequent versioned releases, including v3.4.0 on September 17, 2026, so the patch cadence is driven by your own monitoring and change process in either case.
Plausible vs Umami feature by feature
This table compares the two analytics tools on license, database, resource needs, release delivery, cloud-only features and Google data import. Read the Umami cells as items to confirm with Umami directly where no researched fact exists. The main takeaway is that Plausible Community Edition asks for ClickHouse and a slower security update path, while Umami self-hosts on PostgreSQL with a faster release cadence but fewer documented import paths.
| Capability | Plausible Community Edition | Umami (self-hosted) |
|---|---|---|
| License | AGPLv3 or any later version | MIT |
| Database | ClickHouse, required for the analytics store | PostgreSQL, supported from version 12.14 |
| Minimum resources | Docker and Docker Compose, SSE 4.2 or NEON CPU support, at least 2 GB RAM | Node.js 18.18 or newer for source installs; Docker image with bundled PostgreSQL available |
| Release cadence | Long-term release published twice per year | Frequent named releases, for example v3.3.0, v3.3.1 and v3.4.0 in August and September 2026 |
| Security fix delivery | Fixes arrive only when the operator applies the release (for example v3.2.1, May 15, 2026) | Operator applies new releases; confirm the fix policy and notification process with Umami |
| Cloud-only features | Marketing funnels, user journeys, ecommerce revenue goals, SSO, Sites API, Looker Studio connector, advanced bot filtering | Email reports and streaming API on Umami Cloud; confirm the full list on the pricing page |
| Google Analytics import | Imports historical GA4 data as daily aggregates up to the first native visitor; up to 5 GA properties per site; no ecommerce revenue | Not stated in the researched facts; confirm import support and limits with Umami before planning a migration |
| Google Search Console data | Available through a Google integration configured with GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET | Not stated in the researched facts; confirm with Umami whether an equivalent exists |
| Email reports or streaming API | Not listed as available in Community Edition | Listed as Umami Cloud features the self-hosted version lacks; confirm the self-hosted status with Umami |
What the license and editions mean for each platform
Plausible Community Edition is open source under the GNU Affero General Public License v3 (AGPLv3) or any later version. You can run it in your own infrastructure without a license fee, but you own installation, upgrades, capacity, uptime, backups and security. Plausible's self-hosted page describes Community Edition as a long-term release published twice per year, supported by the community only, and it receives security fixes only when you apply the release.
- Features missing from Community Edition: Marketing funnels, user journeys, ecommerce revenue goals, single sign-on, the Sites API, the Looker Studio connector and advanced bot filtering are available only in Plausible Cloud. If your reporting depends on any of them, self-hosting will not provide them.
- Community-only support: No vendor support is included. Support comes from the community, your own team or a partner you contract with.
- Patch ownership: Plausible published v3.2.1 as a security release on May 15, 2026. Your team must track and apply releases like this one.
- AGPL obligations for modified code: If you modify the code and users interact with the modified version over a network, the AGPL generally requires you to offer those users the corresponding source of your changes. Confirm the scope of this obligation with counsel before you customize.
- Data movement: Community Edition users can export and import data to and from Plausible Cloud, which keeps a later move between editions possible.
Before you commit, confirm with Plausible which features your reporting requires and which edition provides them.
Plausible Cloud is the hosted service from the same project, and it contains the features that Community Edition leaves out. Plausible's homepage lists published plans for 10,000 monthly pageviews, with Starter at $9 per month, Growth at $14 and Business at $19. Enterprise pricing is custom, and the site offers a 30-day free trial with no credit card required. Plausible's homepage also describes the service as made and hosted in the EU.
- Published plans: Starter, Growth and Business are priced at $9, $14 and $19 per month for 10,000 monthly pageviews, according to Plausible's homepage. Higher volumes and Enterprise require a quote.
- Free trial: The 30-day trial requires no credit card, so you can test Cloud-only features such as funnels and SSO before you choose a plan.
- Cloud-only features: Funnels, user journeys, ecommerce revenue goals, SSO, the Sites API, the Looker Studio connector and advanced bot filtering are available here.
- Update cadence: Plausible says Cloud ships updates multiple times per week, so the provider handles most patching and operations.
- Hosting location: Plausible describes the service as made and hosted in the EU. If you have data residency requirements, get the hosting terms in writing.
Check which pageview volume your site reaches, because the published figures apply to 10,000 pageviews per month and costs rise above that level.
Umami is licensed under the MIT license, and Umami's pricing page states that it is open source and can be self-hosted for free. The software is a privacy-first analytics platform that works without cookies, cross-site tracking or the automatic collection of personal data. Your costs are the infrastructure to run it, the database and the staff time to operate it, rather than a license fee.
- Permissive license: MIT allows you to use, modify and redistribute the code, including commercially, as long as you keep the copyright and license notice. It does not carry a network source-sharing requirement like the AGPL.
- Runtime requirements: A source install requires Node.js 18.18 or newer, and Umami supports PostgreSQL from version 12.14.
- Install paths: Umami publishes a prebuilt Docker image and a Docker Compose file that starts Umami with a bundled PostgreSQL database. The bundled database simplifies setup, but you still own backups and upgrades.
- Feature gap: Email reports and a streaming API are features that Umami Cloud offers and the self-hosted version lacks.
- Operating responsibility: You manage the application, database, updates and security configuration yourself, and you should document who does this.
Before you pin a version, review the release history on GitHub, including v3.4.0 published on September 17, 2026, and confirm the database version against your own security standards.
Umami Cloud is the hosted service from the Umami project. It adds features the self-hosted version lacks, including email reports and a streaming API, and its pricing page sets event caps and retention limits for each tier. Umami meters usage in events rather than pageviews, so your event volume determines which tier fits.
- Hobby tier: $0 per month for up to 100K events with 6 months of retention.
- Pro tier: $20 per month for 1 million events with 2 years of retention.
- Business tier: $200 per month for 10 million events with 5 years of retention. Longer retention matters if you compare year-over-year trends.
- Overage charges: The pricing page lists $0.00003 per extra event on Pro and $0.00002 per extra event on Business.
- Enterprise: Custom pricing and custom retention are available on request, so ask for them in writing.
Model your monthly event count, not your pageview count, against each tier, and confirm how Umami counts events before you commit to a plan.
How Google Analytics history moves into each platform
Plausible has a documented Google Analytics import, and the limits matter more than the import itself. According to Plausible's import documentation, it brings historical GA4 stats in as daily aggregates, only up to the first native Plausible visitor, so history and live data meet at a single boundary. It supports up to 5 GA properties per site, cannot import ecommerce revenue, and approximates unique visitors by summing daily uniques. A summed daily unique count can overstate visitors over long ranges when the same person returns on several days, so reports that compare imported months with native months need a clear note. If you run ecommerce reporting on GA, plan to keep revenue history in GA or an export rather than expecting it in Plausible.
On the self-hosted side, the Community Edition wiki documents a Google integration configured with the GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET settings. Per that wiki, this integration enables Search Console keyword data and GA4 historical import from the site's Imports and Exports settings. Your operator needs a Google OAuth client that you control, the correct redirect configuration for your own domain, and a named owner for those credentials, since rotating or losing them stops the import path. Confirm the current OAuth setup steps against the wiki before deployment, because the redirect details depend on how your instance is exposed.
For Umami, this review did not establish a supported historical import path from GA, and you should confirm it directly with Umami before planning a migration. Ask specifically whether a GA import exists, which GA versions and properties it covers, how it aggregates daily, hourly or session data, and how it estimates unique visitors. Whatever the answer, test with a copy of real data before cutover: export a representative month from GA, load it into a staging instance of each candidate, and compare totals, unique visitor counts and top pages against the GA source. Agree on an acceptable variance in writing with the stakeholders who use those reports.
What drives the running cost of each platform
Running cost for Plausible and Umami comes from the same four places: the hosting footprint, the people who keep it alive, the upgrade rhythm, and whether a paid cloud tier makes more sense than self-hosting. The cards below cover each one and the questions to settle before comparing totals.
Infrastructure footprint and event volume
Plausible Community Edition runs on Docker with ClickHouse, and its repository requires a CPU with SSE 4.2 or NEON support and at least 2 GB of RAM. Umami runs on Node.js with PostgreSQL, and its Docker Compose file starts a bundled PostgreSQL database. The database choice shapes the server size, so ask both vendors for sizing at your expected pageview or event volume, retention period and peak traffic, and benchmark both on a copy of your real data before committing.
Staff skills and on-call effort
Plausible Community Edition operators manage installation, upgrades, capacity, uptime, backups and security themselves, so the team needs Docker, ClickHouse and backup skills in-house. Umami's self-hosted path leans on Node.js and PostgreSQL, which many platform teams already run. The recurring cost is the person-hours for on-call response, and it is usually larger than the server bill. Ask who holds these skills, who is paged at 2 a.m., and whether a partner will cover that rota under a retainer.
Upgrades and security patching cadence
Plausible Community Edition is a long-term release published twice per year, is community supported only, and receives security fixes only when the operator applies the release. Umami shipped v3.3.0 on August 12, v3.3.1 on August 20 and v3.4.0 on September 17, 2026, so its release rhythm is far more frequent. Faster releases mean more upgrade windows to test, but they also bring fixes sooner. Budget regular patch testing for either platform and confirm the upgrade path with the maintainers before you go live.
Paid cloud tiers and overage
Plausible Cloud starts at $9 per month for 10k pageviews on Starter, $14 on Growth and $19 on Business, with custom Enterprise pricing. Umami Cloud Hobby is $0 for up to 100K events, Pro is $20 for 1 million events and Business is $200 for 10 million events, with overage at $0.00003 per extra event on Pro and $0.00002 on Business. Compare the cloud bill for your real volume against your self-hosted server and staff cost. Cloud also adds features such as email reports on Umami and funnels on Plausible, so check whether you need them.
Moving from one platform to the other
This sequence moves a site's measurement from Plausible to Umami or back again while keeping the history that matters and avoiding a gap in reporting. Each step ends with a check you can record before moving on.
Define the event schema and retention needs
Start by listing every pageview, custom event, goal and campaign parameter you rely on, along with how long each site's history must stay available. Umami's pricing page ties retention and event volume to plan tiers, so the retention you need decides whether a managed or self-hosted option fits. Your analytics owner and a developer should sign off on this list. It is done when each site has a written inventory of events, properties and retention periods that the destination platform can support.
Confirm export and import formats with each vendor
Before planning any data movement, ask each vendor what it can export, in which format, and whether the target accepts it. The supplied facts confirm that Plausible Community Edition users can export and import data to and from Plausible Cloud, but they do not establish a generic export path from Plausible to Umami or from Umami to Plausible. Get the answers in writing and test them on a copy of a small site. It is done when you have a documented export format and a successful test import.
Export and map historical data
Run the supported export for each site and map its fields to the destination's model. Expect that some history may not transfer in a like-for-like form. Plausible's Google Analytics import documentation, for example, describes daily aggregates and approximated unique visitors, so treat imported history as a separate, labeled data set rather than a perfect continuation. Your analyst should record which periods and metrics transferred intact. It is done when a mapping document shows each data set, its destination and any known differences.
Rebuild dashboards, goals and funnels
Recreate the dashboards, goals, funnels and custom reports that do not transfer automatically. Feature sets differ between the two tools, so some reports may need a different construction or may not be available at all. Plausible's self-hosted page lists features absent from Community Edition, such as funnels and ecommerce revenue goals, which you should check against your reports. Assign an owner for each report and compare the rebuilt versions with the originals using the same date range. It is done when every report in the inventory has a rebuilt counterpart or a recorded decision to drop it.
Update tracking scripts on each site
Replace or add the tracking snippet on each site, along with any custom event calls that reference the old tool. Have a developer test in a staging environment and confirm that pageviews and custom events arrive with the expected names and properties. Check that the new script respects your consent setup, since both tools are described as cookieless but your legal team should confirm the configuration for your jurisdiction. It is done when test events appear in the destination with the correct names and no duplicate counts.
Run both platforms in parallel
Keep the existing tracking active alongside the new one for a period agreed by the analytics owner. During this window, compare totals for pageviews, visitors and key events on each site and investigate any gap that exceeds the tolerance you set in step one. Differences in how the two tools define visitors and sessions are expected, so document them rather than forcing the numbers to match. It is done when the team signs off that the variance is explained and within agreed tolerance for each site.
Cut over and retire the old platform
Switch dashboards, alerts and any reporting references to the new platform, then remove the old tracking script from every site. Keep the exported archive and the mapping document in a controlled location so historical questions can still be answered. For self-hosted installs, confirm who is responsible for backups, upgrades and security patches on the platform you are retiring, and decommission it only after the archive is verified. It is done when the old script is gone from all sites, the archive is verified, and the owner of the new platform has accepted the handover.
Where self-hosted analytics projects usually run long
Self-hosted analytics projects rarely stall on installation. They run long on the parts around it: sizing the database, scheduling upgrades and getting the tracking script onto every site. Plausible Community Edition needs Docker, Docker Compose, a CPU with SSE 4.2 or NEON support for ClickHouse, and at least 2 GB of RAM, but the RAM figure is a floor, not a capacity plan. Ask the team to estimate pageview volume per site and retention needs before provisioning, and to tune ClickHouse storage and memory limits against a staging copy with realistic traffic. Umami runs on Node.js 18.18 or newer and PostgreSQL 12.14 or newer, with a Docker Compose file that starts a bundled PostgreSQL database. That is a more familiar stack for most operations teams, but it still needs a sizing decision, backup schedule and monitoring for the database. Either way, DeployOpen scopes host provisioning, TLS, the reverse proxy, backups, monitoring and tracking-script rollout in writing before any work starts, so the boundaries are agreed up front.
The Plausible upgrade cycle is the most predictable source of delay. Plausible's self-hosted page describes Community Edition as a long-term release published twice per year, supported by the community only, with security fixes arriving only when the operator applies a release. The v3.2.1 security release on May 15, 2026 shows why that window matters. Plan a standing upgrade slot, test the ClickHouse migration on a copy of the data, and confirm who approves production changes. Umami ships more frequently; its v3.4.0 release was published on September 17, 2026, so expect a steadier, smaller change flow and budget time for it as an ongoing task. Consent and privacy review still applies to both tools. Cookieless design usually removes the banner requirement, but the data processing record, retention settings and any Google integration still need legal sign-off. The Google step is the one most likely to slip. Plausible's GA4 import brings in daily aggregates only up to the first native visitor, cannot import ecommerce revenue, and approximates unique visitors by summing daily uniques. Map GA4 events to Plausible goals and Umami events before the cutover, and confirm with the vendor how each will be reported.
How much does self-hosting Plausible or Umami cost and what effort does it need?
What does it cost to self-host Plausible or Umami if the license is free?
Both self-hosted editions carry no license fee, so the cost is the infrastructure you run them on, the staff time to install, upgrade and back them up, and any outside support you buy. Plausible Community Edition requires Docker, Docker Compose, a CPU with SSE 4.2 or NEON support for ClickHouse, and at least 2 GB of RAM. Umami runs on Node.js and PostgreSQL, and its source install requires Node.js 18.18 or newer. Infrastructure is recurring, while setup is largely one-time. Ask any provider for a written quote that separates the one-time install from the recurring monthly support, upgrades and testing, and that states which hosting assumptions it depends on.
How long does a basic Plausible or Umami install take?
The duration depends mostly on how much of the environment already exists and how many sites and environments you need. A team with Docker, a PostgreSQL service, DNS and a TLS certificate process in place will move faster than one building those from scratch. Plausible's stack includes ClickHouse, so you also need to plan its storage and memory sizing. Umami can be started from a prebuilt Docker image and a Compose file that bundles PostgreSQL, which shortens the first run but still leaves backups, monitoring and hardening to do. No fixed duration is supplied here, so ask for a timeline tied to a written scope that lists each component and environment.
What skills does an internal team need to run Plausible or Umami?
Plausible needs people comfortable with Docker and Docker Compose, Linux host administration and the operation of ClickHouse, which is a different database from the one most application teams run. Umami needs Node.js build and runtime knowledge and PostgreSQL operations, including backups, upgrades and connection management. Both need DNS records and TLS certificates for the analytics hostname, and both need a reverse proxy or equivalent in front of the application. Name an owner for each area in your plan. If those skills are thin, the gap should appear in the scope and the handover documentation, not surface during an incident.
Can a small team run self-hosted Plausible or Umami alone?
A small team with one person who knows Linux, containers and databases can run Umami for a modest site count, provided that person has time for upgrades and backups. Plausible Community Edition is workable for a small team too, but it adds ClickHouse and it gets security fixes only when the operator applies a release. Its published release cadence is twice per year, so a missed upgrade can leave a gap. Plan for a named backup operator, a patching routine and an escalation path. Community support is the only support Plausible Community Edition lists, so for a team without spare capacity, a retainer or a documented handover from an implementation partner may be the more reliable choice.
When is a managed cloud tier cheaper to operate than self-hosting?
A managed tier tends to be cheaper when the internal labor to run the stack costs more than the subscription, or when no one can own uptime, backups and security patches. Plausible Cloud lists Starter at $9 per month for 10k monthly pageviews, Growth at $14 and Business at $19, with custom Enterprise pricing, according to its homepage. Umami Cloud lists Hobby at $0 per month for up to 100K events with 6 months of retention, Pro at $20 per month for 1 million events and Business at $200 per month for 10 million events, according to its pricing page. Compare those figures with your fully loaded operating cost, and check which features only the cloud tier offers before deciding.
How does switching from self-hosting to a cloud tier affect the cost later?
Switching later involves export work, a parallel run and a cut-over window, and each adds staff time. Plausible's self-hosted documentation says Community Edition users can export and import data to and from Plausible Cloud, so that path exists, but confirm the scope of what moves. Umami's self-hosted and cloud editions both store event data, and retention limits on the cloud plans affect how much history you can carry across. Ask any partner to price the migration as a separate written item, including validation of historical counts, and to state what happens to tracking scripts and dashboards during the change.
How DeployOpen helps you choose and run either platform
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Plausible vs Umami, we start from your traffic, privacy and hosting constraints, then build and hand over the install you actually choose.
How we scope
- Confirm which events, pageviews and sites you need to measure and how long you must keep them.
- Document the hosting target, including whether ClickHouse or PostgreSQL fits your database standards.
- Agree deliverables, timelines and responsibilities in writing before any work starts, as fixed-scope engagements.
How we build
- Install the chosen platform in your environment with Docker, backups, TLS and access controls configured.
- Test tracking script placement, consent posture and data flows against the scope you agreed.
- Assess whether any Google Analytics history import or Cloud-only feature changes the design before build.
How we hand over
- Deliver runbooks covering upgrade steps, backup and restore tests, and capacity checks for your install.
- Document configuration, admin accounts and the evidence your compliance team may need for review.
- Walk your operations team through monitoring, incident steps and how to apply future security releases.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan release reviews around each platform's published release cadence and support windows you confirm.
- Confirm with the vendor which features your edition includes before committing to a long-term design.
