InsightFlare runs cookieless analytics end to end on Cloudflare

Analytics with no cookies and no stored addresses

InsightFlare is a privacy-friendly open source web analytics tool that runs entirely on Cloudflare. The claim it makes about itself is a strong one, that it is fully compliant with GDPR, with no cookies, so visits can be tracked legally without asking users for consent.

The interesting design decision is what it does instead of identifying a visitor by a cookie or a stored address. The project does not store raw IP information at all. It relies on Cloudflare for geolocation resolution, which is the piece that makes that workable, since every request already arrives through Cloudflare's network and the country and city are already known there.

On top of that sits the smart tracking intensity mechanism, described as automatically adjusting visitor identifier persistence based on regional privacy regulations. The stated intent is to balance data integrity with privacy protection, so a visitor identifier lives longer in some regions than in others depending on the rules that apply there.

The audience is a site owner or a small team who wants to know where traffic comes from and what people do on the site without adding a consent dialog or sending a European visitor's address to an advertising company. The topics attached to the repository list cookieless, gdpr-compliant, privacy-first and edge computing, which describes the design rather than a policy page.

The project is written in TypeScript, licensed MIT, and the last push was on 2026-10-19, with v0.7.1 released on 2026-09-03, v0.7.0 on 2026-08-31 and v0.6.0 on 2026-08-16.

A three kilobyte SDK and the events it sends

The tracking side of the project is deliberately tiny, and the number is stated rather than implied.

The frontend analytics SDK is only about 3 KB after gzip compression, and it is distributed through Cloudflare's global CDN. For a tracker that has to load on every page of every site, that size is the whole argument, since a heavier script slows down the pages whose performance you are trying to measure.

The SDK covers two things. Custom event tracking, which is triggered by a data-insightflare-event attribute in the markup, so a developer marks an element rather than writing a call, and performance metric tracking, which reports the browser and device characteristics that the dashboard later breaks down.

The dashboard then presents that data. The feature list is long and worth reading as a list of questions rather than a list of screens, because it tells you what the tool is designed to answer. There is comprehensive traffic dimension tracking, real-time visitor monitoring, page-level traffic analytics, tracking of real visitor performance, comparison of traffic quality across sources, UTM campaign performance, recording and analysis of custom events, inspection of every session, return visit tracking, geographic distribution and market intelligence, visitor device details, browsers and their capabilities, and a deep analysis view for JSON custom events.

From there it adds funnels for analysing visits and events, scheduled and conditional email notifications, a public sharing system for dashboards, a clearly scoped API system, scheduled tasks, multi-dimensional bot protection with request observation, and a system health view. There is also a note that tracking settings can be adjusted at any time without changing the frontend SDK, which matters when a setting changes and you do not want to redeploy every site.

Deploying with the Cloudflare button and two secrets

Installation is a button. The Deploy to Cloudflare link clones the repository, creates the required resources and binds them, and the only thing left for you to do is fill in two secrets:

  "name": "insightflare",
  "version": "0.7.1",
  "private": true,
  "type": "module",
  "packageManager": "[email protected]",

The MAIN_SECRET is the root secret from which visitor salts, session keys and API key hash keys are derived. The documentation is emphatic that it must be a random string longer than 16 characters, and points at a generator that produces a 32 character string, refreshing the page for a new one each time. The BOOTSTRAP_ADMIN_PASSWORD is the initial administrator password, and you sign in with the admin account and that password, changing both later on the personal settings page.

After the secrets are filled in, the documentation says to wait about three minutes for the deployment to finish. The default URL is https://insightflare.<your-cloudflare-username>.workers.dev, and the domain can be changed on the project settings page.

There is one design point in that secret list that deserves attention from whoever operates this. Because visitor salts and session keys are derived from one root value, losing MAIN_SECRET is not a matter of rotating a password, it changes the identity of every visitor identifier, and the documentation does not describe a rotation procedure for it. A team should decide where that secret lives before the first deployment rather than after.

Analytics Engine as a separate high-throughput layer

InsightFlare has an optional second analytical layer, and the reason it exists is about volume rather than about features.

Analytics Engine is described as the optional high-throughput analytical layer, and it keeps request observability and future traffic and event projections separate from the primary database. Three datasets sit on it, each with a distinct job. REQUEST_ANALYTICS is for request observation and abnormal traffic, TRAFFIC_ANALYTICS holds sampled traffic facts, and EVENT_ANALYTICS holds sampled custom-event facts.

The split is the design. Anything that arrives in large volume and only matters in aggregate, request logs, abnormal traffic patterns, projected counts, goes to the Analytics Engine datasets, while the primary database keeps what the dashboard queries directly. A request observation table is exactly the kind of thing that is cheap to sample and expensive to store in full, and separating it means the main path stays fast.

