CTXR

A file-based content platform built on Schema.org semantics. No database, no framework, no build step. Each space is a self-contained subdomain with its own data, templates, and configuration.

CTXR stores content as flat JSON files using Schema.org types. A compiler resolves the references between nodes into a prebuilt graph that visitors read directly from disk. Editors work on drafts that compile into live pages on approval. The data is valid JSON-LD, so the same content a browser renders is the content a search engine indexes and a language model reads.

The short version

Nodes, not tables. Every piece of content is a node with a Schema.org @type — a Place, a Review, an ImageObject — stored as a JSON file and addressed by a stable @id.

A compiled graph. References between nodes are resolved at write time into a self-contained graph. A page opens one file and has everything it needs — no runtime joins, no query layer in the hot path.

The editor pays, the visitor doesn’t. The expensive work happens once, when an editor approves. Visitors read pre-built results.

Spaces are autonomous. Each space is an isolated tenant. The platform provides defaults; the space adapts them in its build/ folder and then runs on its own.

File-based, zero dependencies. PHP with no Composer, no database, no bundler. The filesystem is the database, and that’s the point.

Start here

In a hurry? The Quick Start takes you from zero to a running space in three steps. Want the reasoning first? Begin with the Foundations.

The reading journeys

The documentation is organised as a journey, from understanding why CTXR works the way it does, through building on it, to trusting it in production.

• Foundations — the architecture and the reasoning: the graph, the compiled model, who pays, the lifecycle, and why it’s file-based and AI-friendly. This is where CTXR earns its right to exist.
• Spaces & accounts — the platform model: what a space is, what an account does, collections and following, plans, and the adoption model.
• Build & customize — the developer’s work: the build/ folder, template helpers, nodes and types, theming and assets, the editing experience, automation, the API, and internationalisation.
• Reference — the concrete lists: template helper signatures, the API action catalogue, and editor attributes.
• Trust & operations — security, privacy and GDPR, reliability and recovery, observability, and accessibility.
• Reach — installable, offline-capable, location-aware mobile delivery (server-sent Web Push still landing).
• FAQ — common questions, answered.