Open-Source & Self-Hosted CMP Options Compared (2026)

If you have searched “open-source CMP” or “can I build my own CMP”, you are weighing control and cost against maintenance and compliance risk. This is the current state of the realistic options, what each one actually does when you install it, how to choose between them, and the two things none of them solve on their own.

Project data below was checked against each repository and its own documentation in August 2026. Star counts and licences move; the architectural differences do not.

Why teams look at open-source and self-hosted CMPs

• Cost — no per-domain SaaS fee, no seat pricing, no renewal conversation.
• Control — you own the banner, the styling, the copy and the data flow end to end.
• No third-party script in the critical path — this is the one people underrate. A hosted CMP is a blocking script from someone else’s CDN, sitting in front of your entire site. When it is slow, your site is slow. When it is down, you are choosing between a broken banner and no banner.
• No vendor lock-in — the consent logic lives in your stack, in your repo, under your review process.

The five projects worth your time

CookieConsent (orestbida) — the default choice

The most-starred of the group and the one to reach for if you have no specific reason to pick another. Vanilla JavaScript, no dependencies, no build step required. Install with npm i vanilla-cookieconsent or point at the CDN build.

Blocking is attribute-based, which is the pattern you want: you mark a script tag as inert and the library decides when to run it.

<script type="text/plain" data-category="analytics">
  // only executes once the analytics category is granted
</script>

An optional data-service attribute breaks a category down into individual toggles in the preferences modal, which is how you give users per-vendor control without writing the UI.

The catch: the library does the banner and the gating; it does not do Google Consent Mode for you. Its own documentation sets the seven signals but never uses the phrase “Consent Mode v2” and does not cover wait_for_update, ads_data_redaction or url_passthrough — the parameters that determine whether your measurement survives a rejection. We walk through the wiring in CookieConsent v3 and Consent Mode v2: the parts the docs leave out.

Naming trap: on npm this is vanilla-cookieconsent. The bare cookieconsent package is Osano’s separate project below, and has not been published since 2019. People install the wrong one constantly.

Cookie Consent (Osano) — read the README before you commit

The most widely deployed consent script on the internet by a wide margin, and the repository is actively maintained. It is also the project whose own maintainers tell you to use something else.

The README states that to effectively use any open-source consent manager you will need to do GeoIP lookups, vary consent types by visitor location, persist consents to a database, and write callbacks to load scripts after consent is granted — and then says plainly: “Unless you specifically need the open source tool, most website owners will be better served by the hosted version.”

That is unusually honest, and it tells you exactly what this project is. The open-source package is the alert UI. Callback-free script blocking, the 38 languages, the stored consent records — those belong to the hosted product. Take it at its word: if you pick this one, you are signing up to build the blocking layer yourself.

c15t — the one built for a modern stack

Full setup walkthrough: how to set up c15t for cookie consent in Next.js.

The newest of the group and the most active. Apache-2.0, TypeScript, aimed at JavaScript, React and Next.js teams, and used in production by expo.dev, zed.dev and unkey.dev among roughly 2,100 sites.

Architecturally it is the odd one out, in a way that matters. The others are a script you drop on a page. c15t is a set of packages that live in your bundle: @c15t/react and @c15t/nextjs for prebuilt UI or headless hooks, @c15t/scripts for consent-aware loaders that gate GTM, GA4, Meta Pixel, PostHog, Clarity, Intercom and several dozen others, and @c15t/iab for IAB TCF 2.3 including TC string generation and Global Vendor List support.

It is the only project here with native Google Consent Mode v2 — GTM loads at page start with defaults denied and updates when the user chooses, instead of you hand-rolling the gtag('consent', ...) calls. It is also the only one that speaks the TCF at all.

The catch: it can run offline with consent stored in the browser, but the durable side — consent records, audit logs, policy state, server-side visibility — wants a backend, either hosted or self-hosted via @c15t/backend with your own database. That is a real operational commitment the others do not ask for. Weigh it honestly: if all you need is a banner on a marketing site, this is more machinery than the job requires.

Klaro — excellent, and worryingly quiet

BSD-3, self-hostable, genuinely well designed, and the one this site has covered most: see Klaro CMP open source: self-host your cookie consent and wiring Klaro to Consent Mode v2.

