Self-hosting a support tool means you choose where the primary data lives, which is a real step toward data residency. It is not the whole answer. The mail provider that sends notifications, the CDN in front of your pages, the error tracker, the analytics script and the AI provider behind an automated reply can each move data somewhere else entirely while the database sits exactly where you put it.
We are not lawyers, and nothing on this page is legal advice. It describes what residency means as a technical fact, how to find out where your own dependencies actually route data, and what a few named vendors publish about their own hosting regions. What that means for your specific obligations is a question for you and your own adviser.
This page is one part of a larger guide. For the practical case for running your own support centre, see self-hosting a feature request board.
What does data residency actually mean?
Data residency is a geographic fact: which country or region a given piece of data is physically stored in, at rest, right now. It says nothing on its own about who can access that data, under which country's laws, or which legal system governs a dispute about it. Two systems can store the same record in the same city and still sit under different rules, depending on who owns the infrastructure and where that company is headquartered. Residency answers "where", not "under whose authority", and the two get confused often. The GDPR itself never uses the phrase: Chapter V of the Regulation governs "transfers of personal data to third countries or international organisations" instead.
That second question, usually called data sovereignty, is the one with actual legal weight, and nobody can answer it for you in general terms. Whether a given hosting arrangement satisfies whatever obligation applies to your business depends on your data, your customers, your contracts and your jurisdiction. This page sticks to the first question, because that one is checkable by looking at where things actually run.
Why doesn't choosing a region solve the whole problem?
Because a support site is never really one system. It is a database, plus everything that talks to it: a hosting platform serving the pages, a CDN caching them at the edge, an error tracker watching for crashes, an analytics script counting visits, and, if the tool automates replies, an AI provider processing the submitted text. Choosing a hosting region for the database answers exactly one line of that list. Every other line is a separate company, running its own infrastructure in its own region under its own terms, and each one is a place your data can end up regardless of where you deliberately put the database.
A support centre hosted in Frankfurt whose transactional email routes through a provider whose nearest data centre is on another continent has not achieved single-region residency. It has achieved it for one component and quietly given it up for another, and the only way to know which is true is to check each dependency by name. Where one of them does route personal data out of the UK, the ICO calls that a restricted transfer and applies its own set of rules to it.
How do you actually enumerate the dependencies?
Start from what the tool does, not from what you assume it needs. A support centre that only stores posts and serves pages has a short dependency list. One that sends email, posts to chat tools or automates replies has a longer one, and each addition is a separate company to check.
| Dependency | What to check | Why it matters |
|---|---|---|
| Primary hosting | Which region the platform actually runs in, not where you selected it in a dashboard | The one line residency choices usually cover |
| CDN | Where content is cached, and whether the provider logs or processes request data outside that region | Caching often happens globally by default |
| Transactional email | Which region the sending provider's infrastructure is in, and whether message content passes through it, not just the address | Notification content can include names and submitted text |
| Error tracking | Whether logs can include submitted content, and where that service stores it | An easy blind spot, since nobody thinks of it as "data storage" |
| Analytics | Whether it is present at all, and where that vendor is based | The simplest fix is often to run none |
| AI provider | Which provider processes submitted text, and where that processing happens | Usually the least visible dependency, carrying the most user content |
| Backups | Where backup copies are stored, and whether that differs from the live data | A backup in a different region is still data in that region |
Every row is a separate company with its own published terms, and the honest way to check each one is to read what it currently states about its own infrastructure, not to infer it from where you host the rest of the stack.
What does this look like for a tool like Docket?
Docket's free edition sends no email, runs no analytics and loads no external scripts, so its dependency list is short: whatever host you choose for the static files, and nothing else. The paid tiers add real dependencies alongside the features that need them: email and voter notifications go through whichever transactional provider you configure, Slack and Discord alerts go to whichever workspace you connect, and agentic workflows send the relevant text to whichever AI provider you set up. Each is a choice you make, worth checking against the table above rather than assumed. The paid tiers also run a once-a-day update check against a static release file, carrying no key, repository name or domain identifier, which is not a route for any submitted content.
One payment, no subscription, unlimited products.
Do hosted tools ever offer the same thing?
Sometimes, yes, and it is worth saying plainly rather than pretending self-hosting is the only route to a chosen region. Featurebase publishes EU hosting in the Netherlands and Germany. Nolt.io runs a separate, air-gapped EU product. Neither fact makes the case for or against self-hosting on its own; the honest comparison is between what each option's own dependency list actually looks like, not "self-hosted equals regional" against "hosted equals not."
Whatever tool you evaluate, the same table applies: a vendor's headline hosting region is one line, and the email provider, CDN, analytics and any AI feature underneath their product are separate lines you are entitled to ask about by name.
What does "self-hosted" actually put in your hands here?
Docket stores every post as a Markdown file in your own repository. That is a genuine advantage here: the primary content is not sitting on a third party's servers, under a third party's terms, subject to a dependency list you cannot see. It is also a genuine responsibility, because the residency and personal-data questions that used to be someone else's to answer are now yours: where your repository host stores its data, who has access to it, and what your own dependency list looks like once you add the features that need one.
Frequently asked questions
What is data residency, in plain terms?
The physical fact of which country or region a piece of data is stored in right now. It does not by itself describe who is legally allowed to access that data, which is a separate question usually called data sovereignty.
Does self-hosting automatically give me data residency?
No. Self-hosting lets you choose where the primary data lives, which is a real step. It does not cover the other services a support tool typically depends on, such as transactional email, a CDN, error tracking, analytics or an AI provider, each a separate company with its own infrastructure and region.
What is the difference between data residency and data sovereignty?
Residency is where data is physically stored. Sovereignty is which country's legal system has authority over that data, which can differ from the storage location depending on who owns the infrastructure and where that company is based. Which matters for your situation is a question for your own adviser.
Do any hosted support tools offer regional hosting?
Some do. Featurebase publishes EU hosting in the Netherlands and Germany. Nolt.io runs a separate, air-gapped EU product. Checking a vendor's published hosting regions directly is the reliable way to confirm this.
Is this page legal advice about GDPR or data residency requirements?
No. It describes what data residency means as a technical fact and how to enumerate a support tool's dependencies. Whether any particular arrangement satisfies your obligations under GDPR or any other regulation is a question for you and your own adviser.