Where does a Solidus pod physically live? One server, and a longer answer
One origin server, hosted by Hetzner in Germany. No regional deployment, no multi-region infrastructure, no contractual residency guarantee offered to anybody, and no date on the roadmap when that changes. The term is not-built in our own lexicon. Nothing here is legal advice.
Why anyone asks
A regulator, or a buyer's counsel, wants one sentence: if we are asked where this data sits, what do we say. Several regimes turn that into a hard requirement, and the one closest to our own stated market, Türkiye's cross-border transfer restriction, is one we cannot answer with an in-country deployment today, because there isn't one.
The simple answer, and what is genuinely good about it
There is exactly one place our infrastructure runs, and we can name it. That is not nothing: plenty of vendors cannot tell you where your data sits, and a short, checkable answer beats a long one that dissolves under questioning.
Two further properties are real and worth stating:
- Personal data is kept off the ledger, so the chain does not replicate anything personal across jurisdictions: there is nothing personal on it to replicate. Checked on one record, not established as systematic.
- The chain is four validators, all operated by us. On every other page that is the limitation. Here it is the reason the residency answer is short: there is no distributed set of foreign operators holding copies. The same fact reads well on exactly one page, and this is it.
The longer answer, which corrects our own entry
Our own lexicon says "a single server in Germany." That is true of the origin and incomplete about the path.
The surface sits behind a global edge network. On the request we made:
$ curl -sI https://pod.solidus.network/
server: cloudflare
cf-cache-status: DYNAMIC
cf-ray: a247c0f1294477ac-ATH ← the edge that served it. Not the origin.
Another host in this estate resolves to the same two addresses, so what you are seeing is the front door in front of everything, not something specific to pod.
What that means, stated without spin: the connection terminates at an edge location, which may be
in a different country from the origin, and request metadata transits it. DYNAMIC says the
response was not served from cache, so the content came from the origin, but "the content came
from Germany" and "nothing about your request left Germany" are different sentences, and only the
first one is ours to make.
Anyone answering a residency question with "our server is in Germany" is answering a narrower question than the one being asked. We had that narrower sentence in our own notes. It is corrected here rather than repeated.
What we cannot offer
- No regional or in-country deployment, of any kind, to anybody.
- No contractual guarantee of storage location: there is no signed agreement specifying one,
- No committed date. Nothing on the roadmap says when a second region appears. "Coming soon" would be an invention, so we are not saying it.
The scope limit on our own evidence
The only Solid-server configuration that actually exists in the repository is file-backed, it imports the file storage backend and a per-pod storage location, and the object-storage configuration the production start script points at is not in the repository at all. So the object-storage path for pods is unbuilt, not merely undocumented.
And that still is not proof of what production runs. The start script referencing a missing file means something else must be launching the deployed server, and the repository does not say what. What we have is consistent evidence, not a settled answer: the live host's behaviour matches the per-pod configuration that does exist. Its own deployment checkbox is unticked while the surface is plainly live, which tells you the document is stale rather than telling you the answer.
And our other storage settings carry no jurisdiction option, account, key, secret, bucket. A residency guarantee would need one, and there is nowhere to put it.
We would rather publish the gap in our own evidence than a confident sentence we cannot support.
The answer that actually works today, and it is not ours
Run your own pod. Solid is a protocol, the Community Solid Server is open source, and a pod you host in your own jurisdiction has whatever residency properties that jurisdiction gives it, with no dependency on where our server sits.
That is Solid's design doing the work, not ours, and it is the honest recommendation for anyone with a hard localisation requirement right now. What you would still depend on us for is a separate question, and it deserves its own page rather than a reassuring sentence here.