Every Nibor app is a NAS document: models, access rules, screens, server functions and jobs. The compiler turns it into Postgres tables, row-level security, a REST and MCP API and the interface, on our cloud or on your servers. This page is the technical overview for IT, security and developers.
Every app is a single document in NAS, the Nibor App Spec. The AI writes NAS; our compiler turns it into a real Postgres schema, row-level security policies, a REST API, running server logic and a rendered interface. Nothing is a mock. Every app is a typed application graph, models, views, functions and roles with explicit, validated references.
"A booking system for our storage facilities, with BankID and credit checks."
AI writes the app spec (models, permissions, pages, automations), validated against our schema.
Tables, RLS policies, tenant isolation, API and UI are generated. Security is compiled, not configured.
Published at its own subdomain, TLS included. Edit by chatting; it redeploys in seconds.
// NAS, the Nibor App Spec (excerpt)
{
"app": { "name": "Storage Bookings" },
"models": [
{ "name": "Booking",
"fields": [ { "name": "unitId", "type": "ref" }, ... ],
"access": { "read": "authenticated", "write": "staff" } }
],
"views": [ { "route": "/book", "layout": "wizard", ... } ],
"appAuth": { "enabled": true, "roles": ["admin", "customer"] }
}
NAS describes one app. ONAS describes the organisation: which systems hold what, how work moves between people, who may do what. Apps and agents read the same graph.
Connect reads and writes across the systems you already run, through governed MCP tools.
Every tool call carries the caller's role; an agent gets exactly the access a person with that role has.
The graph is the source for the notifications and the company map your teams see in Nibor OS.
Every app exposes a governed MCP endpoint, your data, your access rules, your AI key. Agents work through your tools, in a place they cannot break. Claude, OpenAI or Cursor.
{
"mcpServers": {
"nibor": {
"url": "https://nibor.io/_mcp",
"headers": {
"X-API-Key": "plat_your_key_here"
}
}
}
}
Most business software gets harder to change every year. Each new requirement is layered onto code nobody fully understands, so the safe move is always to add rather than alter, and the system accumulates. Nibor works the other way round: the app is regenerated from its NAS document, so there is no accreted layer to build on top of.
Models, permissions, pages and automations live in a single document. The schema, the security policies, the API and the interface are all derived from it, they cannot drift from the spec, because they are produced by it.
Row-level security, tenant isolation and PII handling are emitted for every model from the access rules in the spec. Nothing depends on remembering to tick the right box on the right table.
Our own language, our own compiler, our own infrastructure. There is no third-party app-builder underneath that can deprecate an API, change its pricing, or break your software on its own schedule.
Five years of changes, each one made by someone who has left. Changing the old parts is risky, so nobody does. The cost of every new feature rises with the age of the system.
You change the spec and the app is rebuilt from it. A five-year-old app compiles the same way a new one does, because the compiler (not the accumulated code) decides what gets built.
No third-party app-builder underneath, no per-seat SaaS dependencies. The whole platform runs on a single Kubernetes node, which is exactly what makes it deployable inside a customer's own walls.
Row-level security and tenant isolation are generated from the spec for every model: per-app membership floors, per-operation policies, PII guards.
Kubernetes, Postgres, auth, data API, object storage, ingress with automatic TLS. Self-contained and reproducible.
The same containers deploy in a customer's cloud or data centre. Regulated organisations keep their data, with licensing control.
Claude today; the NAS layer isolates the model. Bring your own AI key, including EU-hosted providers.
Nibor's AI writes one compact spec (the NAS document), not thousands of lines of app code. Generating (and re-generating) an app costs a fraction of the API spend that code-writing tools burn. Bring your own key; you see every cent.
| Approach | Live in | Security review | Year three |
|---|---|---|---|
| AI code builders | Days | Fails on data residency | Code nobody wrote |
| Generic no-code | Weeks | Vendor-hosted only | Locked to their roadmap |
| Consultant build | Six to twelve months | Passes, at six figures | Change requests at day rate |
| Off-the-shelf SaaS | Instant | Passes | Still does not fit |
| Nibor | Minutes to days | Passes: compiled row-level security, your cloud or ours | Regenerated from the spec, no legacy |
One schema per app, generated from the spec. Your data, in a database you can export tonight.
Access rules in the spec become policies in the database. The API cannot bypass them.
PostgREST for screens and integrations, an MCP endpoint for agents, both under the same policies.
Server functions and scheduled jobs run sandboxed per app, with brokered access to vendors and keys that never reach the sandbox.
The same manifests run our cloud and your data centre. Nothing in an app depends on where it runs.
Documentation for the spec, the API and MCP. The AI-readiness audit for the systems you run today. The pilot programme for a first process.