daup is how organisations and people run their own apps on their own infrastructure. Every node is sovereign by default — its data stays on it and is never persisted elsewhere. The apps are thin clients; the data never leaves home.
No shared central database · no node-to-node sync · the signing secret never leaves your node
daup has one kind of node, and every node's data lives on that node. There are no tiers to classify and no central store to trust — sovereignty isn't a premium option, it's the only mode. The apps you see below are static front-ends served from a CDN: they hold nothing at rest. The only component that holds data is the node you control.
Social apps for people, SME apps for small businesses, enterprise apps for organisations — plus the apps you reach from inside another app. Every one of them reads and writes against your sovereign node.
Order and eat at home.
Dining and takeaway, out and about.
Messaging between people and places.
Reach a person or a service directly.
Run a restaurant or food place.
Sell and resell to your customers.
Make and sell what you produce.
Farm produce from gate to buyer.
Services, jobs and bookings.
The single source of truth for every data product, clear through its whole lifecycle. Live.
Plan and track work across an app.
Money, invoicing and settlement.
Secure store for keys and credentials.
These four properties hold on every node — whether an organisation runs daup on-premise or a person runs a hosted node.
It runs on your own infrastructure with its own database and its own signing secret. It boots and serves with every other node offline — not a client of, and not dependent on, any external node.
Nodes don't talk to each other. There's no sync protocol and no server-to-server trust. The only thing two nodes share is the public CDN app bundle — static files, no data path. Any future cross-node capability is opt-in and returns through review first.
Your data is written only to your node's database and never persisted to any external node. Members-only apps are refused on the wrong node by policy, so data can't be created in the wrong place.
A node admits only an operator-maintained roster; an identity not on it is refused entry — fail-closed, not “let in with low privilege.” Access is governed by the node you control, not an external service.