Built for a portfolio, not a single site
Most analytics tools make one property the unit of everything. Run eight of them and you get eight dashboards, eight visitor counts, and no way to know that the person reading your newsletter today is the one who tried your app in March.
Fourteen reports that already work
Not a roadmap. Every area below is built, running and screenshotted from the real dashboard.
One page that holds a person's whole history
Aggregate analytics tells you conversion fell. It rarely tells you what the people who failed to convert actually did.
Identity resolves on deterministic signals only: the same identify() id on two of your properties, or a click through a decorated link between two of your own domains. A merge is one small insert that re-attributes an entire history without rewriting a single stored event, and it keeps a snapshot so a bad merge can be reversed.
A growing share of your readers never load your page
They ask an assistant, and the assistant loads it for them. Falorb separates an agent answering somebody's question right now from an agent collecting a training corpus, because those are completely different events with completely different value.
One script tag, then a real API when you need one
The browser tracker is 2,943 bytes gzipped with no dependencies, and the build fails if a change pushes it over three kilobytes.
<script defer
src="https://a.example.com/t.js"
data-project="prj_8Kd2mQ"></script>falorb.identify(user.id, { email: user.email, plan: 'pro' })
falorb.track('checkout_started', { seats: 3 })
falorb.revenue(99, 'USD')
// server-side, where it is more reliable
await falorb.track({ personId, name: 'subscription_renewed' })
Two stores, because events and people are different problems
Events are immutable and high-volume, so they live in ClickHouse. Person profiles mutate constantly (merges, traits, interest scores), so they live in Postgres. Redis sits between collection and storage, so a slow or restarting database never becomes a slow response on somebody's website.
Browser ──▶ apps/ingest ──▶ Redis Stream ──▶ apps/worker ──┬──▶ ClickHouse (events)
(Bun + Hono) └──▶ Postgres (profiles)
p99 <10ms ▲
packages/queries ────────┘The part that is not a setting
Most privacy claims describe a configuration you could change. These are properties of how the system is built.
- No raw IP is ever stored. It is hashed with a daily-rotating salt at the collector and the original is discarded in the same function.
- Hashes cannot be joined across tenants or across days: the salt is scoped per project and per day.
- Form values are never captured. The tracker records that a form was submitted and which one, and nothing about what was typed into it.
- Consent is enforced at the server. An opt-in batch arriving without consent is refused by the collector, not merely suppressed by the client.
- Cross-site tracking is out of scope permanently. Not unimplemented. Refused, and documented as such in the repository.
MIT, and readable
A monorepo of six packages and five apps, TypeScript strict throughout, with the verification commands in the README so you can check the claims on this page rather than believing them.
Free if you run it. Quoted if we do.
Self-hosting is the default and always free. Managed hosting exists because not every team wants to operate three databases. It is the same MIT-licensed software, on infrastructure somebody else is on call for.
The ones people actually ask
What does self-hosted actually mean here?
Every part of the system runs on machines you control: the collector that receives events, Redis, ClickHouse, Postgres, the background workers, the dashboard and the MCP server. There is no vendor account, no data-processing agreement to sign and no outbound connection to us, because there is no us to connect to. The reference deployment is a Docker Compose file and a Caddy configuration.
Is Falorb really free?
It is MIT licensed, which means free to use, modify, self-host and run commercially, with no seat count, no event cap and no feature held back for a paid tier. Self-hosted, your only cost is the server it runs on. Managed hosting, the same software operated for you, is available on request for teams who would rather not run Postgres, Redis and ClickHouse themselves.
Does it need a cookie banner?
That depends on your jurisdiction and how you configure it, and it is not a question a piece of software should answer on your behalf. What Falorb gives you: cookieless mode that persists nothing on the device, consent mode that refuses opt-in batches at the server until consent is recorded, Do Not Track and Global Privacy Control support, and a privacy disclosure generated from a property's real settings.
How is this different from a pageview counter?
Pageview counters answer how many. Falorb keeps a person-level record, so it also answers who, which of your other products they have used, what brought them, where they stopped and whether they came back. It ships funnels, cohort retention, path analysis, goal conversions and revenue attribution as first-class reports.
Can it handle my traffic?
It is built for small-to-medium volume on modest hardware: the collector answers in single-digit milliseconds and publishes to Redis, so a slow or restarting ClickHouse never becomes a slow response on somebody's website. Events live in ClickHouse with monthly partitions and per-dimension rollups. It is not designed to be a hyperscale event warehouse, and does not pretend to be.
Does Falorb do cross-site tracking?
No, and it never will. That would require third-party cookies, persistent fingerprinting or purchased data-broker profiles. Everything Falorb knows is derived from first-party activity on properties you operate, and anonymous visitors are never joined across domains.
I built it because I got tired of the alternative
I run a lot of small projects: a handful of sites that each do one thing, most of them too small for anyone to call a business.
Analytics for that is miserable. Every tool assumes one important website. I had a property per project in Google Analytics, a login I avoided, and no way to answer did anything I made get used this month without opening eight tabs and adding it up by hand.
So I built the simpler thing I wanted: one deployment, every property on the first screen, and a person-level record underneath so a portfolio reads as one audience instead of eight strangers.
It is MIT licensed because the problem was never mine alone. If you have a folder of small projects and an analytics account you dread opening, take it and run it on your own server.
Written by Joy, who maintains Falorb. More about me and everything else I build at obhox.com.
Your analytics, on your own machines
Clone the repository, bring the stack up with Docker Compose, run two migrations and paste one script tag. Ten minutes, and no account anywhere. Or ask us to run it for you.