Cloud storage guide

Connect application files to the storage you operate.

Start with local storage, then introduce an rclone-supported provider. Keep the credential, store, and file field as three explicit layers you can test independently.

Credential
Cloud store
File field

Why storage stays replaceable →

Local first

Test the application path without provider setup.

{
  "name": "local-store",
  "store_type": "local",
  "store_provider": "localstore",
  "root_path": "/srv/daptin/storage"
}

A local store does not need a provider credential. Check that the Daptin process can read and write the directory and that it resides on durable storage in production.

Remote provider

Create and link all three layers.

Create a credential. Store the rclone-compatible provider fields in the credential content. Keep this operation administrator-only.
Create the cloud store. Give it a unique name, provider type, and provider-specific root path.
Name the credential on the store. Set the cloud store's credential_name to the exact name of the credential record used by the latest release.
Restart after configuration where required. Confirm the server loads the new store and creates its local synchronization path.
Attach a file field. Set ForeignKeyData.Namespace to the exact cloud-store name and KeyName to its folder or prefix.

Provider shape

Keep backend details out of product records.

Credential

Contains provider connection fields. It should be readable and changeable only by the server and intended administrators.

Cloud store

Names a usable storage root and identifies its credential when the provider requires one.

File field

Points at the store name and a logical prefix such as photos, documents, or mail.

Application record

Holds asset metadata and public delivery information without exposing provider keys to the browser.

Verification

Test the provider before attaching production data.

The credential content includes the provider's required rclone fields and type.
The cloud store's credential_name resolves to the intended server-held credential where authentication is required.
The bucket or directory exists and the server identity can access only the intended root.
An upload appears under the configured KeyName prefix.
A Daptin read returns the same file through the record's asset route.
Update and read permissions deny unintended users.
Restart and synchronization behavior is tested before relying on dynamic store changes.
Backup, retention, deletion, and provider outage behavior are defined by the deployment.

Use server-held credentials, but do not treat storage configuration alone as a guarantee of secret safety. Restrict credential-table access and apply the provider's own least-privilege policy.

Attach the store to a record field.

Return to Cloud storage →Configure file fields ↗