Daptin: a self-hosted application server that turns schema files into APIs, identity and automation

The problem Daptin solves, and the engineer it is aimed at

Most backend work is repetition. You write a table, then a create endpoint, then a list endpoint with filtering and pagination, then permissions on that table, then a row-level rule, then an upload path for files attached to those rows, then a webhook that fires when a row changes. Daptin takes the position that all of this should follow from the data model instead of being written again per project.

The README states the premise directly: define resources once, and the server runs their APIs, identity, permissions, files, automation, integrations, realtime delivery and operational controls. The audience is therefore a team that owns its deployment target and is comfortable describing an application as schema plus configuration rows. A single developer prototyping an internal tool fits that description. So does a platform group that wants one runtime for several small applications rather than several bespoke services.

The mismatch appears when a team wants a hosted control plane or a vendor to answer for uptime. Daptin is software you run. The README points at Docker, a Linux binary and a Kustomize guide for Kubernetes, and nothing more.

How the resource runtime works: schema in, JSON:API out

The mechanism is described in the README's own words. Daptin loads schema files into its runtime configuration. Each configured table is recorded as `world` metadata and becomes a permission-aware JSON:API resource at `/api/{entity}`. Everything else attaches around that resource runtime.

The second half of the design is the part worth pausing on. Many capabilities are configured as ordinary data. Rows in tables such as `action`, `task`, `smd`, `cloud_store`, `site`, `integration`, `llm_provider` and `api_plan` tell the running server what to execute or expose. So a scheduled job is a row. An installed OpenAPI operation is a row. A storage backend is a row. This is a coherent choice: configuration becomes queryable, versionable and subject to the same permission gates as business data. It also means a mistake in a system table is a runtime change, not a compile error.

Permission checks happen before work is performed, at the level of the table, the individual row, the relation, or the action. The README lists the attached surfaces as JSON:API, optional GraphQL, WebSockets, feeds, files, OAuth/OIDC and LLM routes. Note the word optional for GraphQL: it is a surface you enable, not the primary interface. The primary interface is JSON:API, and the README links a separate aggregation API for queries that CRUD filtering cannot express.

Installing Daptin with Docker and creating the first administrator

The fastest path in the README is a single container. It pulls the latest image, publishes port 8080 inside the container to 6336 on the loopback interface, and removes the container when it exits.

docker run --pull=always --rm -p 127.0.0.1:6336:8080 daptin/daptin:latest

After that command, open http://localhost:6336. The README says to create the first administrator there and then continue with the Getting Started Guide in the wiki. Because the container is discarded on exit, this is an evaluation path, not a deployment.

For a durable local stack the repository ships a Compose file. Copy the example environment file first, then bring the stack up and wait for health checks to pass.

cp .env.example .env
docker compose up --wait

The Compose stack binds Daptin only to 127.0.0.1:6336 and keeps PostgreSQL inside its private network, with database and asset data in named volumes. Two details matter before you use it for anything real. The README says to change the development password in .env before using the stack beyond local evaluation, and .env.example ships POSTGRES_PASSWORD=replace-with-a-long-random-password, so the placeholder is visible and meant to be replaced. The Daptin service itself runs with read_only: true and a non-root user, and its health check probes /ready over a raw TCP connection.

If you prefer a binary, the README gives this sequence, which downloads the Linux amd64 build, marks it executable, and starts it on port 6336.

curl -L -o daptin https://github.com/daptin/daptin/releases/latest/download/daptin-linux-amd64
chmod +x daptin
./daptin -port=6336

Kubernetes users are pointed at the Kustomize deployment guide in kubernetes/README.md rather than at a Helm chart, which tells you something about the intended operational model.

Where Daptin is the wrong tool

The configuration-as-data model has a sharp edge. Actions, schedules, storage backends and integrations live in system tables. There is no compile step between editing those rows and the running server acting on them. The README does not document rollback, staging promotion, or a dry-run mode for system table changes. If your change management requires a reviewable diff before a scheduled task starts firing, you are adding that discipline yourself.

