Self-host a Plausible alternative on Cloudflare

Inspect the actual deployment files

Start at the Counterscale project page. The original README and configuration evidence are tied to commit 71107f4fe84053c3703df03ca66411d4144e6f2f. Its Wrangler file declares these resources:

Resource	Declaration	What to verify
Worker	workers/app.ts with static ASSETS	Your account, route and request/CPU budget
Analytics Engine	WEB_COUNTER_AE, metricsDataset	Separate test dataset and query access
R2	DAILY_ROLLUPS, counterscale-daily-rollups	Your bucket, storage budget and archive access
Daily job	Cron 0 2 * * *	Scheduled handler runs and expected files appear

Keep resource names and accounts explicit. A preview bucket name alone is not proof that every local integration is isolated. The README specifically warns that local reads use a production Analytics Engine dataset while local writes do not record hits.

Install a reviewed version and keep credentials private

The pinned CLI package reports version 3.4.1. Its README documents installation through @counterscale/cli, and offers advanced settings for Worker and dataset names. Review that package version and the installer prompts before running it in your account. This article has not executed the upstream installer or provisioned a new instance.

Use an account-scoped Analytics token with the documented minimum permissions, store it as a secret and enable the installer's dashboard password option. Do not put tokens into public config or client HTML. Decide who will maintain the application and how access will be recovered before connecting real sites.

Add the tracker only to a test site first

The documented script integration uses your deployed /tracker.js endpoint, a unique data-site-id and defer. Replace the README's hostname placeholder with your deployment; copying a source example does not create that Worker. Keep the test site's identifier separate from production traffic.

1. Confirm the dashboard requires the chosen password before sharing its URL.
2. Load one test page and check that collection reaches your own /collect endpoint.
3. Exercise client-side navigation and confirm the expected pageview count.
4. Inspect referrer and audience breakdowns against a known test visit.
5. Verify a scheduled R2 archive and demonstrate how you would read or recover it.
6. Record request, CPU, data-point, query and storage usage before expanding the rollout.

Check daily limits and the history you need

Workers Free currently permits 100,000 requests per day and 10 ms CPU per invocation. Analytics Engine lists 100,000 written points and 10,000 read queries per day for Free, while its pricing announcement says billing has not started yet. R2 Standard has separate storage and operation allowances. Other applications can consume shared account quotas.

Use actual daily peaks rather than assuming a monthly visitor total fits. Archive retention also needs a tested workflow: Analytics Engine's three-month window and R2 files are different capabilities. Compare the reports you need using Counterscale vs Plausible, then use Plausible pricing and the alternatives shortlist to decide whether taking on that operating work is worthwhile.