Connect storage

DataPrism never stores your file contents. Files are encrypted in your application, split into shards, and written to buckets that belong to you. The platform only keeps the encrypted index that says where everything is.

Supported providers

The signer URL belongs to a small service in your infrastructure. It authenticates your application and returns a short-lived URL for one storage operation and one hash-named object. Your permanent cloud credentials never leave that service.

Recommended bucket setup

• Create a dedicated bucket per project. Shards are content-addressed, so the bucket contains opaque objects named by hash; keeping it dedicated makes cleanup and migration simple.
• Give the signing service an identity scoped to that bucket only, with the minimum read, write, head, and delete permissions it needs.
• No public access is ever needed. Keep the bucket private.
• Authenticate every signer request, validate the object key and operation, and keep signed URLs short-lived.

Enter only the bucket metadata and HTTPS signer URL in the project form, or later from the project's Providers tab. Supply the signer's short-lived authentication token to the SDK at runtime; do not save it in the project.

One provider or several?

The properties you get depend on how many providers you configure, so it is worth deciding early.

One bucket gives you client-side encryption and an anchored index: your provider stores objects it cannot read, and integrity is checkable by anyone. It gives you no dispersal, since that provider holds every shard of every chunk.

Three providers is where dispersal begins to mean something: no single provider holds enough shards to reconstruct a chunk, and a file survives losing one of them.

Five providers with dataShards: 7, parityShards: 3 is the configuration we recommend. Each provider holds two shards out of the seven needed, a file survives losing one provider with a shard to spare, and three providers acting together still cannot reconstruct anything. It costs 1.43 times the raw size.

You can add a provider later; new uploads take it into account. Existing files keep the dispersal they were written with.

Where files show up

The project's Storage tab is read-only. It lists recorded file indexes with their metadata: name, size, and upload date. Content never transits through the dashboard, and the dashboard does not mutate files. Upload and download run in your own application through the SDK. SDK deletion removes the encrypted file index; reclaiming content-addressed shards is a separate customer-controlled cleanup step that must first account for objects shared through deduplication. The Node.js example shows the complete flow.

Next step: invite your team.