Enabling it is not automatic. The documentation says it requires enabling Analytics Engine manually in the Cloudflare Dashboard, with the Analytics Engine section of the account Workers settings given as the place to do it, and the instruction to follow the documentation from there is cut off in the visible text.

For a team evaluating this, the practical point is that the feature is off by default, so a first deployment does not exercise it, and turning it on later is a separate configuration step rather than a flag in the dashboard.

A pnpm workspace with two UI packages and three wrangler targets

The repository layout shows a project that takes its deployment target seriously, because there are three of them.

There is wrangler.toml for the Cloudflare deployment, wrangler.dev.toml for development and wrangler.demo.toml for the demo build, and the scripts mirror that with build:cf, build:local and build:demo targets, all routed through a single scripts/build.ts with a target flag. The dev scripts are equally explicit, with dev:ui running Vite in demo mode, and dev:worker and dev:gallery running in development mode.

The front end is a pnpm workspace with packages/ and two published-internal packages, @insightflare/ui and @insightflare/product-ui, each with its own build, typecheck and pack scripts. The root package.json is private and marked as an ES module project, pinned to pnpm 10.33.0.

The testing and quality setup is extensive for a project of this size. There are separate Vitest configurations, one of them for the tracker, a Playwright configuration for end to end tests, an e2e/ directory, husky for git hooks, Prettier and ESLint configurations, a components.json for the component system, a migrations/ directory for the database, a changelog/ directory, and a scripts/ directory holding the code generators, including scripts to generate the OpenAPI definition, the release index, the skills and the schema.

The generated skills are interesting. There is a generate:skills script and a verify:skills script that checks the result, which means the agent-facing documentation is produced from the same source as the code rather than written by hand and left to drift.

Where the Cloudflare dependency bites

The tool is good, and the constraint is structural rather than a bug.

Running entirely on Cloudflare is the source of several of the project's nicer properties. The SDK is served from Cloudflare's global CDN, so it is close to every visitor. The geolocation comes from Cloudflare's network rather than from a third-party lookup service, which is also why no raw address has to be stored. The deployment is one button and about three minutes, with no server to provision and no database to run. And the free quotas can support free tracking for 100,000 visits per day, with performance from edge computing.

The same choice is the limit. There is no path in this repository to run the collector somewhere else, and the durable objects and workers model are part of the design rather than an implementation detail you can swap out. A team with a hard requirement to keep telemetry inside its own infrastructure is looking at a different tool.

The quota is the other boundary. A hundred thousand visits a day is generous for a small site and small for a busy one, and the documentation does not set out what the paid path looks like, so a high-traffic site has to find that out separately.

The privacy claim also has a boundary that is worth stating carefully. Not storing raw IP addresses does not mean not identifying visitors, because the smart tracking intensity mechanism still derives a visitor identifier, and the identifier's persistence depends on the region. A reader who treats cookieless as anonymous would be misreading it, and a reader who treats it as full anonymity would also be misreading it, since the dashboard reports sessions, devices, browsers and return visits. The claim is that the identifier is not a personal identifier in the cookie sense, not that the data cannot single out a device.

A fast moving project with a small licence surface

The maintenance picture is straightforward and worth stating precisely.

The repository is not archived, the last push was on 2026-10-19, and the recent tags are v0.7.1 on 2026-09-03, v0.7.0 on 2026-08-31 and v0.6.0 on 2026-08-16. So the project is on a 0.x line, and the version numbers move with a mixture of patch and minor releases. A deployment that wants stable behaviour should expect to read the changelog directory before upgrading, since there is no long-term support branch described in the documentation.

The licence is MIT, which is the least encumbered option available. There is a LICENSE file at the root, and a NOTICE-style set of files is not required by that licence, so a team embedding or modifying the dashboard does not have to carry obligations beyond the notice itself. That is a genuine advantage over analytics products that arrive under a business licence with restrictions on what you may do with the data.

The repository also carries the administrative files you would expect from a project inviting outside contributions: CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md and SUPPORT.md, the last of which is a support policy rather than a support contract.

And it is multilingual, with a README switcher for English, Japanese and Chinese, and a dashboard that translates place names for more than 95 percent of the world, which is a small feature that says a lot about who the author expects to use it.

Editorial conclusion

InsightFlare suits a site owner who wants traffic analytics without cookies, without a consent banner and without a monthly invoice, and it is the wrong choice for anyone who needs self-hosting outside Cloudflare or analytics at a scale beyond the free tier. Before adopting it, decide who holds MAIN_SECRET, since the same secret derives visitor salts, session keys and API key hashes, and check the bot protection settings before you spend a week classifying scraper traffic as human.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. RavelloH/InsightFlare on GitHub
4. README
5. Releases