Table of Contents
- Scope and measurement rules
- Measured result
- How to verify a hosting path
- What the statuses prove—and do not prove
- Project-level interpretation
- Frequently Asked Questions
Scope and measurement rules
This audit measures whether eight prominent open-source projects have a concrete public path to managed hosting through two third-party provider catalogues. It is a discovery report, not a hosting-quality ranking or purchase recommendation.
The sample contains the eight most-starred live projects in the Product & Web Analytics category in OpenAlt’s production catalogue snapshot. Stars rank the sample only; they do not measure hosting quality, project maturity, support, security, or operational reliability.
The category is broader than its label may suggest. It spans web analytics, product analytics, social publishing, model visualization, log analysis, and data infrastructure. Hosting availability therefore does not imply product equivalence. A concrete deployment path for one project may be irrelevant to a reader seeking a different type of tool.
OpenAlt tested two public provider surfaces on 2026-09-23:
- PikaPods:
availablemeans the project name appeared as a concrete app card in the public PikaPods catalogue HTML fetched on that date. It does not mean the search query parameter worked, that the card was selected, or that checkout was completed. - Elestio:
availablemeans the generated project-specific/open-source/<repo>page returned HTTP 200 with a project-specificManaged ... as a Servicetitle on that date. A 404 is unavailable. No checkout was attempted.
OpenAlt’s separate Catalog managed status is a current project-level managed-hosting flag. It may describe an official vendor cloud or another hosted path, so it is not expected to match these two third-party catalogues exactly.
Measured result
The measured result is narrow but useful: PikaPods exposed concrete app cards for 2 of 8 projects, Elestio exposed project-specific pages for 3 of 8, and at least one tested provider covered 3 of 8.
In this eight-project sample, concrete third-party catalogue coverage reached 3/8 at most, while OpenAlt’s broader catalog-managed flag covered 5/8.
| Signal | Result | Projects or interpretation |
|---|---|---|
| PikaPods concrete app cards | 2/8 | Umami and Matomo |
| Elestio project-specific pages | 3/8 | PostHog, Umami, and Matomo |
| At least one tested provider | 3/8 | PostHog, Umami, and Matomo |
OpenAlt Catalog managed flag | 5/8 | PostHog, Umami, Postiz, Plausible Analytics, and Matomo |
The overlap matters. Umami and Matomo appeared on both tested provider surfaces. PostHog had an Elestio project-specific page but no PikaPods app card. Postiz and Plausible Analytics were marked catalog-managed by OpenAlt, yet neither tested provider showed a concrete page for them.
Those differences are not contradictions. They show that the provider tests and OpenAlt’s catalogue flag answer related but different questions. The provider tests ask whether a named third-party catalogue exposed a concrete, project-specific path at the measured time. The OpenAlt flag captures a wider project-level view of managed hosting.
The report page shell includes a downloadable CSV source, direct links to the tested project pages, and links to the provider catalogues. Those links let readers inspect the same project-level evidence without treating the summary count as a substitute for verification.
How to verify a hosting path
The fastest verification method is to confirm a project-specific provider surface, then separate availability from purchase readiness.
- Start with the exact project name and repository identity. Similar names, forks, integrations, and hosted editions can produce misleading matches.
- For PikaPods, inspect the public PikaPods apps catalogue. Count a result only when the project appears as a concrete app card in the fetched catalogue HTML. Do not treat a provider homepage or a URL containing a search term as equivalent evidence.
- For Elestio, open the generated project-specific path
https://elest.io/open-source/<repo>. Count it only when the page returns HTTP 200 and uses a project-specificManaged ... as a Servicetitle. A 404 is unavailable under this audit’s rule. - Check whether the page identifies the actual project rather than a generic marketplace, documentation page, blog post, or provider landing page.
- Treat checkout, deployment, region selection, resource sizing, billing, and account setup as separate verification steps. This audit did not attempt checkout.
- Compare the provider result with OpenAlt’s
Catalog managedflag. A mismatch is a signal to investigate, not proof that either source is wrong.
Generic provider homepages should not be called one-click app pages because they do not establish that the specific project is listed, deployable, or configured for managed service. Unfiltered search URLs should receive the same treatment: a query string can show intent without proving that the provider recognized the project or returned a usable app configuration.
The practical standard is simple: name the project, identify the provider’s project-specific surface, record the response evidence, and state what was not tested.
What the statuses prove—and do not prove
These statuses prove public availability evidence at a defined point in time. They do not prove that a deployment will succeed, remain online, fit a workload, or meet a business requirement.
HTTP 200 on an Elestio project-specific page proves that the page responded successfully and matched the required project-specific title. It does not prove that the service was purchasable, that deployment capacity existed, that the image was current, or that the resulting installation would be production-ready.
A PikaPods catalogue card proves that the project name appeared as a concrete card in the fetched public catalogue HTML. It does not prove that the card’s configuration was complete, that the project could be launched in the reader’s region, or that payment and provisioning would succeed.
Neither provider result establishes:
- Reliability, uptime, performance, or scaling behavior.
- Security posture, patch cadence, backups, or disaster recovery.
- Support quality, response times, or operational ownership.
- Price, billing terms, resource limits, or total cost.
- Data residency, compliance, privacy terms, or jurisdiction.
- Compatibility with a particular integration, migration, database, or workload.
- A recommendation to buy, deploy, or entrust data to the provider.
The same caution applies to Catalog managed. A positive flag is useful for finding a managed path, but it may refer to an official vendor cloud or another hosted route outside the two tested third-party catalogues. A negative result on either provider does not deny that a project has an official cloud, a self-hosted managed service, a commercial partner, or another hosting option.
Project-level interpretation
The project-level picture is mixed: three projects had concrete coverage from at least one tested provider, while two additional projects were catalog-managed without a matching page in either test.
PostHog is the clearest example of provider asymmetry. It had an Elestio project-specific page but no PikaPods app card. That is evidence of one concrete third-party route, not evidence that Elestio is the only route or that PikaPods cannot add the project later.
Umami and Matomo had the strongest measured coverage because each appeared as a PikaPods app card and an Elestio project-specific page. The overlap makes them straightforward starting points for readers whose requirements fit those products, but it still does not turn catalogue presence into a quality or purchase recommendation.
Postiz and Plausible Analytics were marked Catalog managed by OpenAlt, but neither tested provider had a concrete page. This does not deny their official cloud or other hosting. It means only that the two measured third-party catalogue surfaces did not provide the required evidence.
Netron, GoAccess, and Druid had neither tested provider. That result identifies a gap in these specific public catalogues; it does not establish that managed hosting is impossible or that self-hosting is the only option.
Readers can continue through OpenAlt’s analytics category, the Google Analytics alternatives guide, or the project pages for Umami and PostHog. Use the audit as a shortlist for verification, then confirm current terms and technical fit directly with the relevant project or provider.
Frequently Asked Questions
Does “available” mean I can purchase hosting immediately?
No. It means OpenAlt found the defined public evidence on 2026-09-23: a PikaPods app card or an Elestio project-specific page meeting the stated rule. Checkout, provisioning, capacity, pricing, and account eligibility were not tested.
Why does Catalog managed differ from provider coverage?
Because Catalog managed is a broader OpenAlt project-level flag. It may represent an official vendor cloud or another managed route, while the provider measurements cover only the tested PikaPods and Elestio surfaces.
Are the eight projects directly comparable?
No. The sample spans multiple product types, including web analytics, product analytics, social publishing, model visualization, log analysis, and data infrastructure. Hosting availability should not be interpreted as product equivalence.
What should I verify before choosing a provider?
Verify the exact project page, deployment workflow, current price, regions, data handling, backups, support, limits, and migration options. Treat the audit as availability evidence and a starting point for due diligence, not as a reliability, security, or purchase recommendation.