What does your feature entail? What is it for?
This feature requests the addition of Kagi-operated server infrastructure physically located within the European Union — ideally in multiple EU member states to ensure redundancy — to handle search queries, account data, and associated telemetry for EU-based users. The goal is twofold: to give EU users a credible data sovereignty guarantee (their searches and account data never leave EU jurisdiction), and to deliver meaningfully lower latency for users in Europe, particularly in Western and Northern Europe where round-trips to US-based infrastructure add noticeable delay.
Given Kagi's positioning as a privacy-first, user-respecting search engine, EU infrastructure would be a natural extension of those values — and would directly address a real concern for privacy-conscious European users who are aware that data processed on US servers falls under US jurisdiction regardless of contractual protections.
How will it affect existing workflows or user experience?
For most users, the change would be invisible and purely beneficial: queries routed to the nearest EU node would return faster, and account data would remain within GDPR-governed infrastructure. Existing accounts would require no migration unless users actively opt into EU-only data residency.
A meaningful UX addition would be a Data Residency setting in account preferences — allowing users to explicitly choose EU, US, or "nearest available" routing. This is especially relevant for users in regulated industries (healthcare, legal, finance) or public sector roles where data residency is a compliance requirement, not just a preference.
For Kagi as a business, EU infrastructure would unlock adoption among organisations and teams currently blocked from using Kagi due to procurement or DPA (Data Processing Agreement) requirements — a real barrier to the Teams and enterprise tiers gaining traction in Europe.

Exact User Journeys & Usage Scenarios

The Privacy-Conscious Individual (e.g., a German or French consumer)
A user in Hamburg opens Kagi settings after reading about CLOUD Act implications — the US law that can compel American companies to hand over data stored anywhere in the world. They navigate to a new "Data & Privacy › Data Residency" setting, select "EU only (Frankfurt)", and from that point forward every search query, result click, and personalisation signal is processed and stored exclusively on EU soil. A small persistent badge — similar to how Mullvad VPN or ProtonMail display jurisdiction indicators — shows "🇪🇺 EU" in the Kagi interface footer as quiet confirmation.
The Public Sector Employee
A civil servant at a Scottish council or a French mairie wants to use Kagi for research but their IT policy requires all web services to process data within the EEA. Currently, Kagi cannot satisfy this requirement at all — the user simply cannot use it. With EU infrastructure and a formal Data Processing Agreement (DPA) tied to EU-resident data, Kagi becomes procurable. The IT admin adds Kagi to the approved tools list, and the employee uses it daily with full policy compliance. This mirrors how Fastly, Cloudflare, and AWS EU regions are sold to public sector — the feature is as much a procurement unlock as a UX one.
The Teams/Business User
A small law firm in Amsterdam subscribes to Kagi Teams. Under GDPR Article 28, they must ensure any data processor they use operates under adequate safeguards. Today this is a grey area with US-based Kagi. With EU infrastructure, the firm's DPO (Data Protection Officer) can sign a standard GDPR-compliant DPA with Kagi, mapping to processing that never leaves the EU. The workspace admin gets a "Data Residency: EU" toggle in the Teams dashboard — analogous to how Notion, Slack, and Atlassian now offer EU data residency as a paid workspace setting. Slack launched this in 2021 specifically because enterprise customers were blocked without it.
The Speed-Sensitive Power User in Northern Europe
A developer in Perth, Scotland runs Kagi as their default search across browser, Alfred, and API integrations. Routing currently goes to US infrastructure. With EU edge nodes, latency for the search API drops from _180ms to _40ms for a Dublin or Amsterdam PoP — comparable to what Algolia and Typesense users experience when switching from US to EU regions. The user doesn't configure anything; Kagi simply routes to the nearest node by default. The difference is felt immediately in the snappiness of instant search results and the Quick Answer AI responses.
The Developer Using Kagi's API
A developer building a Go application that wraps Kagi's search API (for a self-hosted tool like Gather, for instance) adds a single request header or URL parameter — region=eu — to pin their API calls to EU infrastructure. This is exactly how Algolia (appId maps to a region), OpenAI (EU data residency in their Enterprise tier), and Typesense Cloud (choose cluster region at creation) implement it. For GDPR-compliant apps, this parameter becomes a hard requirement in the integration, not optional.
How comparable products implement this
Product
Implementation
ProtonMail / ProtonVPN
Swiss/EU servers by default; jurisdiction displayed prominently in UI
Slack
EU data residency as a paid workspace setting; admin toggle in org settings
Notion
EU data residency for Business/Enterprise plans; DPA available on request
Fastly
Customer can restrict POP usage to EU-only via shield/origin config
Algolia
Region chosen at index creation; EU region (DSN routing to Frankfurt/Dublin)
Brave Search
EU-based infrastructure already; marketed as a differentiator vs Google
Brave Search is the most directly relevant comparison — they explicitly market EU data processing as a trust signal. Kagi, with its stronger privacy positioning, is better placed to make this a flagship feature rather than a footnote.
Extension of existing features
Search Personalisation: EU-resident user profiles would remain on EU servers, meaning Kagi's personalisation engine (lenses, result rankings, blocked domains) continues working — just processed domestically. No loss of functionality.
Kagi Assistant / AI answers: The AI inference layer would need EU-hosted model endpoints (or explicit contractual coverage via providers like Mistral, which is Paris-based, or Azure EU regions). This is the most complex piece, but it's exactly the gap users will ask about.
Privacy Pass / billing: Payment data is already handled by Stripe (which has EU data residency options) — this piece is likely simpler than it appears.
The core ask is simple: give EU users a setting they can point to and trust, backed by infrastructure that makes the promise legally enforceable. The product already has the ethos. The infrastructure would make it structural.