DaptinTeach 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.
One foundation, several ways to use it.
The pieces are valuable because they remember the same people, ownership, and product vocabulary.
Name the records and relationships that matter: customers, projects, bookings, documents, or anything else.
Make ownership and team membership part of the same model instead of copying rules into every service.
Give repeatable work a name, then use it from interfaces, schedules, provider connections, or mail.
Offer records, files, live updates, sites, feeds, or familiar protocols without creating separate realities.
How the foundation is arranged.
For technical evaluators, these layers show where shared identity, policy, data, services, and operating concerns meet.
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. Released deployments may use existing controls; the redesigned generic metering lifecycle in current source is not labelled as v0.12.36.
- 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. Live delivery uses PubSub and is not a durable event log.
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. Failure rolls back the transaction unless an individual outcome explicitly allows continuation.
Credentials stay permissioned.
Cloud storage and integrations link to encrypted credential records. Integration execution resolves the credential as the original request user; internal action execution does not silently lend administrator access to another user’s secret. 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. The site never calls PubSub itself a durable queue.
Lifecycle is a dependency order.
In v0.12.36, the runtime composes database, Olric, HTTP routes, caches, schedules, and optional protocol servers at startup. Current source after that release adds explicit readiness gating and an ordered shutdown path: quiesce and drain schedules, protocol listeners, accepted HTTP, WebSockets, LLM work, event workers, caches, PubSub, Olric, and the database. That lifecycle detail is evidence of direction, not a released claim.
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 | Live fanout, not durable replay |
| Stored mail, outbox, attempts, scheduled retry | Network ambiguity prevents an exactly-once promise; DNS/reputation are operator-owned | |
| 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 | No universal compatibility claim; DAV is deliberately scoped |