Prototype locally
Develop with a straightforward local store before adding external infrastructure.
Daptin
Run Daptin →
Cloud storage
Start on local disk. Move to S3-compatible or another rclone-backed provider when the product needs it. Keep the application-facing model unchanged.
Storage without lock-in
Configure storage sites in Daptin and use them for assets, managed files, and published content. Provider credentials remain on the server rather than moving into browser code.
Develop with a straightforward local store before adding external infrastructure.
rclone support opens a broad set of object-storage and file-service destinations.
Application records refer to managed assets rather than hard-coding one provider throughout the frontend.
The same storage layer can hold published site content and templates.
One storage layer, several uses
Point individual file fields at named prefixes so product records remain independent from provider URLs and bucket layout.
Map a directory in a cloud store to a hostname or path and synchronize it into Daptin's local serving cache.
Keep raw messages in configured storage while mailbox and delivery metadata remain queryable in SQL tables.
Keep the application-facing field tied to a logical store name while infrastructure choices evolve behind it.
Configuration
A provider credential supplies connection fields. A cloud-store
record names the provider root. A file field selects the store and
prefix. In the latest release, the store's
credential_name must exactly match the server-held
credential record.
Daptin keeps credentials server-side, but administrators must still restrict credential-table access and apply least privilege at the provider. Backups, retention, deletion, cost, regional placement, and provider outages remain operational responsibilities.
Configure the three storage layers →