GDPR and a personal data pod: what changes, what doesn't

A pod changes where your data sits. It does not change who owes duties under the regulation, and we build nothing for compliance today, gdpr is not-built in our own lexicon, and no Solidus product may be described as compliant. There is no certificate to hold anyway: the regulation awards no badge to anyone.

Nothing on this page is legal advice. It is a description of a law and of our own posture against it, written by the people whose posture it is, which is exactly the kind of source you should read sceptically.

What a pod genuinely changes, and it is smaller than the pitch

Storage topology. Your data sits in storage you control rather than in each application's database. An application that reads a value from your pod on demand does not necessarily hold a copy afterwards.

That maps onto two of the regulation's principles, storage limitation and data minimisation (Article 5), as a design property, not as a compliance property. A design that makes over- collection awkward is worth something. It is not evidence that anyone has met an obligation, and we are not going to present it as one.

And it only holds if access control actually holds, a separate layer, with its own status, on its own page.

What it does not change, which is most of the regulation

Lawful basis. Article 6 still demands one for every use of personal data. Where the bytes live is not a lawful basis.
Who the parties are. A person storing their own data is a data subject, not a controller in the legal sense. Self-hosting exempts nobody who processes that data from their own duties.
Cross-border transfer rules, breach notification, records, impact assessments. All unaffected by storage topology.
Individual rights. Access, correction, portability, objection, and erasure, which collides with an append-only chain hard enough to need its own page.

So the honest summary of the architecture's contribution is: it can make some obligations easier to satisfy, and it removes none of them.

The part that goes against us: running your pod is processing your data

We operate the deployment at pod.solidus.network. Anyone who runs storage on someone's behalf is handling that person's personal data, and "the user holds their own data" does not remove us from that picture. A pod hosted by us is our processing to account for.

What the pod's own tables hold, read from the schema rather than assumed: an email address, a password hash, a pod URL and an optional identifier on users; then folders, files, credentials, records of what has been shared with the account, and connected applications.

And the harder half: the file contents are arbitrary. A user may put anything in their own storage, including categories the regulation treats as special. We cannot classify what we do not inspect, and we do not inspect it. That is good for the user's privacy and it is not a compliance answer, it makes some duties harder to discharge, not easier, and a page claiming otherwise would be selling you something.

The pod surface publishes no privacy policy

Checkable in the source: the route tree carries sign-in, sign-up, auth, onboarding, files, shared, search, apps and settings. There is no privacy, legal or terms route.

Note the evidence carefully, because the obvious check is worthless here. Requesting /privacy on this host returns 401, but so does every unknown path, because unrecognised requests fall through to the storage server. CONTROL: / returns 200 text/html, so the host is up.** A 401 therefore proves nothing about whether a page exists, and **the finding rests on the route tree, not on the probe.

What is already in place, because listing only absences would be inaccurate too

This is not nothing, and none of it is a compliance claim:

We removed live claims of compliance from production surfaces on 2026-07-31, because our own record forbids them. A record that gets enforced against our own marketing is worth more than a policy page, and it is the reason this page reads the way it does.
Personal data is kept off the chain. The record we resolved carries key material, timestamps, a version identifier and a recovery policy, and no personal fields. Verified on one record, not established as systematic.
Selective disclosure exists, proving a fact without handing over the document behind it, which
SCOPE, stated because the alternative is a borrowed credential: an enforced retention-purge job and a consent-record schema exist in another Solidus product, not in pod. They are real, and they are not pod's.

The documented path, and the decisions already taken

A written plan exists covering an impact assessment, records of processing, an appointed representative and a data-protection officer. All four are on the roadmap; none of them is done, and "documented" is a much weaker word than "in place".

Two decisions were recorded on 2026-07-31 and are worth stating plainly rather than glossing: there is no EU representative and no privacy counsel today, and both were scoped rather than appointed.

What would change this page: a published impact assessment · records of processing anyone can ask for · a named representative and data-protection officer · an independent examination of any of it. Until at least the first of those exists, "documented plan" is the whole of the claim, roadmap, not posture.

What you can check yourself today

Resolve a real identifier against our public endpoint and read the fields. It takes no credentials and an invented identifier returns null as the control, so what comes back is a real record. If you find a personal field in it, we have a problem and you should tell us: that is a more useful test of this page than anything we could assert.