Blocking follows the same attribute pattern as CookieConsent, with its own names:

<script type="text/plain" data-type="text/javascript" data-name="optimizely">

The catch, and be clear-eyed about it: the last push to the repository was March 2025. It is not archived and it has not been abandoned in any formal sense, but seventeen months without a commit on a compliance tool is a signal, not a detail. Consent frameworks move — TCF versions, Consent Mode parameters, browser storage behaviour. A project that is not moving is one you will eventually be maintaining yourself. If you adopt Klaro today, adopt it on the assumption that you own the fork.

tarteaucitron.js — the pragmatist’s option

French, MIT, running since 2013, and built around a completely different idea from the rest. Instead of giving you a blocking primitive and letting you wire each vendor, it ships a catalogue of services with the integration already written. You declare which services you use and it handles disabling them by default, loading them on acceptance without a page reload, and showing a fallback — a plain link instead of a social button, a static banner instead of an ad — while consent is absent.

That fallback behaviour is a genuinely thoughtful touch that none of the others provide, and the service catalogue removes most of the per-vendor work that makes the others tedious.

Its services do set analytics_storage, ad_user_data and ad_personalization, so the v2 signals are there. The phrase “consent mode” does not appear in the codebase, though, so treat it as signals present rather than a documented, supported Consent Mode integration, and verify the behaviour yourself.

How to choose, in one pass

• React or Next.js, and you want it in your bundle? c15t. Nothing else here is built for that, and it is the only one that gives you Consent Mode v2 and the TCF without hand-rolling either.
• Plain site, want something proven and small? CookieConsent by orestbida.
• Long tail of third-party services you do not want to wire individually? tarteaucitron.
• Already running Klaro? Stay, but watch the repository and budget for owning it.
• Considering Osano’s open-source package? Re-read its README, then decide whether you are really building the blocking layer yourself.

And if the honest answer is that nobody on the team wants to own any of this, that is a legitimate finding rather than a failure. We priced that decision in build your own CMP vs pay for one and what building your own actually costs, and compared the hosted field in the best-known CMPs compared.

The first thing none of them solve: Google will not take your consent signal

This is the trap that catches self-hosted setups, and it is not a legal problem — it is a commercial one.

Every project above can be configured to satisfy the GDPR. None of them, as far as their own documentation claims, is on Google’s list of certified CMPs. Since January 2024, serving personalised Google ads to users in the EEA or the UK requires a CMP that is both certified by Google and integrated with the IAB TCF. Implementing the TCF is not the same as being certified — they are two separate gates with two separate gatekeepers, so even c15t’s TCF support is only half of that test, and the certification half is yours to check before you rely on it.

Get this wrong and the failure is quiet: your ads keep serving, but European traffic drops to non-personalised or limited inventory and your RPM sags without anything appearing broken. The full breakdown, including the three ways out, is in your self-hosted CMP is legal and still cannot serve Google’s ads in the EEA.

If you do not monetise with Google ads, none of this applies to you and you can ignore it entirely.

The second thing none of them solve: proving what your site actually does

Open-source or SaaS, a CMP only declares intent. It does not prove what your site does. The most common — and most litigated — failure is tags firing before consent, regardless of which banner is on the page, and it is almost never the CMP’s fault. It is a pixel someone pasted into the theme two years ago, a tag added in GTM by marketing that nobody gated, a plugin that loads its own script.

Self-hosting makes this more your problem, not less. There is no vendor dashboard telling you a new tracker appeared. The blocking attribute has to be on every script, on every template, after every deploy, forever — and the failure mode is silent, because a script that fires early looks identical to one that fires correctly unless you are watching the network tab at the right moment.

Verify it, then keep verifying it: run a scan with CookieInspector to see every cookie and tracker that fires before and after consent. Do it once to find what your banner is missing today, and keep it running so the next deploy that quietly breaks a blocking attribute does not go unnoticed for six months.

Bottom line

Open-source CMPs are a strong choice when you have the engineering capacity and want control, and the field is healthier than it was two years ago — c15t in particular closes gaps that used to force teams onto commercial products. Pick on architecture rather than star count: how it blocks scripts, whether it speaks Consent Mode, and whether the repository is still moving.

Then, whatever you pick, pair it with independent verification. The banner is the promise; the scan is the proof.