Publish an application surface

Serve a product, portal, or content experience beside the backend that powers it.

Connect a hostname or path to stored content, add dynamic templates where needed, and use the same certificates and access context as the wider application.

See what it changes Technical guide ↗

Sites in a product

Choose the experienceFrontend, portal, documentation, or content site

Connect its contentServe a synchronized storage root

Give it a public homeRoute the hostname with TLS and optional access

Frontend and backend share one operating home

01Ship the whole experience togetherServe the frontend beside its data and actions.

02Use the storage you chooseConnect a local or cloud-backed site root.

03Keep public and private surfaces distinctAdd hostname routing, optional authentication, and TLS.

Why it matters

A customer experiences one product, even when teams operate the frontend and backend separately.

A portal needs static assets, dynamic routes, a hostname, TLS, access, caching, and the application APIs behind it. Splitting each concern into an unrelated service can make a small product surprisingly hard to operate.

Daptin sites map a host or path to content in a connected store. The runtime can serve synchronized files, route template-backed pages, apply optional authentication, and select configured certificates for the hostname.

The result is a cohesive application surface: the frontend, its records, its actions, and its operating context live close enough to understand together.

Give the product one front door

Route a hostname or path to the content customers should see.

Publish from owned storage

Serve a synchronized site root without handing product identity to a hosting provider.

Combine static and dynamic experiences

Place template-backed routes beside ordinary frontend files.

How it fits

Part of one connected backend.

Sites does more when it can reuse the records, people, access rules, and workflows already in your application.

Step 1Store

Put the site content in a connected local or cloud store.

Step 2Route

Associate a host and path with the intended root.

Step 3Protect

Apply optional authentication and matching TLS material.

Step 4Serve

Deliver cached, compressed, range-aware content as configured.

What it enables

Use it in products people recognize.

Start from the experience you want to create; the backend capability supports the work behind it.

Customer portal

Serve a branded frontend that calls the same Daptin backend.

Documentation hub

Publish maintained static content with controlled updates.

Private operations site

Require authentication before serving an internal application surface.

Connected by design

Build the next part without starting over.

These capabilities share the same application context, so each one makes sites more useful.

Know the boundary

What Daptin leaves in your hands.

Daptin sites are a self-hosted serving surface, not a global managed CDN. You own DNS, certificates, cache capacity, deployment strategy, synchronization, backups, security headers, and edge placement.

Understand the operating responsibility →

Build from one foundation

Make sites part of the product—not another disconnected service.

Run Daptin locally, explore the live administration surface, and follow one complete application path.

Get Daptin Explore all capabilities