Modular AI stack · open source on TYPO3
A modular AI stack for TYPO3 — controllable, replaceable and adoptable in steps.
The Netresearch modular AI stack is not a toolbox but a value stream where each layer builds on the one below: security and identity foundation, governable AI base, content production and distribution. Built from open-source TYPO3 extensions — sovereign through freely chosen hosting and models you can run locally or self-hosted.
Why AI initiatives stall in existing systems
Not for want of models. For want of ownership, of an overview, and of decisions someone can still take back.
Departments sign up individually. Nobody knows which content goes where.
The same API key sits in three extensions, two configuration files and a repository.
What is missing centrally appears locally — with no log, no approval and no budget.
The invoice arrives monthly; the attribution to a project or a person never does.
Who approves a model? Who reviews the logs? Without an answer, every control is theory.
Switching provider means rebuilding every integration.
An assistant that may write without anyone agreeing is an incident with a lead time.
The stack grows with the problem.
Pick a layer. The diagram shows only what that layer adds; everything below it is inherited.
Value stream: from secured access to channels
Note: The diagram deliberately avoids repeating module rows. Each layer shows only what it adds — the full stack is in the detail panel. Security layer 0 is the foundation the AI, content and distribution layers build on.
Maturity
Maturity and version come from each project's own manifest, not from this page. Netresearch core modules and community dependencies are deliberately not presented as equals.
| Module | Role | Maturity | Latest release | Typical use | Responsibility boundary |
|---|---|---|---|---|---|
| nr-vault | Secret foundation | Beta | v0.15.0† | Credential storage | Makes no AI decision and sees no prompt. |
| nr-passkeys-be | Backend identity | Beta | v0.12.1† | Passwordless sign-in to the TYPO3 backend | Authenticates people. Grants no permission the backend user did not already have. |
| nr-passkeys-fe | Frontend identity | Beta | v0.6.0† | Passwordless sign-in for frontend users | Authenticates people. Authorisation and data access stay with the site's own rules. |
| nr-llm | Control plane | Beta | v0.28.0 | Central use of language models | Provider and model risks stay with the provider and the operator. |
| nr-browser-ai | On-device assistant | Beta | v0.5.0 | Page-level questions | Supported browsers and devices only. |
| nr-mcp-agent | Backend agent | Alpha | v0.9.0 | Controlled assistance in the backend | Writing actions require an approval. |
| Social network extensions | Channel distribution | Community | — | Publication from TYPO3 | Third-party vendors, their own maintenance state. |
† No product page of its own. Release and version come straight from the repository; the maturity is Netresearch's own assessment.
Community extensions are not maintained by Netresearch. Maturity, security and further development are the respective vendors' responsibility, so no maturity is stated here.
What the stack means for your role
The same architecture, five different questions.
Do we stay able to act?
Every layer is replaceable on its own. Switching provider is a configuration change, not a rebuild of the integrations. Run it in the cloud, in your own data centre, or mixed.
What leaves our network, and who may do what?
Keys are stored encrypted in the vault, never in the database. Permissions apply per capability, writing tools require approval, and every use leaves an entry. The data flow is documented on the product page, control by control.
What does it cost, and who causes it?
Budgets per user and period, analytics by provider, model and use case, and a fallback to cheaper or local models. Cost is visible before the invoice.
Does it help with writing without causing trouble?
Assistance in the editor, suggestions rather than silent edits, and answers that cite their source. Anything written goes through a human approval first.
How much do we have to build ourselves?
Inject a service instead of wiring up a provider. Caching, streaming, tool calls, error handling and fallback chains are built once, not per extension.
Operating models
The stack does not prescribe an operating model. It turns the choice into a configuration decision.
| Model | Where data is processed | Fits when | What it costs you |
|---|---|---|---|
| Commercial cloud provider | At the provider, outside your network | Quality and model choice decide | A contractual and data-protection review per provider |
| EU-hosted provider | At the provider, inside the EU | The processing location is prescribed | A smaller model selection than the large providers offer |
| Azure or an OpenAI-compatible endpoint | In your own cloud account | A framework agreement with the provider already exists | Commitment to the platform, not to the model |
| Self-hosted (Ollama, vLLM, LocalAI) | In your own infrastructure | Data must not leave the network | Your own operations, hardware and model maintenance |
| In the browser (on-device) | On the visitor's device | Page-level questions should be answered without a server call | Supported browsers and sufficiently equipped devices only |
| Mixed operation | Different per use case | Sensitive and uncritical cases are treated separately | More configuration and more to explain |
Who decides what
Technical controls only work once someone is named to operate them. This mapping is a proposal — your roles are called something else; the questions are the same.
| Decision | Typical role | How it is evidenced |
|---|---|---|
| Which providers are permitted | Architecture and data protection together | Provider configuration in the backend |
| Which budgets apply | Controlling | Per-user budgets, analytics by model |
| Who may use writing tools | Department head with security | Tool groups and per-capability permissions |
| Who reviews the logs | Security or internal audit | Analytics and the approval trail |
| When models are changed | Architecture | Model and configuration state, fallback chains |
| What happens after misbehaviour | The organisation's incident process | Logs, and switching off the affected configuration |
Where to start
Five entry points. Each stands on its own and blocks none of the others.
Connect language models centrally, set budgets, measure use. No new features for editors. The smallest step with an immediate effect on shadow AI.
nr-llmTranslation, alt text and drafts in the editor — on the same control plane, under the same budgets.
cowriter, nr-repurposeAnswer page-level questions on the visitor's device, with no server call. Clearly bounded, and a good first visible step.
nr-browser-aiAn assistant in the backend that reads, and asks for approval before any change. Alpha — for evaluation, not for unattended operation.
nr-mcp-agentSecurity, control plane, assistance, content and channels together. Worth it when the architecture decision is due anyway.
every layerOpen source and data sovereignty
Control over code, operation and models — as a property, not an add-on.
Every Netresearch module is an open-source TYPO3 extension on an enterprise CMS you can host yourself. Full sight of the code, no CMS lock-in.
nr-llm is provider-independent and talks to any provider or operator — from an EU cloud provider to your own infrastructure.
Sensitive cases run on local or self-hosted models — the data does not leave your environment.
Modules and repositories
The components of each layer, with a direct link to the public repository.
Security and identity
A secure, auditable secret and knowledge store as the foundation of the stack.
github.com/netresearch/t3x-nr-vault nr-passkeys-bePasswordless passkey sign-in for the TYPO3 backend.
github.com/netresearch/t3x-nr-passkeys-be nr-passkeys-fePasswordless passkey sign-in for the frontend.
github.com/netresearch/t3x-nr-passkeys-feAI base and governance
Controlled, traceable access to language models, with permissions, budgets and analytics.
github.com/netresearch/t3x-nr-llm nr-mcp-agentBackend assistant with MCP tool calling, built on nr-llm.
github.com/netresearch/t3x-nr-mcp-agent nr-browser-aiOn-device assistant for questions about the current page, with no chat API of its own.
github.com/netresearch/t3x-nr-browser-aiProduce and repurpose content
Turns existing knowledge into editorially usable formats, variants and text blocks.
github.com/netresearch/t3x-nr-repurpose cowriterAI-assisted writing inside the editor (TYPO3 / CKEditor).
github.com/netresearch/t3x-cowriter nr-landingpageGenerator for TYPO3 landing pages, driven by language models.
github.com/netresearch/nr-landingpageServe the channels
Existing TYPO3 community extensions can be used for distribution. They do not come from Netresearch; maintenance and security are the respective vendors' responsibility. A few examples:
Evidence
Every statement on this page can be checked. What is not here is not claimed either.
Every Netresearch module is public, with its release history and changelog.
github.com/netresearch Technical documentationArchitecture, interfaces and configuration per module.
nr-llm documentation Architecture decisionsWhy something is built the way it is, including the alternatives that were rejected.
Architecture Decision Records Measured usageReleases, downloads, contributors and dependent projects, collected daily and downloadable as a dataset.
Impact dashboardWhat is not claimed
- No blanket conformity with the EU AI Act, the NIST AI Risk Management Framework or ISO/IEC 42001. The modules support controls; whether an organisation is conformant is a legal and organisational assessment, not a property of an extension.
- No savings or return-on-investment figure. We do not know your volumes.
- No protection against wrong model answers. The stack bounds what a model may do — not what it says.
Frequently asked questions
Briefly: how the layers are built and how they fit together.
What is the modular AI stack?
A value stream of four layers, each building on the one below: the security and identity foundation (layer 0), the governable AI base (layer 1), content production (layer 2) and channel distribution (layer 3). Each layer inherits everything below it.
Which modules make up the security layer?
Layer 0 comprises nr-vault for a secure, auditable secret and knowledge store, plus nr-passkeys-be and nr-passkeys-fe for passwordless passkey sign-in in the TYPO3 backend and frontend.
Why is the AI base separated from security?
Access, secrets and identities are secured first (layer 0) before nr-llm establishes controlled, traceable AI access (layer 1). That keeps AI use auditable from the start.
Which AI tools produce content?
Layer 2 uses nr-repurpose to turn knowledge into editorially usable formats, cowriter for AI-assisted writing in the editor, and further tools such as nr-landingpage. The backend agent nr-mcp-agent belongs to the AI base (layer 1).
Is the stack open source and TYPO3-based?
Yes, for every Netresearch module. TYPO3 is an open-source enterprise CMS you can host yourself. The channel layer consists of community extensions with their own licences and maintenance states.
How does the stack support data sovereignty?
Through two properties: the Netresearch part is open source and built on the self-hostable TYPO3 platform, and nr-llm is provider-independent — any provider or operator, or local and self-hosted models. Sensitive data stays in your environment if you configure it that way.
Where is the best place to start?
With central provider and cost control. It acts immediately against shadow AI and duplicated keys, and it blocks none of the later steps.
Plan the AI stack for your use case
We work through which layers you need, which operating model fits your constraints, and what a first, small step looks like.
Something wrong on this page? An issue in the repository will not get lost. Open an issue