1. Model and protect data
Define records and relationships, then test owner, group, and guest access.
Data modeling →Permissions →
Sites and publishing
Host every static site your product needs.
Map hostnames and paths to content in local or cloud storage. Daptin synchronizes the files, serves them from a local cache, and can add TLS, Basic Auth, or FTP access without another site-hosting service.
- Multiple sites
- Cloud-backed
- Host + path routing
How the pieces connect
A site is the delivery edge of an application flow.
Daptin does not turn static hosting into a server-side template runtime. Build static files with your chosen frontend or site generator, store the output, then route a hostname and path to it. Dynamic behavior continues through Daptin APIs and actions.
Permissions →
2. Build the frontend
Compile templates or an SPA into static files. Call permission-aware APIs and actions for live data.
Application APIs →Backend actions →
3. Store the output
Place built files in a local or cloud-backed store and synchronize the directory.
Cloud storage →Site configuration →
4. Route and operate
Map host and path, add TLS or Basic Auth, verify caching, and monitor synchronization.
TLS certificates →Monitoring →
Know where authorization changes.
Requests from the frontend to Daptin APIs remain subject to the
data and action permission model. A publicly served static file is
public unless the site route has its own access protection; record
permissions do not automatically wrap every static asset.
What Daptin handles
Storage becomes a site, not an infrastructure project.
A site record connects a hostname and optional path to a directory in a configured cloud store. Incoming requests are routed to the matching site and served from a synchronized local cache, including directory index files.
Many sites from one server
Run a product frontend, documentation, customer portal, campaign pages, or separate tenant sites from distinct host and path mappings.
Storage stays replaceable
Back content with the local filesystem or an rclone-supported provider. The public route does not expose the provider to visitors.
Fast reads from a local cache
Daptin synchronizes remote content into an
AssetFolderCache instead of fetching every object
for every request.
Update without rebuilding Daptin
Change files in the backing store and run
site.storage.sync, or use scheduled
synchronization to refresh the local copy.
Where it earns its place
Keep public experiences beside the backend they use.
Single-page applications
Serve the compiled frontend while it calls Daptin data, identity, actions, files, and realtime interfaces.
Documentation and product sites
Publish generated static content from managed storage and update it through synchronization or FTP.
Protected internal sites
Add HTTP Basic Authentication to staging builds, internal references, or private static tools.
Several branded domains
Use host routing and SNI certificate selection to serve distinct domains from one Daptin process.
Already connected
Publishing uses the rest of the server.
Sites share Daptin's storage configuration, certificate management, scheduler, and optional FTP service. That means fewer independent services and fewer copies of credentials and routing configuration.
Managed HTTPS
Associate a matching certificate with the hostname; Daptin loads enabled-site certificates and selects them through SNI.
Optional FTP management
When FTP is enabled globally and for the site, authenticated users can manage its underlying storage path.
Explicit routing
Each site needs a valid cloud store and non-conflicting hostname and path. DNS must point public hosts at the deployment.
Static hosting by design
Daptin serves files and generated static output. APIs and actions handle dynamic behavior; this is not a general server-side code runtime.