Many applications.
One process.
Each kept apart.
A self-hosted substrate that runs all of your apps from one core, hands them sign-in, data, secrets, APIs and serving as shared capabilities, and never lets one app reach into another.
Nodus is Latin for knot. The tangle and the hub are the same points.
Everything below is in the release we are building now. Short statements, no hedging. Each one is something you would otherwise assemble from three tools and a weekend.
A shop, a blog, an internal tool and an API can share one server and one core, and still none of them can see another's data, sessions or secrets. Isolation is how the system is built, not a setting you remember to turn on.
Put related apps in an app group and a person signs up once: same password, same second factor, one place to reset it. What that account may do is still decided app by app, and apps in other groups never learn the account exists.
Groups are how one install hosts things that must not know about each other: separate companies, departments or brands. Each group has its own sign-in realm and its own users, roles decided per app, and its own data. Nothing crosses a group line unless both sides declare it, or one app calls another's API with an API key scoped to exactly that.
Serve static files, route a single-page app, or stand a process in another language behind the built-in proxy. Certificates are issued and renewed for you. One place to configure all of it.
Pick a starter: a static site, a React or Astro single-page app, an API-only app, or a Python app. Each one arrives with sign-in pages and the SDK already pointed at your install, registered in a group, bound to a host. Open it and start on the part that is yours.
$ pn generate app shop --preset=spa --framework=react
--preset=<p> static | spa | api-only | python-basis
--framework=<f> react | astro (spa preset only)
--group=<slug> target app group (created if new)
$ Declare a model whose parts live in different stores: a row in Postgres, documents in MongoDB, a live field from someone else's HTTP API. Ask for one record and get one object back, already joined. Your code never learns which store held which piece.
// three kinds of source
"adapters": {
"pg_main": { "type": "postgres", "connection": "…" },
"mongo_orders": { "type": "mongodb", "connection": "…" },
"carrier_api": { "type": "rest", "connection": "…" }
}
// the app binds a resource to each, then declares a model
"resources": {
"customers": { "backing": { "adapter": "pg_main" } },
"orders": { "backing": { "adapter": "mongo_orders" } },
"shipments": { "backing": { "adapter": "carrier_api" } }
},
"data": { "models": {
"customers": {
"fields": {
"id": { "type": "uuid", "primary": true },
"name": { "type": "string" },
"plan": { "type": "string" }
},
"relationships": {
"orders": { "type": "hasMany", "model": "orders",
"foreignKey": "customerId" },
"shipments": { "type": "hasMany", "model": "shipments",
"foreignKey": "customerId" }
}
}
}}const customer = await pn.custom('data.get', {
resource: 'customers',
query: { where: { id: customerId } },
include: ['orders', 'shipments'],
}){
"id": "…",
"name": "Northwind Bakery", // a Postgres row
"plan": "team",
"orders": [ // MongoDB documents
{ "id": "…", "total": 84.5, "items": [ … ] }
],
"shipments": [ // live from the carrier's API
{ "carrier": "…", "status": "in_transit" }
]
}A federated query fans out to several stores at the same time, feeds the result of one into the filter of the next, and returns a single answer that names which parts came back and which did not. The stores can be SQLite, Postgres, MySQL or MariaDB, SQL Server, MongoDB, Redis, Qdrant, or a plain HTTP API.
The model API for everyday calls. NodusQL when you want one dialect that PN translates for every engine underneath, SQL table, document collection or vector index alike. Declared raw statements for the hard ones: joins, window functions, each database's own features, written as real SQL in your app's own files with named parameters. Raw statements and NodusQL can both act as sources inside a federated read.
await pn.custom('data.query', {
resource: 'orders',
where: { status: 'paid',
total: { $gt: 50 } },
limit: 20,
})SELECT id, total, status
FROM orders
WHERE status IN ('paid', 'shipped')
AND total BETWEEN 50 AND 500
AND tags CONTAINS 'gift'
ORDER BY placedAt DESC
LIMIT 20-- statements/top_customers.sql
SELECT c.id, c.name,
SUM(o.total) AS spent
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE o.placed_at >= :since
GROUP BY c.id, c.name
ORDER BY spent DESC
LIMIT 10Scaffold it, add an endpoint, deploy, mint a key. No server to write. The same endpoint answers over REST, through the SDK, and as a tool to AI assistants over MCP, each behind an API key you issued and can revoke.
$ pn api new orders --app=shop
$ pn api endpoint add orders list --read
$ pn api deploy orders
$ pn api key create orders --for=warehouse
✓ key issued (shown once)
$ TypeScript and Python, kept at parity by a machine-checked matrix, so a capability in one is a capability in the other. The TypeScript SDK adds React hooks for sign-in, queries, mutations, permissions, uploads and live updates, and Astro helpers for server-side sessions and routes.
import { useCurrentUser, useQuery } from '@procuratornodus/sdk/react'
const user = useCurrentUser()
const orders = useQuery<Order[]>('data.query', {
resource: 'orders', limit: 20,
})from procuratornodus import ProcuratorNodusClient
pn = ProcuratorNodusClient(...)
orders = await pn.custom("data.query", {
"resource": "orders", "limit": 20,
})Subscribe to a capability and changes arrive as they happen, over a connection that reconnects on its own when the network drops. Loop over it in plain TypeScript, or hand it to a React hook and render the latest value.
const stream = pn.subscribe<Order>('orders.changes', {})
for await (const change of stream) render(change)
// the same stream, as a hook
const { data } = useSubscribe<Order>('orders.changes', {})An API names the secrets it needs and the hosts it will talk to, and that is the whole declaration. The value of a secret never appears in your repository. A call to a host you did not list is refused before it leaves.
"needs": {
"calls": ["data.query"],
"hosts": ["api.carrier.example"],
"secrets": { "CARRIER_TOKEN": ["api.carrier.example"] }
}
// the token lives in the vault; this file only names it
// and binds it to the one host it may be sent toThe setup wizard writes the configuration and registers PN as a system service. The first start prints the link to the admin console, where you add capabilities, configure them and watch health. From the terminal, pn status and pn doctor tell you the same story.
$ pn init
Procurator Nodus — setup wizard
✓ Project directory ~/procurator
✓ Process manager systemd
✓ Admin credentials configured
✓ Config written ~/.pn/config.json
Setup complete. Run pn start to boot.
$ pn start
Starting Procurator Nodus...
✓ Server started on port 7600
Admin: http://localhost:7600/admin_…
$ Install PN for the machine it runs on, for a home or office network, or for public sites. On one machine it answers only that machine, so terminal tools and background jobs can use it with no certificate at all. On a private network it serves over HTTPS with a certificate you provide, to the addresses you allow. On the open web it obtains and renews public certificates itself. Start small and move it out when you are ready.
pn update stages the new release, snapshots the old one, switches over and checks health. A failed check puts the release that was working back, without waiting for you. pn rollback does the same on request.
pn backup writes one sealed file, encrypted and signed, meant to leave the machine. pn restore puts it back on the same server or a fresh one, checks the whole file before writing anything, and signs every old session out so nothing from before the restore stays valid. Daily snapshots stay on the host for the quick cases. Database servers such as Postgres are backed up with their own tools, and their dumps can be sealed into the same file.
PN does not report how you or your apps use it: no analytics helper, no usage statistics, no crash reports. Once a day it checks for a newer release and tells you; it never installs anything on its own, and you can turn the check off. Export and erasure are capabilities every app inherits, so the people using what you build keep rights over their own data without you writing a line.
Hundreds of codes, each namespaced by where it comes from, each stable. See one in a log or an API response and run one command: it tells you what caused it, how to fix it, its category and HTTP status, and a hint. The same codes come back through the SDKs, so an app can handle them by name instead of parsing a message. There is pn errors find for when all you have is a phrase.
$ pn errors lookup SERVE_028
SERVE_028 serve • config
spa handler requires `root` — set `root` to the filesystem path of the SPA build output
severity: error http: 400 recoverable: no
CAUSE
A serve route was registered with `spa: true` but no `root` field. The SPA handler must serve files from a filesystem root.
REMEDIATION
Set `root` to the filesystem path of the SPA build output (e.g., `/var/www/app/dist`), in addition to `spa: true`.
HINT
The spa handler is a static-file server with single-page-app fallback rewriting; it requires a `root` to serve from. …
$ At the center is the core. It is the one thing you install, and its job is to keep apps apart while letting them share what you choose.
Around it sit spokes. Each provides one capability: sign-in, data, secrets, serving, APIs, the admin console. An app uses the spokes it needs, and every request between parts passes through the core, so a spoke never reaches another spoke directly and an app never reaches another app.
You install one package, run a command-line setup, then manage the rest from the admin console. Adding a capability is an install. Adding an app is a declaration.
Prime directive: Protect the system and its users’ data. Nothing outranks it.
Hammer is the overwatch. It runs as its own process beside PN, not inside it, so a failure in the system it guards cannot take the guard down with it. PN does not run without it.
It keeps its own sealed store, separate from PN's, that no app can reach. It keeps the record of what happened in a form where tampering shows. And it watches security signals, not your users: it does not know what they read, only when something in the system starts to behave like a threat.
When a component misbehaves, Hammer does not negotiate with it. It stops it, restarts PN clean, and reports. When PN itself goes wrong, Hammer can stop it.
The services you would otherwise stitch together, each with its own account, config and failure mode, become one install that you update, back up and watch as one thing.
Imaginary Grocery Company is a fictional grocery and logistics business built on PN as a complete reference stack: two groups on one install, with every declaration, model, view and seed file written out. It is the stack PN is proven against before release. At release it goes live here as a working demo with test logins you can try, and its source becomes a public repository you can read, run and borrow from. The apps are not full products; they are complete enough to show what a finished stack looks like.
This release already carries the shape of a real organisation, its internal tools and its public sites on one platform, and PN is being built to go further in that direction.
From a single box to an organisation with departments and a public face. The scale changes; the shape of the install does not.
A home lab, NAS or office server running several tools, on one machine or across your own network. One sign-in for all of them, each tool kept apart from the rest, encrypted connections with your own certificate, updates that roll themselves back, and a backup you can carry to the next box.
Internal tools for staff in one group, customer sites in another, more groups for other departments or brands as they come. Staff sign in once with a different role in each tool, customers have their own accounts, partners get API keys, and no group can reach into another. The example above is this shape.
Four commands from app to endpoint to key. The endpoint answers over REST, through the TypeScript or Python SDK, and as a tool AI assistants can call over MCP, with every error carrying a code the caller can act on.
The first release is the foundation. This is where it goes next, planned in the open and without dates.
Procurator Nodus is in active development and is not yet available to install. At release it will be free and open source under the Apache-2.0 license.
This is the project’s official home. The release, the documentation and the install steps will be published right here.