Zero-Storage CMS: We Built a Content System That Never Touches Your Data

The Decisive CMS Question in 2026: "Where Does Our Data Live?"

Editor features used to decide CMS deals. Now the security questionnaire arrives first, and it asks two questions that a feature list cannot answer. Where does the content physically live, and who has the technical ability to read it?

A few things pushed the conversation there:

• Data residency rules with real penalties. The CMS GDPR Enforcement Tracker puts cumulative fines in the billions of euros, and cross-border transfers to unvetted sub-processors are a recurring theme in them.
• Sector compliance. In HIPAA healthcare, SOC 2 environments, and ISO 27001 financial firms, every external datastore holding production content is one more system in scope for audit.
• Lock-in that procurement has learned to price. Getting millions of documents, nested relations, and taxonomies back out of a proprietary SaaS datastore is a months-long project, and buyers now ask about it up front.

Cortex is our answer to that. It is a headless CMS that stores nothing of its own.

Instead of holding content in our cloud, it runs as a stateless layer over the client's existing database, whether that is PostgreSQL, MySQL, or MongoDB. The editorial interface is ours. The data never leaves their infrastructure.

Rendering diagram...

Defining the "Zero-Storage" Paradigm

In a standard SaaS headless CMS (Contentful, Sanity, Strapi Cloud), the vendor provides both the user interface and the persistent database. When content creators draft an article or publish a product catalog, that content is uploaded, indexed, and stored inside the vendor's multi-tenant cloud storage clusters.

A Zero-Storage Headless CMS eliminates this persistence layer entirely.

It functions as an ephemeral gateway:

1. When an administrator authenticates, Cortex initiates a secure connection directly to the client's enterprise database cluster.
2. The engine dynamically inspects the database schema, introspects tables or collections, and generates an administrative UI and GraphQL/REST API endpoints on the fly.
3. Every write, edit, publish, or delete operation is translated directly into database-native queries executed strictly within the client's private database.
4. When the session terminates, all credentials and ephemeral caches are flushed from volatile memory. Zero customer records ever touch persistent vendor disks.

Deep-Dive into the Core Engineering Architecture

Editing someone else's database, safely, without a schema you defined, took four pieces:

1. The Dynamic Adapter Abstraction Layer

One editing interface has to sit over three unrelated query languages. We compile content operations to an abstract syntax tree, then let a per-engine adapter emit the actual query:

2. Runtime Schema Introspection (No Static Config Files)

Most headless CMSs make you declare the content model twice, once in the database and once in a schema.js or content-types.json file, then keep the two in sync forever.

Cortex reads the database instead:

• On connect, it walks foreign keys, JSONB columns, indexes, and constraints.
• It generates form fields, relationship pickers, and validation rules from what it finds.
• Run a migration in the backend repo and the admin UI reflects it on the next reload. No config change, no redeploy.

The trade is that a badly named column produces a badly labeled field. Introspection is only as good as the schema underneath it, and we added a label override map for exactly that reason.

3. Ephemeral Memory Pipelines and Secure Credential Tunneling

Holding another company's production database credentials is the part of this architecture that has to be right:

• Credentials are encrypted with AES-256-GCM under customer-managed keys, so the client can revoke access without involving us.
• Decrypted connection strings live in memory for the life of a session and are never written to disk.
• Traffic between the CMS and the database runs over TLS 1.3, or over VPC peering where the deployment allows it.

4. Row-Level Security (RLS) Mirroring Layer

Application-level permission checks fail open. One missed WHERE clause in one code path and a tenant sees another tenant's rows. So we push isolation down to where it cannot be bypassed, using PostgreSQL's FORCE ROW LEVEL SECURITY:

Before each query, Cortex sets app.current_tenant_id with SET LOCAL inside the transaction, so the value cannot leak across pooled connections. From there Postgres enforces the boundary. A bug in our query builder produces an error, not a data leak.