What LinX, Xpod, and drizzle-solid each do

These three pieces are three positions in one system, not three separate projects. You can use just one of them, but together they explain the division of labor.

Anything marked Now on this page has public material you can check. Anything marked Next or Later is still planned, not shipped.

LinX is the layer you work in

LinX is the client you open directly. You give it material and your requirements, and it produces a result you can keep revising.

• Now: the repository and its release record are public. The latest entry in the LinX release record is linx-v0.3.33 (2026-06-30), and its only asset is a .tgz package file.
• Not verified: desktop installers, per-platform system requirements, first launch, and the connection flow. We do not present unverified capability as something you can already use.
• How to get started: Use LinX.

Xpod is the layer that stores data and serves APIs

Xpod stores data and exposes interfaces. The official README describes it as a local-first Pod runtime, built internally from Community Solid Server plus an API layer behind one gateway.

• Now: two deployment profiles, local (SQLite plus local disk, no Redis or MinIO required) and cloud (PostgreSQL, MinIO, Redis); commands such as bun run local and bun run cloud; the library entry point startXpodRuntime; sidecar paths /-/sparql and /-/vector; AI APIs /v1/chat/completions, /v1/responses, /v1/messages, /v1/models, and /v1/chatkit.
• Marked planned by the official README: /-/terminal.
• Not verified: our team has not run a Xpod deployment. The startup commands and dependency requirements are in Self-host Xpod, quoted from the official README.
• Where things live, who can see them, and how to move them: Storage, access, and migration.

drizzle-solid is the data layer for applications

drizzle-solid is the data layer for application developers. It stores application-owned data in a Solid Pod with typed schemas, and offers two API styles: the Solid-first pod() and the Drizzle-shaped drizzle(). Both use the same runtime; the difference is API shape, not storage behavior.

• Now: the npm package @undefineds.co/drizzle-solid, at version 0.3.24 when we checked, depends on drizzle-orm. The official README documents podTable, pod(session), drizzle(session), and an examples/ directory.
• Not verified: we have not run the official examples. Installation source, authentication prerequisites, and read/write targets are in the drizzle-solid quickstart.

How data, identity, and requests move

Keep these three separate. Mixing them is the easiest way to reach a wrong conclusion.

Data: applications read and write Pod resources over Solid’s HTTP interface. Xpod’s local profile keeps data in SQLite and on local disk; the cloud profile keeps it in PostgreSQL and MinIO. drizzle-solid maps application objects onto Pod documents and resource ids: base defines where documents live, and id is a base-relative resource id such as post-1.ttl.

Identity: Xpod keeps Pod resources, WebID identity, and access control at the core. To read or write through drizzle-solid, both pod(session) and drizzle(session) need an authenticated session first. In other words, an application works with one specific user’s identity and permissions rather than going around access control.

Requests: application reads and writes against the Pod go over the Solid interface, and collection queries go through /-/sparql. Calling an external model is a separate matter: the request goes to the model service you configure, and what it contains depends on which API you call and which material you pass. Storage location and request destination are explained separately in Storage, access, and migration.

Now, next, and later

Stage	What it covers	What you can check
Now	Keeping files, conversations, and work records in a Pod; applications reading and writing Pod data through an authenticated session	Xpod’s local and cloud profiles; the official examples for drizzle-solid 0.3.24
Next	Noting which version you accepted and which line you changed; exploring your own model from records you choose to provide	Not confirmed as shipped; this site labels both as Next
Later	Letting LinX handle more small things inside the limits and standards you set	A long-term direction; what it may take on and what must always ask you first stay yours to decide

The official roadmaps list further planned items: /-/terminal is marked planned in the Xpod README, and drizzle-solid publishes 2026 priorities including schema lifecycle and migration, and cross-Pod exact operations. Those are official plans, not capability this site has accepted as working.

Where to start doing something

• Use LinX: Use LinX
• Deploy Xpod: Self-host Xpod
• Connect an application: drizzle-solid quickstart
• Access and migration: Storage, access, and migration