Home / Product / Cloud storage

Choose where content lives

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

Connect local or rclone-backed storage to records and sites, so changing where bytes live does not require changing what they mean.

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.

03Avoid remodelling the applicationRecords continue to own files even when storage placement changes.

Why it matters

Your storage provider should hold the bytes, not define your product.

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 without teaching clients a new object-store 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

Build the next part without starting over.

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

Know the boundary

What Daptin leaves in your hands.

Rclone supports many providers, but that is not a promise that every provider and option is tested. Verify compatibility, credentials, costs, consistency, limits, region, encryption, and recovery for your chosen store.

Understand the operating responsibility →

Build from one foundation

Make cloud storage 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