Data residency. One server in Germany, object storage with no jurisdiction set, and a live page that says otherwise
Solidus offers no data-residency guarantee to anyone, has no regional deployment options, and no signed agreement specifying a storage location. Nothing here is legal advice.
The distinction that decides the whole page
"Our infrastructure is in Germany" and "your customers' document images are stored in the EU" are two different claims, and only the first one is supported.
- The application and chain infrastructure runs on a single server, hosted in Germany. There is exactly one place it physically runs, no multi-region deployment, no failover region, no regional options.
- Uploaded documents, selfies, voice audio and session recordings go to object storage, and that storage is configured with no jurisdiction restriction. The provider places and replicates objects according to its own policy rather than a region we have pinned.
So we cannot tell you which country a given customer's identity document is sitting in, and any sentence implying we can would be untrue.
Object storage supports a jurisdiction-restricted mode. We are not using it. That is a configuration choice with a real consequence, and it is checkable: a jurisdiction-restricted bucket resolves under a distinct endpoint, and ours does not.
Our own compliance page currently claims otherwise
As of 2026-07-31, verify.solidus.network/compliance advertises an "EU data residency option"
and states that a German regulator's residency requirement is "satisfied" by a Solidus EU region.
There is no EU region. There is no residency option. There is no product to select.
Those statements are wrong, and this page exists partly to say so. A residency claim is exactly the kind of thing a regulated buyer verifies in diligence, and finding it unsupported after signing is far worse for both parties than reading it here.
What a buyer with a localisation requirement should conclude
If your regulator or your policy requires data to remain in a specific country or region, we cannot meet that today. Not partially: there is no mechanism to configure.
This matters most in the market we care most about. Türkiye's data-protection regime restricts cross-border transfer of personal data, and a Turkish buyer cannot get an in-country deployment from us. Given that Türkiye is where our content actually converts, this is the gap most likely to end a real conversation, and we would rather it ended early.
And nothing on our roadmap commits to a date when that changes.
What would have to exist
- A jurisdiction-restricted storage configuration, which is a configuration change with operational consequences, not a product.
- Regional deployment of the application and database, which is not a configuration change.
- A data-processing agreement that actually specifies location. Ours is a draft template, not legally reviewed and not executed.
- Something independent confirming any of it, which is the same missing external audit named on SOC 2 and ISO 27001.
A vendor's own statement about where data sits is not evidence. It is the kind of claim that exists to be audited, and ours has not been.
Keep reading
- The OID4VP verifier, real endpoints, real policy knobs, and one of them means less than it reads
- EUDI wallet issuance, not certified, not recognised, and gated on a partner we do not have
- Trust anchors. There are two of them, and we control both
- Data minimisation, real at the disclosure step, and the opposite of minimal at the collection step