Home / Product / How it worksA shared product context

Teach the backend your product once.

When Daptin knows what a customer, project, file, permission, and action mean to each other, new experiences can reuse that understanding. The product stays coherent even as it gains more ways to store, automate, connect, and communicate.

See the idea in plain language Inspect the technical path

The simple version

One foundation, several ways to use it.

The pieces are valuable because they remember the same people, ownership, and product vocabulary.

KnowDescribe the product.

Name the records and relationships that matter: customers, projects, bookings, documents, or anything else.

ProtectAttach people and access.

Define ownership and team membership once in the relational model and apply them across records, files, actions, and APIs.

ActAdd product behavior.

Give repeatable work a name, then use it from interfaces, schedules, provider connections, or mail.

ReachChoose delivery surfaces.

Serve the same records and files through APIs, live events, sites, feeds, and supported protocols.

Under the hood

How the foundation is arranged.

For technical evaluators, these layers show where shared identity, policy, data, services, and operating concerns meet.

DefinitionSchema, built-in records, configuration, database and storage choicesProduces normalized resources, relationships, defaults, actions, schedules, and service records

Shared contextPublic record identity, user and groups, ownership, table/row/relation/action policySupplies the identity and access vocabulary used by resource and action paths

Core pathsJSON:API resources, GraphQL, aggregation, action execution, assetsRead and change the same relational records inside explicit transactions

Attached servicesStorage/sites, events/WebSockets, Yjs, integrations, templates, feeds, mail, FTP and DAV-style accessReuse the same records, credentials, certificates, permissions, and lifecycle rules across every delivery surface.

RuntimeDatabase pools, Olric cache/PubSub, limits, statistics, logs, listeners, background workRun startup, readiness, live coordination, outcome handling, and resource bounds through the Daptin runtime.

See the whole product stay available

Connect saved information, customer delivery, shared traffic, and team visibility.

This view shows how Daptin keeps business information safe, answers customer requests, stays consistent as traffic grows, and gives the team clear checks, history, and restorable backups.

Diagram showing saved business information connected to customer requests, scheduled routines, active Daptin services, team checks, activity history, and restorable backups. — **Keep the product available as customer traffic grows**Bring customer requests, scheduled routines, immediate updates, secure connections, active Daptin services, availability checks, history, and backups into one product view.Open diagram for full-size view

From caller to committed change.

Establish the caller.
Authentication resolves a guest or account session and the account’s group relationships.
Check the resource boundary.
Table access is evaluated before object access. Reads are filtered; writes must satisfy the relevant owner, guest, or group permission.
Validate and meter where configured.
Model validation and transformations run in the resource path. Validation, transformations, admission controls, usage reservations, and completion records run in the resource path.
Write inside the database boundary.
CRUD methods use a transaction. Stable reference identity and standard lifecycle fields follow each resource.
Continue from a successful change.
Configured exchange work and create/update/delete events run in the shared middleware path. Use PubSub for live event fanout and a durable store or broker for retained replay.

An action follows the same application context.

A named action is resolved on an entity. Daptin checks the action’s permission and, for an instance action, the subject record’s execute permission. Inputs are validated and transformed. Ordered outcomes can work with records, templates, integrations, files, responses, or registered backend performers. Keep protected record changes pending until every required outcome completes, then commit the transaction.

Run scheduled actions with an explicit account and the same permission checks as interactive requests. A persisted task loads its selected account and group context, then calls the same action handler.

Credentials stay permissioned.

Cloud storage and integrations link to encrypted credential records. Resolve integration credentials for the original request user and keep each user’s secrets within that authorization context. OAuth tokens provide a parallel delegated path for provider calls.

Certificates connect service surfaces.

Certificate records and their manager supply hostname TLS material to HTTPS and configured sites, and to applicable SMTP, IMAP, and FTP paths. ACME challenge and self-signed generation are explicit actions. Renewal, DNS, trust chains, and service configuration remain visible operator work.

Live and durable state stay distinct.

Olric PubSub carries live record and topic events across configured nodes. Yjs stores collaborative room state. Audit/state tables and application records provide durable history when enabled. Describe PubSub as live fanout and direct durable delivery requirements to stored work or a message broker.

Lifecycle is a dependency order.

The runtime starts dependencies in order, gates readiness, and drains active work before shutdown. It composes the database, Olric, HTTP routes, caches, schedules, and protocol servers, then drains schedules, listeners, accepted HTTP, WebSockets, AI work, event workers, caches, PubSub, Olric, and the database.

Guarantees and boundaries

Area	Daptin mechanism	Boundary
Data integrity	Relational constraints, validation, transactions, reference identity	Schema quality and migrations remain application responsibilities
Access	Shared table, row, relation and action checks	Protocol adapters have specific documented scope; defaults must be reviewed
Realtime	Olric PubSub and permission-aware WebSockets	Use PubSub for live fanout and a durable store for replay.
Mail	Stored mail, outbox, attempts, scheduled retry	Record delivery attempts and design idempotent messages while operators manage DNS and sender reputation.
Cluster	Peer discovery, shared cache/PubSub/counters	Database/storage and network topology still determine availability
Protocols	SMTP/IMAP, FTP/FTPS, feeds, basic DAV-style paths	Document the supported DAV operations and test every required client workflow against that scope.