Existing projects to consider

These repositories cover part of this workflow. Check their scope and hosting requirements before choosing.

Existing project · Free tier eligible

Counterscale

By benvinegar

Page-view collection, referrer and audience breakdowns and a simple traffic dashboard; advertising attribution and complete enterprise analytics parity are excluded.

The documented Counterscale deployment can use Cloudflare Free allowances for a small workload under the request, CPU and service-specific quotas below. This is conditional eligibility, not a measured zero-cost deployment; optional features, domains and external providers can add costs.

Explore Counterscale →

Existing project · Paid hosting baseline

Traks

By shivamanupadi

Website pageviews, visitors, referrers and live/historical reports; no advertising attribution, universal analytics integration or complete proprietary analytics-platform parity.

The README explicitly requires Workers Paid, starting at $5 USD/account/month. Pipelines, R2 Data Catalog, R2 SQL, DO writes and other services are metered beyond allowances. Its small-site approximately $5 estimate is upstream documentation, not a measured catalog deployment or a guaranteed bill.

Explore Traks →

Build proposal

This is a proposed build, with a conceptual architecture. Any linked existing projects have their own documented scope and infrastructure.

Browse existing projects and remaining proposals →

Queue #4

Waiting for votes

Plausible on Cloudflare

Privacy-first analytics, event capture, dashboards, and exports on Cloudflare.

replaces Plausible D1 Queues R2 Turnstile Workers

would replace

Plausible· analytics

How it would work

A URL goes in, an API-ready result comes out. These are the stages the request flows through.

map01
Map the rented workflow
Identify the small-team job that actually needs replacing.
→
build02
Assemble the Cloudflare loadout
Pick the primitives that cover the core data, compute, auth, and delivery path.
→
ship03
Publish the useful version
Release a deployable build with limits, setup notes, and maintenance tradeoffs.

Concrete jobs it does

If you're paying Plausible for any of these, the proposed build would let you stop.

→Cover the small-team workflow people actually rent the SaaS for
→Expose a simple, deployable API
→Persist the right data in D1 and the right artefacts in R2
→Stay maintainable by one or two engineers

Config knobs

What you'll be able to tune from day one.

Workflow scope: core team workflow only
Deployment target: Cloudflare Workers + supporting primitives
Access model: simple auth and admin controls
Limits: documented scale and maintenance boundaries

proposed architecture

The Cloudflare loadout, wired together.

Architecture

Overview inferred from the listed Cloudflare services. Routes and connections have not been verified.

Public interface

Surfaces1

client / caller

interface not yet reviewed

→

↓

App

Workers

entry

request handler

→

↓

Bindings

what each tool does

Cloudflare feature

Function in the proposed app

D1tool 01

Track crawl jobs, pages, status, users, limits, and API keys.

Queuestool 02

Queues

Fan out background jobs so crawls can retry and continue after the first request.

R2tool 03

Store raw HTML, screenshots, markdown output, and crawl artefacts.

Turnstiletool 04

Turnstile

Use Turnstile for the part of the owned app that needs this platform capability.

Workerstool 05

Workers

Public API, routing, auth checks, rate limits, and orchestration glue.

will build

+The core workflow small teams actually use every week.
+A deployable Cloudflare-native version with clear setup steps.
+Basic auth, data storage, admin screens, and operational visibility.
+A writeup that explains the useful limits and maintenance burden.

will not build

-A pixel-perfect clone of the SaaS being replaced.
-Enterprise governance, compliance guarantees, or managed support.
-Every advanced feature that only large teams need.
-A promise that replacing the rented tool is always the right call.

readme