Home / Product / Cloud storage

Choose where content lives

Keep product ownership in Daptin while files live where you choose.

Your team validates credentials, consistency, regions, encryption, recovery, costs, and provider quotas.

See what it changes Technical guide ↗

Cloud storage in a product

Choose the storage accountLocal path or compatible cloud provider

Connect it securelyUse a protected credential

Attach it to the productFile fields and sites keep the same context

Storage placement is separate from product meaning

01Use infrastructure that fitsChoose local storage or a compatible provider for the workload.

02Keep provider secrets behind the backendConnect through permissioned credentials.

03Keep the same file records, ownership, and permissions when switching storage providers.Records continue to own files even when storage placement changes.

Why it matters

Keep product identity, ownership, and permissions in Daptin while the selected provider stores the bytes.

A product may begin with local files, move to object storage, or use different providers for different content. If application records depend directly on provider URLs and credentials, every storage decision leaks into the customer experience.

Daptin connects a cloud store to protected credentials and lets asset fields or hosted sites use that store. Records keep the stable application context while the configured backend handles physical content.

This creates a practical separation: product code works with customers, articles, or documents; operators choose where those bytes belong.

Match storage to the deployment

Use local paths for fitting installations or rclone-backed providers such as S3-compatible storage where supported.

Keep access layered

Separate the customer's record permission from the operator's provider credential.

Retain a migration boundary

Move or synchronize content through Daptin file records while clients keep the same API contract.

How it fits

Part of one connected backend.

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

Step 1Choose

Select the local or cloud storage destination.

Step 2Authorize

Store the provider credential behind backend permissions.

Step 3Attach

Connect the store to file fields or a site.

Step 4Operate

Synchronize, cache, back up, and monitor the complete path.

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 uploads

Place account-owned documents in object storage.

Media catalogue

Keep product images in a scalable provider while records remain relational.

Hosted frontend

Serve a static site from a connected storage root.

Connected by design

Keep record identity, ownership, and permissions stable when bytes move between storage providers.

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

Know the boundary

What Daptin leaves in your hands.

Validate the exact rclone provider, operations, credentials, consistency, and options used by your deployment. Verify compatibility, credentials, costs, consistency, limits, region, encryption, and recovery for your chosen store.

Understand the operating responsibility →

Build from one foundation

Move file bytes between local and cloud storage while record identity and access stay consistent.

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

Get Daptin Explore all capabilities