A cloud CMP is run by the vendor: you add one script tag, and the vendor hosts the banner, stores the consent records and ships updates. A self-hosted CMP runs on your own servers: you control where every consent record lives, and your engineers own the code, the database, the updates and the uptime. Most websites are better served by a cloud CMP that keeps data in the EU, while self-hosting suits organisations with strict data residency rules and engineers to spare.
Two hosting models, very different responsibilities
Every consent management platform runs somewhere. That somewhere decides who controls the consent data, how fast the banner loads and how much engineering time you spend keeping it running. The two main models are cloud-hosted (SaaS) and self-hosted (on-premises or your own infrastructure), and the gap between them is wider than most website owners realise.
Cloud CMPs handle infrastructure, updates and uptime on your behalf. Self-hosted CMPs hand you full ownership of the stack, from the database storing consent records to the JavaScript served to visitors.
Neither option is better for everyone. The right choice depends on your regulatory exposure, your technical team and how much control you actually need over consent data.
What cloud-hosted CMPs offer
A cloud CMP runs on the vendor's infrastructure. You add a script tag to your site, configure your banner in a dashboard, and the vendor handles the rest: serving the banner JavaScript from a CDN, storing consent records, running geo-detection and pushing updates when the rules change.
The advantages are practical. There is no server to provision, no database to back up and no security patch to apply. Changes such as the move to IAB TCF v2.3, required for new consent strings from 1 March 2026, reach your site through the vendor's script without a code deployment on your side.
Most cloud CMPs also offer global CDN distribution. The banner script loads from a nearby edge node, which reduces latency for visitors wherever they are.
The trade-off is dependency. Your consent data sits on someone else's servers. If the vendor has downtime, your banner may fail to load. If the vendor's infrastructure is outside the EEA, you may inherit cross-border data transfer obligations under Chapter V of the GDPR.
What self-hosted CMPs offer
A self-hosted CMP runs entirely on infrastructure you control. The consent banner code, the configuration files and the consent log database all live on your own servers or private cloud environment.
Data residency is the main draw. With a self-hosted setup, consent records stay on your infrastructure. If your servers are in the EU and nobody outside the EEA can reach them, there is no cross-border transfer to assess. That second condition matters: the EDPB's Guidelines 05/2021 on international transfers treat remote access from a third country, even just displaying personal data on a screen in a support or troubleshooting situation, as a transfer.
Full control also means full customisation. You can change the banner code, integrate directly with your back-end systems and tailor the consent logic to unusual requirements without waiting in a vendor's feature request queue.
Performance: script weight and loading speed
Cookie banners affect Core Web Vitals. In a March 2025 test, DebugBear measured Largest Contentful Paint rising from 1.43 to 3.61 seconds when a consent banner's policy text became the largest element on the page. Cumulative Layout Shift also suffers when banners insert content that pushes page elements downward.
Cloud CMPs vary widely in script size, so ask each vendor for a measured figure and check it in your browser's developer tools. Kukie.io's banner script, for example, measured about 37 KB gzipped in October 2026. The CDN advantage offsets some of the weight through caching and edge delivery.
Self-hosted CMPs give you direct control over what gets loaded. You can strip unused features, defer non-critical components and serve the script from the same domain as your site, avoiding the extra DNS lookup and TLS handshake that external scripts need. Serving from a first-party domain also avoids some ad-blocker interference, since many blockers target known third-party CMP domains.
Optimisation then becomes your job. A self-hosted CMP that nobody maintains can become slower than a well-tuned cloud alternative.
Performance comparison at a glance
| Factor | Cloud CMP | Self-hosted CMP |
|---|---|---|
| Typical script size | Varies by vendor (ask for a measured figure) | Depends on build |
| CDN delivery | Included (global edge nodes) | You must configure your own CDN |
| DNS lookup overhead | Extra lookup for vendor domain | None (same origin) |
| Ad-blocker risk | Higher (known vendor domains) | Lower (first-party domain) |
| Caching control | Vendor-managed | Full control over cache headers |
| Ongoing optimisation | Vendor handles | Your engineering team handles |
Data residency and GDPR transfer rules
Consent records contain personal data: at minimum, an identifier, the timestamp and the choices made. Under the GDPR, transferring this data outside the EEA requires a valid transfer mechanism such as Standard Contractual Clauses or an adequacy decision.
Cloud CMPs typically process data in the region where their infrastructure sits. Many EU-focused vendors now offer EEA-only hosting, but not all do. If your cloud CMP routes consent data through US-based servers, check that appropriate safeguards are in place under Articles 44 to 49 of the GDPR. Kukie.io, for example, runs its servers in Hetzner data centres in the EU and lists every sub-processor, with its location and safeguard, in its Data Processing Agreement.
Self-hosted CMPs remove the transfer question, provided your infrastructure stays within the EEA. That is a real simplification for organisations with strict data sovereignty requirements, such as public sector bodies or financial institutions.
Even a self-hosted setup can trigger transfer rules if your hosting provider's support team reaches your servers from outside the EEA.
Maintenance, updates and the hidden cost of control
Self-hosted CMPs need ongoing engineering effort. Regulatory changes, browser updates and security patches all fall on your team. The EU's planned ePrivacy Regulation will not be the trigger: the Commission withdrew the proposal, approving the withdrawal on 16 July 2025 and announcing it in the Official Journal on 6 October 2025. The live reform track is the Digital Omnibus, which would move cookie rules into the GDPR and is still a proposal as of October 2026. Whatever passes, a cloud CMP vendor ships the change. A self-hosted CMP needs your engineers.
Consider the maintenance surface:
- Banner JavaScript and interface components
- Consent storage database (backups, retention policies)
- Geo-detection logic for region-specific banners
- Google Consent Mode v2 integration
- TCF string generation and vendor list updates, if you use the TCF
- Security patching for the web server and dependencies
For a team with dedicated privacy engineers, this is manageable. For a small marketing team running a WordPress site, it is a serious commitment. A cloud solution removes that burden at the cost of less granular control.
Feature parity between the two models
Cloud CMPs compete on features. Geo-detection, region-specific consent models, scheduled cookie scanning, consent log storage and multi-language banners are standard in most commercial cloud platforms.
Self-hosted CMPs rarely match this feature set as installed. Building geo-detection that correctly identifies whether a visitor falls under the GDPR, the CCPA, the LGPD or POPIA, and serves the right banner variant, is a sizeable engineering project. Keeping a cookie classification database current is equally demanding.
Feature availability by hosting model
| Feature | Cloud CMP | Self-hosted CMP |
|---|---|---|
| Geo-detection | Built in | Must build or integrate |
| Automatic cookie scanning | Built in | Must build or integrate |
| TCF v2.3 string generation | Vendor-maintained, where the CMP supports the TCF | Must implement and update |
| Consent log | Built in | Must design database schema |
| Multi-language banners | Usually included | Must implement translations |
| Google Consent Mode | Pre-integrated | Must implement API calls |
| Rule changes | Vendor ships updates | Manual code changes |
When self-hosted makes sense
Self-hosting is worth the effort in specific scenarios. Large enterprises with dedicated privacy engineering teams, organisations in regulated sectors like financial services or healthcare, and public sector bodies with strict data residency mandates all have legitimate reasons to keep consent infrastructure in-house.
If your organisation already runs its own CDN, has a DevOps team that can manage another service, and faces pressure to avoid any third-party data processing, self-hosting removes a dependency and a data transfer risk.
The cost is real, though. Budget for at least one engineer spending part of their time on CMP maintenance, plus the infrastructure costs for hosting, CDN and database services.
When a cloud CMP is the practical choice
For most websites (small businesses, agencies, publishers and mid-market companies), a cloud CMP gives the same consent features with far less effort. The vendor absorbs the work of tracking rule changes, browser compatibility and infrastructure management.
Cloud CMPs also scale without intervention. Whether your site receives 1,000 or 10 million monthly visitors, the vendor's CDN handles the load. With a self-hosted solution, traffic spikes can overwhelm your infrastructure if capacity planning falls short.
The key is choosing a cloud vendor that offers EEA data residency and transparent data processing agreements. That combination gives you the convenience of SaaS without the data transfer headaches.
Hosting a CMP: short answers
Does a self-hosted CMP guarantee GDPR compliance?
No. Self-hosting controls where data is stored, but the GDPR also requires valid consent collection, proper record-keeping and respect for user rights. The hosting model is only one part of the picture.
Can a cloud CMP store consent data in the EU only?
Many cloud CMPs now offer EEA-only data residency. Check whether your vendor provides it and whether it covers all data flows, including support access and backups, because the EDPB treats remote access from a third country as a transfer.
Is a self-hosted CMP faster than a cloud CMP?
It can be, because serving scripts from your own domain removes extra DNS lookups and avoids some ad-blocker interference. But performance depends on your infrastructure and optimisation effort: a neglected self-hosted CMP can be slower than a well-tuned cloud alternative.
Do I need a DPA with my cloud CMP provider?
Yes. Your cloud CMP provider processes personal data on your behalf, which makes it a processor under Article 28 of the GDPR. A data processing agreement must be in place before you start using the service.
How much engineering time does a self-hosted CMP require?
Expect at least part of one engineer's time for ongoing maintenance, including rule changes, security patches, browser compatibility fixes and database management. The initial setup can take several weeks depending on feature scope.
Can I switch from self-hosted to cloud CMP later?
Yes, though migrating consent records needs careful planning. Consent logs collected under one system need to be kept and mapped to the new platform's format so you can still show what each visitor agreed to.
Try a cloud CMP that keeps data in the EU
Scan your site, review the cookies, then publish a banner that blocks trackers until visitors choose. Kukie.io keeps its servers in the EU, handles region rules, consent logging and script blocking, and you can start on the Free plan.