The wiki is the documentation surface, not the README. The README is a feature map with links. Anything beyond installation and the first administrator lives behind links such as Core Concepts, Permissions, Action Reference and Task Scheduling. A team that will not read those pages will misconfigure permissions, because the gate model spans table, row, relation and action, and the default and access groups are part of that model.

Breadth is also a maintenance liability for the operator. The go.mod file pulls in rclone for storage, Olric for pub/sub, go-guerrilla and go-imap for mail, fclairamb/ftpserver, emersion/go-webdav, goja for JavaScript execution, AWS SDK v1 and v2, and a Daptin LLM gateway module. Every one of those is a surface you may or may not enable, and each is another thing to keep patched. A team that wants only CRUD over Postgres is carrying a large dependency tree for a small job.

Finally, the README does not state supported database backends beyond the PostgreSQL example in Compose and the DAPTIN_DB_TYPE key it sets. If your organisation requires a specific engine, confirm support in the wiki before committing.

How Daptin differs from FastSchema and from hand-written Go services

FastSchema appears in the related searches as the comparison people reach for. Both projects start from a schema and generate API surface, so the difference is in what gets attached afterwards. FastSchema is a Go backend framework: you embed it in your own program, write Go where you need custom logic, and the framework gives you schema-driven CRUD, auth and file handling inside your binary. Daptin is the opposite arrangement. It is a server you run, and custom logic is expressed as action rows with ordered outcomes and Go performers rather than as code in your repository. If your team wants the backend to be a library inside an application you compile and ship, FastSchema matches that shape. If you want the backend to be an appliance you deploy and configure, Daptin matches that one.

The second alternative is the obvious one: write a Go service with a router, an ORM and a migration tool. That gives you total control and a small dependency tree, and it costs you the parts Daptin already implements, which the README enumerates at length: OAuth 2 and OIDC provider endpoints with JWKS, presigned file flows, CalDAV and CardDAV routes, RSS and Atom feeds, WebSocket CRUD events, and an action engine with conditions and conformations. The honest comparison is not capability against capability. It is whether you would rather own that code or own the configuration of someone else's.

Maintenance, release cadence and the LGPL-3.0 question

The repository is not archived, and the last push was on 2026-09-09. Three releases landed in the days before that: v0.13.5 and v0.13.6 on 2026-09-07, and v0.13.7 on 2026-09-09. That is a fast cadence on the 0.13 line, and it has a practical consequence for operators: the Compose file defaults to daptin/daptin:latest with pull_policy: always. If you run that stack as written, you are tracking master-equivalent images rather than a pinned version. Pin DAPTIN_IMAGE in .env to a specific tag if you want reproducible restarts.

The upgrade cost is not only the binary. Schema files and system table rows are part of your deployment state, and the README does not describe a migration mechanism for either. Back up before upgrading, and treat the database as the source of truth. The Compose stack stores database data in the postgres-data volume and Daptin's assets under DAPTIN_LOCAL_STORAGE_PATH with a cache at DAPTIN_CACHE_FOLDER, so a restore routine that only dumps Postgres is incomplete.

Licensing: the repository ships LICENSE and COPYING.LESSER, and the README badge and the Dockerfile label both identify LGPL v3 (the Dockerfile writes LGPL-3.0-only). The practical implication of LGPL for a server you run yourself is different from GPL, and different again if you modify the code and distribute the result. This is not legal advice. If you intend to modify Daptin and ship it inside a product, have your own counsel read the actual licence files rather than a badge.

Editorial conclusion

Adopt Daptin if your team already runs its own infrastructure and wants the backend defined as schema plus configuration rows rather than as application code, and if you are willing to read the wiki before touching production data. Do not adopt it if you need a managed control plane, a vendor SLA, or a system whose every behaviour is documented in the README alone. Verify three things first: that the release you pin behaves the same as the running master, that your backup and restore routine covers both the database and the storage and cache paths named in docker-compose.yml, and that the LGPL-3.0 obligations are acceptable to whoever ships your product.

Frequently asked questions

Official sources

1. daptin/daptin on GitHub
2. License: LGPL-3.0
3. Project website
4. README
5. Releases