/// CONCEPTS / DATA HANDLING

Data handling

Storafleet is a control plane for buckets you already own — not a copy of your data. Your file contents never come to rest on our servers. This page documents exactly how each kind of operation moves bytes, so you can answer a security review with specifics.

The short version: everyday actions are direct (your browser talks straight to your bucket via a presigned URL), and the only path that transits our servers is a cross-cloud migration, which streams in-flight and is never written to disk.

A control plane, not a store

When you connect a Fleet, storafleet stores your encrypted credentials and reads metadata — bucket and object listings, sizes, timestamps, and configuration — so search, dashboards, and the file browser are instant. It does not copy your objects into its own storage. Every operation below uses your credentials to act on your bucket; the object bytes stay in your cloud.

Direct transfers (presigned URLs)

Browsing, uploading, downloading, and sharing all use presigned URLs. storafleet signs a short-lived, scope-limited URL with your credentials and returns it to the browser; the browser then transfers the object directly to or from your bucket. The file bytes never pass through our servers.

Download — a presigned GetObject URL; the browser fetches straight from the bucket.
Upload — a presigned PutObject (or multipart) URL; the browser writes straight to the bucket.
Share & collect — a share link or file-request link is a presigned URL your recipient's browser uses to talk directly to your bucket. No public access is enabled, and we never proxy the file. See Presigned URLs.

Presigned URLs are time-limited and can be password-protected. The bucket is never made public — the URL is a signed, expiring grant to a single object.

Streaming transfers (migration & copy)

Moving objects between two different accounts or clouds can't be done with a presigned URL alone, so storafleet uses a streaming engine: it opens a read stream from the source (GetObject), pipes it through a backpressure-safe integrity check (SHA-256), and writes it to the destination as a multipart Upload. The bytes are in-flight only — they are streamed through and discarded as they flow. Nothing is buffered or written to our disks, which is also why there is no object-size or job-size cap.

Transfers are checkpointed and resumable, and run in the background — you watch them in the Transfers tab.
A few providers disable S3 server-side copy (for example Storj and Rabata); transfers to or from them always stream this way.

This is the one path where object bytes transit our infrastructure. They are never persisted — the stream is read and forwarded, not stored. We call this out plainly rather than claim “your data never touches us,” because for a cross-cloud migration that wouldn't be true.

Server-side copy

When the source and destination are in the same account on the same provider, storafleet issues the provider's native server-side copy (CopyObject). The data is copied entirely inside your provider and never leaves it — storafleet only sends the API instruction.

What storafleet persists

Only two things are ever written to storafleet's database:

Credentials — encrypted at rest with AES-256-GCM using a per-user derived key, decrypted only in memory to sign a request. IAM-Role Fleets store no long-lived key material at all. See Credential Security.
Metadata — bucket and object listings, sizes, timestamps, and configuration used to power search and dashboards.

Your file contents are never stored — not written to our disks, not retained after a transfer, not sent to any third party.

Disconnecting

Because your objects live in buckets you own, disconnecting a Fleet leaves your data exactly where it was — there is nothing to export and nothing left behind on our side beyond the metadata index, which is removed with the Fleet.

PreviousProvider capabilities

NextCredential Security