When is Plausible Community Edition enough, and when does Plausible Cloud make sense?
Choose Plausible Community Edition when the rule that analytics data must stay in your own infrastructure outweighs the features that only Plausible Cloud includes. Choose Plausible Cloud when your team wants the full feature set and does not want to operate the stack. The deciding question is whether your team can absorb the operating work the Community Edition leaves to you: installation, upgrades, capacity, uptime, backups and security. If it cannot, the Cloud plans are the simpler route, and the self-hosted build is a poor fit regardless of licensing.
Community Edition is a reasonable fit when your reports only need core pageview analytics and you can live without the documented gaps. Plausible's 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 absent from Community Edition. Check each of these against what your marketing, finance and identity teams actually request before you commit. If single sign-on is a hard requirement, or if revenue reporting drives budget decisions, the Cloud edition is the safer choice. The edition also ships as a long-term release twice per year and receives community-only support, so security fixes arrive only when your operators apply the release.
Plausible Cloud makes more sense when you need the paid features, when you cannot staff on-call coverage for a Docker and ClickHouse stack, or when you need security updates to reach production within days rather than on your own schedule. Cloud ships updates multiple times per week, and its plans are published by pageview volume, starting at 10k monthly pageviews. Ask for a quote from Plausible for Enterprise pricing if your volume is above those tiers. Before you decide, confirm with the vendor how data export and import to and from the Cloud works for your site, because the self-hosted page states that this path exists and your switching cost depends on it.
Which features does the Community Edition leave out?
This table compares the features Plausible's self-hosted page lists as missing from Community Edition with Plausible Cloud, plus the Google integration and GA4 import limits. Read a check mark as available in Cloud and a cross as missing from Community Edition, and confirm current status on the vendor's page before you decide. The main takeaway is that the gaps are feature gaps, not data gaps, so a team that needs any of these should price in either a workaround or the Cloud service.
| Capability | Plausible Community Edition | Plausible Cloud |
|---|---|---|
| Marketing funnels | No | Yes |
| User journeys | No | Yes |
| Ecommerce revenue goals | No | Yes |
| Single sign-on | No | Yes |
| Sites API | No | Yes |
| Looker Studio connector | No | Yes |
| Advanced bot filtering | No | Yes |
| Google integration (Search Console keywords, GA4 import) | Configured with GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET from the Imports and Exports settings | Confirm current Google integration availability with Plausible |
| GA4 historical import limits | Daily aggregates up to the first native visitor, up to 5 GA properties per site, no ecommerce revenue import | Confirm import terms with Plausible before migrating |
How licensing, support and updates differ between the two editions
The two editions differ less in code than in who carries the operational risk. Community Edition gives you the AGPLv3 code and a release you must install yourself, while Cloud moves patching and upgrades to Plausible. The cards below cover what each difference means for a team deciding who applies fixes and when.
AGPLv3 licence terms
Community Edition is open source under the GNU Affero General Public License v3 or any later version. The AGPL's network clause matters if you modify Plausible and let users interact with the modified version over a network, so your legal team should review how your changes are shared. Cloud is a hosted service, so its licence terms are a contract with Plausible rather than a code licence you exercise yourself. Confirm both with counsel before you build on either.
Long-term twice-yearly releases
Community Edition is published as a long-term release twice per year. You get a stable target to plan around, but new features and fixes arrive in batches rather than continuously. Schedule an upgrade window at least once each cycle, and track the release notes so you know which changes touch your ClickHouse or Docker setup. Ask Plausible to confirm the support period for each release line before you commit.
Community-only support
Community Edition is supported by the community only. There is no vendor support contract to call when an upgrade breaks a dashboard or an ingestion pipeline stalls. Your team, or a partner you contract, must diagnose issues from public channels and the repository. Budget for that internal or external effort, and ask any implementation partner which support responsibilities they will take on in writing.
Security fixes depend on your patching
Community Edition only receives security fixes when the operator applies the release. A vulnerability fixed upstream stays open in your deployment until someone pulls the new image and restarts the stack. Document who monitors the releases page, who approves changes, and how fast a security release is rolled out. Cloud receives its updates without this step.
Why patch timing matters
Plausible published Community Edition v3.2.1 as a security release on May 15, 2026, following v3.2.0 on January 26, 2026. An illustrative case: a team that reads the release notes in a monthly review could run the patched version weeks after publication, while a team with an alert on the releases feed could schedule it within days. Measure your own gap between publication and deployment, and set an internal target for security releases.
Cloud's continuous update model
Plausible Cloud ships updates multiple times per week, so fixes and features reach your analytics without a scheduled upgrade. The trade-off is that you accept changes on Plausible's timeline, and you cannot hold a version for a compliance review. If your change control requires advance notice or a frozen version, confirm with Plausible how updates are announced and whether any pinning option exists.
What running Community Edition demands from your team
Choosing Community Edition means your team takes on the operator role that Plausible Cloud otherwise covers. Plausible's self-hosted page says Community Edition operators manage installation, upgrades, capacity, uptime, backups and security themselves. In practice, that is a standing workload: someone must own the Docker Compose stack, apply each long-term release when it ships, watch the containers and the ClickHouse database for capacity problems, test and restore backups, and track security fixes. Before you commit, name an owner for each of those six areas and confirm who covers them during holidays and on-call rotations.
The repository's stated requirements are a starting point, not a sizing plan. The community-edition repository requires Docker and Docker Compose, a CPU supporting SSE 4.2 or NEON (which ClickHouse needs), and at least 2 GB of RAM. Treat 2 GB as the floor for a lab or very small site. Real capacity depends on your monthly pageviews, how many sites you track, how long you retain event data, and how many dashboard queries run at once. Ask Plausible which hardware profile they expect for your traffic range, and run a load test with your own event volume before you pick a server size.
Security deserves a separate check because it has a timing dependency. Plausible's self-hosted page says Community Edition gets security fixes only when the operator applies the release. The v3.2.1 security release, published on May 15, 2026, is an example of why the release calendar matters. Set a patch window, subscribe to the plausible/analytics GitHub releases feed, and record how quickly you can apply a security build. Compare that with Cloud, which ships updates multiple times per week and removes that patch decision from your team.
Which edition fits which team?
When policy requires that analytics data stay inside your own cloud account, data center or network, Community Edition is the edition that meets that requirement, because the data is stored on infrastructure you operate. Plausible Cloud is hosted by the vendor, and its homepage describes the service as made and hosted in the EU, which may satisfy some residency rules but does not place data inside your own boundary. The trade-off is operational: your team installs, upgrades, sizes, backs up and secures the stack.
- Hosting footprint: The repository requires Docker, Docker Compose, a CPU with SSE 4.2 or NEON (needed by ClickHouse) and at least 2 GB of RAM.
- Patch timing: Community Edition gets security fixes only when you apply the release, so your patch process sets your exposure window.
- Support model: Support is community-only, so plan internal or contracted operations capacity before go-live.
- Feature gap: Funnels, SSO and the Sites API remain Cloud-only, so confirm they are not required.
The answer changes if your policy allows a vendor-hosted EU service with a contractual data processing arrangement. Confirm the exact residency wording with your legal and privacy teams before choosing.
A small site that needs pageview counts, referrers, top pages and goal tracking usually does not need to run its own infrastructure. Plausible Cloud's published plans start at 10k monthly pageviews for $9 per month on the Starter plan, with a 30-day free trial that requires no credit card. For a team with no spare operations capacity, this is the lower-effort path, since upgrades, backups and capacity are handled by the vendor, and Cloud ships updates multiple times per week.
- Predictable cost: Cloud cost is a subscription tied to pageview volume, so check the plan for your traffic level before committing.
- Low effort: Nothing to install, patch or back up.
- Faster fixes: Cloud receives updates continuously, while Community Edition depends on your release schedule.
- Trial first: Use the free trial to confirm the reports cover your questions.
The answer changes if your traffic grows beyond the plan limits, or if a no-operations model conflicts with your hosting rules. Confirm current plan limits and pricing on the vendor's pricing page, because these figures may change.
Teams that need marketing funnels, user journeys or ecommerce revenue goals will find these only in Plausible Cloud. Community Edition's self-hosted page lists marketing funnels, user journeys and ecommerce revenue goals among the features missing from the community build. If revenue attribution is part of the question, Cloud is the edition to evaluate, and a self-hosted install cannot close that gap by configuration alone.
- Cloud-only reports: Funnels, user journeys and ecommerce revenue goals are not part of Community Edition.
- Historical imports: Google Analytics import cannot bring over ecommerce revenue, so historical revenue data will not carry across.
- Self-hosted alternatives: Confirm with the project whether any of these features are planned for the community build before relying on them.
- Mixed setup: Some teams keep Community Edition for raw traffic and use Cloud for revenue reporting, but this doubles the places data lives.
The answer changes if your reporting needs are limited to pageviews and simple goals, since Community Edition may then cover them. Confirm your required reports against the feature list before deciding.
Organizations that must sign users in through a central identity provider should check single sign-on early, because it is listed as a Cloud-only feature. Community Edition's self-hosted page lists single sign-on among the features missing from the community build. A team that depends on SSO for access control and offboarding would need Cloud, or would need to accept access managed outside the identity provider.
- Access control: SSO is not available in Community Edition, so account lifecycle must be managed locally.
- Sites API: The Sites API is also Cloud-only, which affects automation for user and site management.
- Looker Studio: The Looker Studio connector is Cloud-only, so BI reporting may need a different route.
- Compliance evidence: Local accounts need documented review and removal processes that an auditor can test.
The answer changes if your identity requirement is met by network-level access controls or a reverse proxy in front of the community install. Confirm with your identity team how access will be enforced, and verify Cloud plan terms for SSO before purchase.
What each edition costs to run
This table separates the cost components of Plausible Community Edition from those of Plausible Cloud, showing who is paid for each one and whether it recurs. Read the Cloud rows for published list prices and the Community Edition rows for the staffing and infrastructure you carry yourself.
| Cost component | Community Edition | Plausible Cloud |
|---|---|---|
| Software license fee | None. Community Edition is licensed under AGPLv3 or any later version, so there is no license subscription to buy. | Subscription. Published plans start at $9 per month (Starter) for 10k monthly pageviews, per Plausible's homepage and pricing page. |
| Pricing basis | Not applicable. Your cost tracks the servers, storage and people you commit to the deployment. | Scales with monthly pageviews. Published tiers are Starter at $9, Growth at $14 and Business at $19 per month, all at the 10k pageview level. Higher volumes need a custom quote. |
| Infrastructure and hosting | Recurring. You provision Docker and Docker Compose hosts with at least 2 GB of RAM and a CPU supporting SSE 4.2 or NEON for ClickHouse. Sizing grows with traffic. | Included in the subscription. Plausible hosts the service, so you do not provision servers or storage for analytics. |
| Staff time for upgrades | Recurring. Your team applies each twice-yearly release and the security fixes that arrive with it, such as v3.2.1 on May 15, 2026. | Included. Plausible Cloud ships updates multiple times per week, so you do not schedule upgrade windows. |
| Backups, uptime and capacity | Recurring. Your operators own backups, uptime monitoring and capacity planning for ClickHouse and the application. | Included in the plan, managed by Plausible. Confirm the backup and recovery terms in writing before you rely on them. |
| Premium features | Not available in Community Edition, including funnels, ecommerce revenue goals, SSO and the Sites API. | Included in paid Cloud plans where the feature is offered. Check the plan tier that includes each feature you need. |
| Trial and entry cost | No trial applies. Cost starts with the first server and the time to install and test the stack. | A 30-day free trial with no credit card required is offered before you pay. |
| Enterprise and self-hosted quotes | Ask for a written scope covering infrastructure sizing, support expectations and the staff hours you will carry. | Custom Enterprise pricing is quoted separately. Ask for written terms covering support, data handling and any feature scope. |
How do you move data between Community Edition and Plausible Cloud?
The sequence moves historical Community Edition data into Plausible Cloud, ends with a verified import and a tracking script that sends new events to Cloud, and keeps the limits of each step visible. Plausible's self-hosted page confirms that Community Edition users can export and import data to and from Plausible Cloud. Field-level compatibility and feature handling are points to confirm with Plausible, so the checks below cover them explicitly.
Confirm the transfer path with Plausible
Start by reading the export and import section of Plausible's self-hosted page, then ask Plausible to confirm in writing three things: whether the export format is accepted by Plausible Cloud, which Community Edition data types carry across, and how features missing from the target edition, such as funnels, ecommerce revenue goals and the Sites API, are handled. Your team owns this step. The output is a written answer you can file with the migration record.
Inventory sites, goals and imports
List every site in Community Edition, its goals, and any Google data already brought in through the Imports and Exports settings. Note which sites use ecommerce revenue goals, because the Google Analytics import cannot carry that revenue, and which sites depend on the Google integration for Search Console keyword data, which you must confirm can move. Mark each site as move, rebuild or retire. The output is a site register that the cutover plan references.
Export data from Community Edition
Run the export from the Community Edition instance using the path Plausible documents for moving data to Plausible Cloud. Confirm with Plausible whether exports run per site or per instance, and make sure each archive maps to one target site. Store the files in an encrypted location with access limited to the migration team, and record each file's size and checksum beside its site name. Your operators, or a DeployOpen engineer under the written scope, run this step inside your infrastructure. It is done when every site has an archive and a matching manifest entry.
Validate the archives against a staging target
Import the archives into a non-production Plausible Cloud site, which you can set up during the 30-day free trial that Plausible's homepage lists with no credit card required. Compare the result with the source for a sample date range, checking pageview totals, top pages, referral sources, goal conversions and the first and last dates of the range. Ask Plausible to confirm how unique visitor counts are recalculated after import, and record each difference in the register. Done means every check has a signed result or a documented gap.
Import the validated archives into Cloud
Once the staging comparison is accepted, import the same archives into the production Cloud sites in the same order you validated them. Confirm with Plausible how any feature the target lacks or treats differently will behave, and note any data that does not survive the move. Keep the source archives unchanged so the import can be repeated if a check fails. Done means each production site shows the expected historical range and the register lists every known gap.
Set limits for Google Analytics history
If you need Google Analytics history, use Plausible's Google Analytics import documentation to plan it and treat the imported figures as a separate series. According to that documentation, historical GA4 stats arrive as daily aggregates up to the first native Plausible visitor, a site supports up to 5 GA properties, ecommerce revenue cannot be imported, and unique visitors are approximated by summing daily uniques. Record these limits in the register and tell stakeholders which reports show approximations. Done means stakeholders have signed off the reports that use imported GA data.
Cut over the tracking script
Update the tracking script on each site to point at its Plausible Cloud site, deploy the change through your normal release process, and confirm that events appear in Cloud before you remove the Community Edition snippet. Keep the self-hosted instance available for reference for as long as your retention policy requires. Confirm with Plausible how events sent to the old instance will be handled during that period. Done means live traffic from each site appears in Cloud and the old snippet is gone from every page.
What do buyers ask before choosing an edition?
What does running Plausible Community Edition cost compared with Cloud?
The software itself is free under the AGPLv3, so your costs are the infrastructure and the people who run it. The repository requires Docker and Docker Compose, a CPU with SSE 4.2 or NEON (required by ClickHouse), and at least 2 GB of RAM as a minimum, so the server or virtual machine is the main recurring line item. Costs rise with pageview volume, data retention, the number of sites, backup storage, uptime targets and staff time. Plausible's homepage lists Cloud plans at $9, $14 and $19 per month for 10k monthly pageviews, with custom Enterprise pricing. For a quote, ask for a sizing estimate based on your own traffic and a monthly breakdown of compute, storage, backups and operator hours.
How much time do upgrades and backups take my team?
Community Edition operators handle installation, upgrades, capacity, uptime, backups and security themselves. Plausible publishes a long-term release twice per year and sends security fixes only when you apply the release. The security release v3.2.1 on May 15, 2026 followed v3.2.0 on January 26, 2026, which shows the kind of update you will need to plan for. No supplied source gives a duration for an upgrade or a backup restore, so ask Plausible for its upgrade procedure and test the full cycle on a staging copy before you commit. Confirm which volumes, including ClickHouse data and configuration, your backup job must capture, and time a complete restore, not just a backup.
Can a team run Plausible Community Edition without outside help?
A team can run it alone if it has Linux and Docker operations skills, monitoring, a backup routine and an owner for security patches. Community Edition is supported by the community only, and Plausible Cloud ships updates multiple times per week, so the gap in patch speed is yours to close. If your team lacks capacity, an implementation partner can help. DeployOpen 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. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support and upgrades are available as retainers.
How long does moving data to or from Plausible Cloud take?
Plausible's self-hosted page says Community Edition users can export and import data to and from Plausible Cloud, so the move is possible in both directions. No supplied source gives a duration, so you need to confirm it. The elapsed time depends on how much history you hold, how many sites are involved and whether you also move imported Google Analytics history. Ask Plausible for the documented procedure, the supported version pairings and any limits on the data it covers. Then run a full export and import on a copy of a representative site, and schedule the cutover around a period when traffic is low, so you can compare reports before you switch the tracking script.
How do the Google integration and GA4 import limits affect historical reports?
The GA4 import brings historical stats in as daily aggregates, and it runs up to the first native Plausible visitor, so older periods and newer periods are built differently. You can import from up to 5 GA properties per site. Ecommerce revenue cannot be imported, so any revenue reporting starts from the day Plausible collects it. Unique visitors are approximated by summing daily uniques, so totals across long ranges may not match a native Plausible count. The Community Edition wiki documents the Google integration, configured with GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET, which adds Search Console keyword data and GA4 import from the site's Imports and Exports settings. Test the import on one site and label the imported periods in your reporting.
Which features does Community Edition leave out compared with Cloud?
Plausible's self-hosted page lists these features as missing from Community Edition:
- Marketing funnels and user journeys
- Ecommerce revenue goals
- Single sign-on
- The Sites API
- The Looker Studio connector
- Advanced bot filtering
If your reporting depends on any of these, the choice is settled before you install anything. If you only need core pageview and goal reporting, the gap may not matter. Check each item against the reports your stakeholders use each week, and confirm with Plausible whether any feature has moved since the page was published, because the feature list is the one most likely to change.
Does self-hosting change how cookie banners and data location work?
Plausible's homepage says the service uses no cookies, so no cookie banner is required for its analytics, and it describes the service as made and hosted in the EU. Self-hosting moves the data location decision to you. The data stays in whatever region and facility you choose, and the consent position depends on your configuration, your jurisdiction and any other tags on the site. Confirm with your privacy counsel whether the no-cookie design satisfies your obligations, and document where the ClickHouse data is stored, who can access it and how long it is kept. Plausible's claims are the vendor's statements, so check them against your own setup.
How DeployOpen scopes and supports a Plausible Community Edition deployment
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Plausible Community Edition vs Plausible Cloud, that means agreeing in writing what the self-hosted install will own, including the operational work Plausible's own documentation places on the operator.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope records which sites, the hosting target, and which Cloud-only features the team is willing to forgo.
- We confirm whether the host meets the Docker, Docker Compose, CPU instruction set and RAM requirements before any build begins.
How we build
- We deploy Community Edition from the community-edition repository inside your cloud account, data center or air-gapped network.
- We configure the Google integration only where the scope calls for Search Console data or GA4 historical import.
- We test the install, including data export and import paths to and from Plausible Cloud, before it is treated as ready.
How we hand over
- Deliverables include runbooks for installation, upgrades, backups and restores, with the steps written for your own operators.
- We document the release-applying process, so security fixes reach your instance on a schedule your team owns.
- Handover covers the configuration, secrets locations and monitoring checks agreed in the written scope.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
- Retainer scope should state who applies each twice-yearly release and who watches for security releases between them.
- Ask any provider to confirm in writing who handles capacity, uptime and backups once the install is live.
