Where you deploy an AI-built app changes its cookie footprint before you write a single line of consent logic. Vercel, Netlify and Cloudflare Pages each wrap your generated code in an edge network and an optional analytics product, and those layers set their own cookies and collect their own request data independently of what the app itself does.
An AI builder hands you application code. The host decides what happens at the edge. A vibe-coded app that looks identical in three browser tabs can carry three different sets of cookies depending only on where it runs, and that difference is a compliance variable most launch checklists miss.
Why does your hosting platform set cookies you never wrote?
Your hosting platform sits between the visitor and your application, so it can read and write cookies before your code runs. AI builders such as v0, Lovable or Bolt generate the front end and any API routes, but they do not configure the edge network, the CDN or the platform's built-in analytics. Those are host features you switch on in a dashboard, and several of them drop a cookie or log a request the moment a page is served. The result is a footprint the generator never produced and the prompt never described. This matters because what AI builders don't generate - the banner, the policy, the consent gate - is exactly the layer regulators inspect.
None of this depends on which builder you used. The cookie behaviour below follows the host, not the generator, so the same analysis applies whether the code came from a prompt-to-app tool or an in-editor assistant.
What cookies does each hosting platform set by default?
By default, the three platforms behave very differently. Netlify sets no cookies at all for its analytics, because it reads server logs rather than running code in the browser. Vercel's analytics is cookieless but loads client-side and starts collecting on page load. Cloudflare Pages, sitting behind Cloudflare's security network, sets a small group of security and bot-management cookies classed as strictly necessary. The table below summarises what each host adds before you install anything of your own.
| Hosting platform | Cookies set by default | Built-in analytics model | Consent implication |
|---|---|---|---|
| Vercel | None for analytics; only cookies your app or third-party scripts add | Web Analytics uses a hash of the request with a 24-hour session, plus Speed Insights; no cookies | Cookieless, but the component loads on page view with no consent gate, so a rejection is not honoured unless you wire it |
| Netlify | None by default; nf_ab appears only if Split Testing is enabled | Server-side, read from CDN logs, with no client code | No cookie is set for analytics; nf_ab is functional and worth disclosing |
| Cloudflare Pages | __cf_bm, cf_clearance, plus __cflb and __cfruid | Cloudflare Web Analytics is cookieless | Cookies classed strictly necessary; disclosure recommended, classification contested in some EU jurisdictions |
Vercel: cookieless analytics that still ignores your banner
Vercel Web Analytics identifies visitors with a hash generated from the incoming request rather than a stored identifier, and discards the session after 24 hours, according to Vercel's own analytics documentation. No cookie is set, which removes the storage trigger that analytics cookies normally pull. The catch is behavioural, not technical: the @vercel/analytics component begins reporting page views the moment it mounts, with no built-in consent check. A visitor who rejects analytics still generates data unless you conditionally render the component behind your own consent state. Speed Insights behaves the same way for Core Web Vitals. Automatic tracking can also capture URLs and query parameters holding a user ID, token or order number, so a beforeSend hook is needed to redact anything personal.
Because most Vercel projects are Next.js apps, the consent gate belongs in a client component that reads your stored preference before mounting analytics, rather than in the layout where the script would fire on every route.
Netlify: the only host that sets nothing by default
Netlify Web Analytics runs entirely on the server, pulling page views from CDN log data with no JavaScript and no cookie, which Netlify states is GDPR compliant out of the box. That makes it the quietest of the three by default. One feature changes the picture: Split Testing. When an A/B test is active, Netlify's CDN sets an nf_ab cookie holding a random value between zero and one that decides which branch a visitor sees. It is a functional cookie rather than a tracking one, but it is still stored on the device, so it belongs in your cookie policy, and if the test runs inside an iframe it needs the SameSite attribute set to None with the Secure flag. Turn Split Testing off and a static Netlify site can genuinely ship with zero platform cookies.
Cloudflare Pages: strictly necessary, but contested
Cloudflare Pages inherits Cloudflare's edge network, which sets a handful of security cookies described in Cloudflare's cookie documentation. The main one is __cf_bm, a bot-management cookie that expires after 30 minutes of inactivity and holds an encrypted bot score. cf_clearance records that a visitor passed a challenge, while __cflb and __cfruid support load balancing and rate limiting. Cloudflare classes all of these as strictly necessary and generated independently of any user identifier, and its Web Analytics product is cookieless. The duty to disclose them falls on you, the site operator, not on Cloudflare. Whether they are truly exempt from consent is where opinions split: guidance under Germany's TDDDG treats the necessity of CDN cookies as contested and recommends disclosure at minimum. By default Cloudflare processes this data in the United States, with an enterprise Data Localisation Suite available to keep it in the EU.
Do these platform cookies actually need consent?
The test is the same regardless of host: under Article 5(3) of the ePrivacy Directive, storing or reading anything on a visitor's device needs prior consent unless it is strictly necessary to provide a service the user explicitly asked for. A shopping-cart cookie clears that bar. A bot-management cookie is defensible as strictly necessary for security, which is why Cloudflare and most legal analyses treat __cf_bm as exempt. The grey area is analytics: a cookieless beacon avoids the storage trigger entirely, but the moment a platform stores an identifier or a preference, consent logic applies.
The ePrivacy Directive governs the storage of the cookie itself, while the GDPR's consent requirements govern the personal data that follows. The practical move is to separate two duties that get conflated: disclosure, which means listing every cookie in your policy, and consent, which means asking before non-essential storage happens. Security cookies usually need the first and not the second; analytics usually needs both.
Does "cookieless" analytics really mean no consent needed?
Cookieless removes one trigger, not every obligation. Netlify's server-side logs and Cloudflare Web Analytics avoid device storage, so the ePrivacy cookie rule does not bite. Vercel's hash-based counting is also cookieless, but two questions remain. A hash derived from IP address and user agent can, in some readings, still be personal data under the GDPR even when no cookie is stored, so a lawful basis and a privacy-notice entry are prudent. Vercel also loads client-side and does not gate itself, so an opt-out has to be enforced in your own code. Server-side tools sidestep both problems because nothing runs in the browser at all. If avoiding banners is the goal, privacy-preserving analytics that never touch the device are the cleaner route, though they still belong in your privacy notice. This nuance is drawn from each platform's published privacy documentation rather than its marketing.
Who is the data controller when your host processes visitor data?
You are. For the visitor data your site generates, the hosting platform acts as a data processor and you are the controller, which means the legal duty to obtain consent sits with you. Vercel's data processing addendum states this plainly: the customer is solely responsible for obtaining and maintaining the consents needed before data is processed, in line with Article 28 of the GDPR. The practical steps are to sign the platform's DPA, usually a click in the dashboard, and to list the host and its sub-processors in your privacy policy. Location matters too. Vercel and Cloudflare are American companies, and by default some processing happens outside the EU, which pulls in the rules on cross-border data transfers. Both offer transfer mechanisms, and Cloudflare adds an EU data-localisation option, but the responsibility to document the transfer stays with you.
Where your app lives matters less than where your visitors are
Hosting location does not decide which law applies - your visitors' location does. Cookies fall under the ePrivacy Directive, transposed into national law such as Article 82 of the French Data Protection Act, and that sits outside the GDPR's one-stop-shop. The CNIL used exactly this reasoning in September 2025 to fine Google 325 million euros and SHEIN 150 million euros for cookie breaches affecting French users, regardless of where either company or its infrastructure sat. The SHEIN decision is the one to study: advertising cookies were dropped as soon as a visitor arrived, before any interaction with the banner, and continued after the visitor clicked reject.
That is the precise failure a host-injected analytics component reproduces when it loads on page view without a consent gate. Deploying in Frankfurt does not shield an app whose analytics fires before consent; serving French or German visitors is enough to bring their rules into scope. Mapping obligations by visitor region is the reliable approach, not by the region of the data centre.
How do you make a hosted AI-built app compliant?
Start from what the app actually ships, not what the builder claims. Run a cookie audit against the deployed URL so you see the host's cookies alongside your own, then work through five steps. Gate every client-side analytics component, Vercel's included, behind a stored consent preference so a rejection is honoured. Classify the host's security cookies correctly: __cf_bm and its siblings as strictly necessary, anything analytics-related as non-essential. Disclose every cookie, including the platform's, in your policy, and name the host as a processor. Sign each provider's DPA and record where data is processed. Honour reject and withdrawal so no non-essential cookie survives a no.
A cookie scanner run against the live deployment is the fastest way to confirm the list matches reality, because the gap between the generated code and the served page is exactly where these cookies hide. The builder decides what your app does. The host decides what else gets set. Both are yours to disclose.
Frequently Asked Questions
Does Vercel Web Analytics need a cookie banner?
Vercel Web Analytics is cookieless, so it does not trigger the ePrivacy cookie-consent rule on its own. It still loads without a built-in opt-out and may process data that counts as personal under the GDPR, so gating it behind consent and listing it in your privacy notice is the safer setup.
Is the Cloudflare __cf_bm cookie GDPR compliant?
Cloudflare classes __cf_bm as strictly necessary for bot management, and most analyses accept it as exempt from consent on that basis. You are still expected to disclose it in your cookie policy, and some EU jurisdictions treat the necessity of CDN cookies as contested, so disclosure is the minimum.
Does Netlify set any cookies by default?
A standard Netlify site sets no cookies for its analytics, because data comes from server logs rather than browser code. The one exception is the nf_ab cookie, which appears only when Split Testing is enabled and stores which test branch a visitor sees.
Do I need consent if my analytics is cookieless?
Cookieless analytics avoids the cookie-storage rule, but consent can still apply if the tool processes personal data such as an IP-derived hash under the GDPR. Server-side tools that run nothing in the browser have the weakest claim to needing a banner, though they still belong in your privacy notice.
Does hosting my app in the United States break GDPR?
Hosting in the United States does not break the GDPR by itself, but it usually means visitor data is transferred outside the EU, which needs a documented transfer mechanism. Providers such as Vercel and Cloudflare offer these, and Cloudflare also has an EU data-localisation option for eligible plans.
Who is responsible for cookie consent, me or my hosting provider?
You are. The hosting platform acts as a data processor for your visitors' data, and the duty to obtain consent sits with you as the controller. Signing the provider's data processing addendum and disclosing it as a processor is part of meeting that duty.
Scan the App You Actually Shipped
If you have deployed an AI-built app to Vercel, Netlify or Cloudflare Pages, the cookies on the live page rarely match the generated code. Kukie.io scans your deployed URL, detects first-party and platform cookies, and helps you categorise and disclose them.
