Every site I build ends up needing the same boring thing: a way to ask people whether they are happy to be tracked, and a way to prove, later, that they said yes.
For years I reached for the obvious tools. CookieYes, OneTrust, Cookiebot, Iubenda. They all work. They also all do the same three things I have quietly grown to dislike. They add a third-party script to your site. They send you a per-domain bill that grows as you grow. And they put the record of your users’ consent, the thing a regulator will one day ask you to produce, on someone else’s servers.
So I built the opposite. It is called AllowKit, it is open source under the MIT licence, and it is the consent backend I wish I had started with.
The thing nobody says out loud about consent SaaS
A cookie banner is not the hard part. Anyone can build a banner in an afternoon. The hard part is everything behind it: storing the choice, honouring it everywhere, and keeping an honest, tamper-proof record of it for GDPR Article 7(1), which asks you to demonstrate that consent was given.
Consent SaaS products bundle the easy part, the banner, with the hard part, the backend, and then charge you for the bundle per domain. In exchange you accept three costs that rarely get talked about.
The first is a script on your site. That is one more third-party origin in your content security policy, one more thing that can break, slow you down, or change under you without warning. If you care about performance and control, and I do, that is a real cost.
The second is your data living somewhere else. The consent record is legal evidence about your users. Handing it to a vendor means that when you need it, you are asking someone else for your own proof.
The third is the shape of the tool itself. These products are UI-first. They want to own the banner, which means they want to own your design. The moment you have more than a website, a dashboard, a mobile app, a desktop client, that model falls apart, because each surface ends up with its own idea of what the user agreed to.
What AllowKit actually is
AllowKit is a consent API and nothing more. It is backend-only. You bring your own UI.
It runs entirely on your own Cloudflare account: a Worker for the logic, KV for the latest consent state, and D1 for an append-only audit log. There is no hosted service in the middle, no per-domain pricing, and no script tag pointing at me or anyone else. Your banner, in your design system, calls your AllowKit instance. That is the whole picture.
The architecture is deliberately small:
Client (web / mobile / desktop)
|
v
AllowKit Worker (Hono)
|
KV -> latest consent state, keyed by a hashed subject ID
D1 -> append-only audit log (updates and deletes blocked at the database)A few principles hold the whole thing together.
Default deny. Nothing non-essential runs until the user says yes. No analytics, no marketing tags, no tracking before consent. That is the correct default under GDPR, and it is the default here.
One subject, one consent state, shared everywhere. Consent is stored per subject, per instance, and the last write wins. If someone withdraws consent on your mobile app, your website reads the same withdrawn state on the very next request. The audit log records which app made each change, so you can see the full history, but the runtime answer is always singular and consistent. This is the part the UI-first tools cannot do cleanly, and it is the reason I started.
An audit log you cannot quietly edit. Every change appends a row to D1, and database-level triggers reject any attempt to update or delete those rows. The log only grows. That is what “demonstrable consent” should mean in practice, not a dashboard you have to trust, but an append-only record on infrastructure you control.
The security decisions I am most comfortable defending
Consent data is sensitive, so the security model matters more than the feature list. A few choices are worth calling out, because they show the posture.
Subject IDs are never stored in the clear. They are hashed with a per-instance salt using SHA-256 before they touch storage, and they are never echoed back to clients or placed in a URL. The web model uses a high-entropy UUID that your site generates and keeps in a first-party cookie, defended server-side by a strict Origin allowlist, so a non-browser caller without an allowed Origin simply gets a 403. Your authenticated apps go further and sign every write with a short-lived JWT, capped at five minutes by default and fifteen at the absolute most, with the classic algorithm-confusion attacks rejected outright.
The write order is chosen so that the failure direction is the safe one. AllowKit writes the audit row first, then the KV cache. If the cache write fails after the audit row commits, your runtime falls back to default-deny while the audit log still shows what the user intended. The reverse order would have been the dangerous one: tracking granted in the cache with no record of why. I would rather fail closed and keep the evidence.
I am also honest in the README about the trade-offs I accepted, because pretending a system has none is how you get bitten. The idempotency check is not a true compare-and-swap. The salt is effectively permanent for the life of an instance. Rate limiting lives at the Cloudflare edge rather than inside the Worker, which is a feature, not a gap, because it runs before a request ever costs you anything. If you want the full threat model, it is all written down in the open.
What it is not
AllowKit is not a banner, and it will never ship one. It is not an npm package or a script loader. It does not implement the IAB TCF framework, and it is not legal advice. If you want a drop-in widget that thinks for you, this is the wrong tool. If you want to keep your design and own your data, it is exactly the right one.
Why this is the way I want to build
There is a bigger idea under this, and it is the same one behind most of what I build lately. The healthy version of the web is one where you own the important parts. Your performance, your design, and your users’ data should not be rented from a third party that can change the terms, raise the price, or become the reason your site is slow or breaks.
Consent is a small, unglamorous corner of that. It is also a corner almost every site has quietly outsourced without thinking about what it gave away. AllowKit is my attempt to take one piece back, cleanly, on infrastructure you already trust, at a cost of essentially nothing to run.
It is open source, it is MIT-licensed, and the whole thing, code, tests, threat model, and setup, is on GitHub: github.com/rolandfarkasCOM/allowkit. If you deploy it, break it, or improve it, I would genuinely like to hear about it.