Where data is stored, who can access it, and how to move it

This page answers four concrete questions: what is stored today and where; who can access it and how access is granted or withdrawn; what leaves your environment when you call an external model; and how far backup, export, and migration actually go.

Wherever we have not run something or the official documentation does not cover it, we say so instead of closing with “your data belongs to you.”

What is stored today, and where

• Resources in a Pod: files, conversations, and work records are stored in a Pod as resources. Which records an application can keep depends on how that application connects; there is no single answer.
• Xpod local profile: a SQLite file and local disk. No Redis or MinIO required.
• Xpod cloud profile: persistence in PostgreSQL and MinIO, with Redis for coordination.
• Hosted service: https://pods.undefineds.co/ responds (HTTP 200). We have not verified whether registration is open, so this page promises no account, quota, or price.
• Not confirmed as shipped: noting which version you accepted and which line you changed, and exploring your own model from records you choose to provide. Neither is at the point of being saved on your behalf.

Exact paths depend on your deployment and configuration; see Self-host Xpod.

Who can access it, and how access is granted or withdrawn

• Xpod keeps Pod resources, WebID identity, and access control at the core (the official README’s wording). Access permission belongs to the Pod itself, not to a private arrangement between applications.
• Granting: before giving an application access, look at what it wants to read and write. An application needs an authenticated session to read or write data; drizzle-solid’s pod(session) and drizzle(session) both build on that.
• Withdrawing: the official README does not document a single revocation interface or command, and we have not run one. What you can check today is the deployment document docs/deployment-modes.md and the repository’s documentation directory. Once you know which client and deployment you use, confirm revocation against the matching document. Until we verify the actual procedure, this section will not be padded with a guessed workflow.
• Deployment, identity, and access prerequisites: Self-host Xpod. Application-side authentication: the drizzle-solid quickstart.

What an external model request contains

• Storage location and request destination are two different things. Data sitting in your Pod does not mean a request is never sent anywhere else.
• Xpod exposes AI APIs (/v1/chat/completions, /v1/responses, /v1/messages, /v1/models) and sidecar paths (/-/sparql, /-/vector). Which model service a request finally reaches is decided by your configuration.
• So what goes out depends on which API you call and which material you pass. Before using an external model, check what the request contains and what the provider’s terms say.
• We will not make a blanket claim about where external requests end up. What can be stated is narrower: you choose what goes into the request, and you configure where it goes.

How far backup, export, and migration go

• Backup: for the local profile, back up the SQLite file and the disk directory; for the cloud profile, handle PostgreSQL and MinIO as the official deployment documentation describes. The README does not give backup commands and we have not run any, so treat the official deployment documentation as the source of truth. Make your own backup before you change or move anything.
• Export: Pod resources are exposed over standard HTTP and Solid interfaces with stable URLs, so you can take them out resource by resource. The official README does not promise a one-click export of everything into any other application, and we do not claim one. How much you can carry depends on whether the target application can read those resources.
• Migration: local and cloud are different storage backends, and the README does not provide a tool for moving between them. Before changing deployment location, work out how the data follows, and how identity and permissions are recreated.
• Moving application data: drizzle-solid gives exact reads and writes by resource id or full IRI, which suits moving application data item by item. It needs an authenticated session and is limited by what the target Pod supports; see the drizzle-solid quickstart.
• Entry points you can check:
  • Deployment and dependencies: https://github.com/undefinedsco/xpod and docs/deployment-modes.md
  • Hosted service: https://pods.undefineds.co/ (reachable; registration not verified)
  • Reading and writing data: the drizzle-solid quickstart
  • Problems: the LinX issue tracker by default; for anything Xpod-specific, the Xpod issue tracker

Related reading

• How the three pieces divide the work: What LinX, Xpod, and drizzle-solid each do
• Install and deploy: Install LinX first, or deploy Xpod first
• Read and write data from an application: drizzle-solid quickstart