STORAGE ARCHITECTURE PUBLISHED: JUNE 18, 2026 READ: 7 MIN

Unlimited File Transfer: The BYOS Architecture That Removes Every Size Limit

The 200 GB Problem

Every consumer and prosumer file sharing service you have ever used imposes a file size limit, and the reason is not technical — it is economic. When Dropbox, WeTransfer, or Google Drive stores your file, they are paying for that storage on hardware they own and operate in data centers they lease. Storage costs money. Bandwidth costs money. As file sizes grow from megabytes to gigabytes to terabytes, those costs scale linearly, and the business model that worked for a 100 MB presentation slides begins to buckle under a 100 GB video export. The result is a patchwork of limits designed to keep average storage cost per user manageable: WeTransfer caps free transfers at 2 GB and paid tiers at 200 GB. Dropbox's largest business plan allows files up to 10 TB in theory, but only because they are betting most users never actually hit that ceiling.

For teams operating at the frontier of data-heavy workflows, these limits are not inconveniences — they are blockers. A machine learning research team shipping Llama 3 70B model weights between a training cluster and a production inference server is dealing with 40+ GB artifacts. A post-production studio receiving RAW 8K footage from a field crew shoots 100–800 GB per project day. A genomics company performing whole-genome sequencing produces FASTQ files in the 50–200 GB range per patient sample. A satellite imagery platform distributing geospatial tiles to analysis agents may handle 1 TB+ per dataset. For these teams, "just use Google Drive" is the same as saying "just don't share the file."

The fundamental architectural reason consumer file sharing services hit walls at large sizes is that they act as the storage layer. They own the files between upload and download. This is convenient for the user experience — no configuration required, just drag and drop — but it creates an irreconcilable conflict between their cost structure and your file size. ShareBolt's approach flips the ownership model entirely. ShareBolt is not a storage service. It is a cryptographic coordination service — and that distinction is what makes unlimited file transfer possible.

What Is Bring Your Own Storage (BYOS)?

Bring Your Own Storage means exactly what it says: you bring your own cloud storage bucket, and ShareBolt encrypts your file and writes the encrypted data directly there. Currently, ShareBolt BYOS supports Cloudflare R2; support for AWS S3, Azure Blob Storage, Google Cloud Storage, and MinIO is planned. ShareBolt generates an AES-256-GCM encryption key locally on your device, encrypts the file before it leaves your machine, and uploads the encrypted data directly to your bucket using your storage credentials. ShareBolt's servers handle only the encrypted key envelope — the tiny piece of data (a few hundred bytes) needed to let the recipient unwrap the decryption key.

The key insight: ShareBolt is purely a cryptographic coordination layer — we never store your files. Your encrypted data lives in storage you control, managed under your cloud provider account, subject to your retention policies, and billed at your storage tier's rates. Even if ShareBolt's entire infrastructure were offline, your encrypted data would still be in your bucket, waiting for you to decrypt it locally.

This architecture removes two constraints simultaneously. First, it dramatically increases the size ceiling: Pro Vault supports up to 25 GB per file with BYOS; Enterprise Citadel supports unlimited file sizes with BYOS. Second, it removes the custody problem: your data never resides on ShareBolt's infrastructure, which means ShareBolt cannot be compelled to produce your files in a legal discovery request, cannot be breached in a way that exposes your file contents, and cannot go bankrupt and delete your data. You are always in possession of your own encrypted data.

BYOS Architecture: The Complete Data Flow

Here is exactly what happens when you initiate a large file transfer with BYOS enabled — every step, in order:

Client Device (Sender) ├─ [1] Generate AES-256-GCM key locally (never leaves device in plaintext) ├─ [2] Encrypt file chunk-by-chunk in memory (64 MB chunks by default) ├─ [3] Upload encrypted chunks → YOUR S3 / R2 / GCS bucket └─ [4] Wrap DEK with recipient's X25519 public key → send envelope ShareBolt Relay Server └─ [5] Receive encrypted key envelope → relay to recipient DID (Server sees: opaque encrypted bytes, sender DID, recipient DID) (Server does NOT see: file contents, file name, DEK) Client Device (Recipient) ├─ [6] Receive encrypted key envelope → unwrap with own X25519 private key ├─ [7] Pull encrypted chunks from S3 (using pre-signed download URLs) └─ [8] Decrypt chunks locally → reassemble file on disk

The encryption design processes the file before it leaves your device. Each chunk is encrypted independently with the same AES-GCM key but a unique nonce, then uploaded to your storage backend. (Note: single-part uploads are currently supported. Chunked resumable uploads are on the roadmap.) Pro Vault supports up to 25 GB per file with BYOS; Enterprise Citadel supports unlimited file sizes with BYOS.

Supported Storage Backends

BYOS is available on Pro Vault and Enterprise plans. Currently Cloudflare R2 is the supported BYOS backend. S3, Azure Blob, GCS, and MinIO support are planned for future releases.

Provider Min Plan Max File Size Status
Cloudflare R2 Pro Vault Up to 25 GB (Pro) / Unlimited (Enterprise) ✅ Live
AWS S3 Pro Vault Planned 🔜 Roadmap
Google Cloud Storage Pro Vault Planned 🔜 Roadmap
Azure Blob Storage Enterprise Planned 🔜 Roadmap
MinIO (self-hosted) Enterprise Planned 🔜 Roadmap
ShareBolt Managed Standard Shield 2 GB ✅ Live

Cloudflare R2 is the currently supported BYOS backend. R2 charges zero egress fees when files are downloaded through Cloudflare's network, which is the path ShareBolt uses for pre-signed download URLs. For large file transfer workloads that involve frequent downloads — like a CI/CD pipeline pulling model artifacts on every training run — this can result in significant cost savings. AWS S3, Azure Blob, GCS, and MinIO (for on-premises air-gapped deployments) are planned as future BYOS backends.

Real-World Large File Transfer Scenarios

The following are representative workloads from teams currently using ShareBolt BYOS in production:

Setting Up BYOS in 5 Minutes

Connecting your AWS S3 bucket to ShareBolt requires only a minimal IAM policy and a 5-minute configuration in your dashboard:

Use this minimal IAM policy — ShareBolt requires only the three S3 actions needed to write, serve, and clean up encrypted file chunks:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::my-sharebolt-transfers/*"
    }
  ]
}

Do not grant s3:* or s3:ListBucket to the ShareBolt IAM user. Least-privilege is especially important here because the IAM credentials are stored locally in the ShareBolt client and never sent to ShareBolt's servers — but scoping permissions tightly limits the blast radius if the local device is ever compromised.

Security: Your Data, Your Keys, Your Bucket

BYOS does not just solve the size limit problem — it delivers a fundamentally stronger security posture than centrally-stored file transfer services. The threat model is different in every dimension:

Encrypted Before Upload
ShareBolt encrypts with AES-256-GCM before the first byte leaves your device. Your S3 bucket receives opaque ciphertext — not a file, not readable data.
Credentials Never Leave
Your AWS IAM access key is stored in the ShareBolt local client keychain, encrypted at rest. It is never transmitted to ShareBolt's relay servers under any circumstances.
ShareBolt Cannot Read Your Files
ShareBolt's relay handles only the encrypted key envelope. Without the recipient's private key, even ShareBolt's own engineers cannot decrypt your file data.
S3 Breach Is Not a Data Breach
If your S3 bucket were somehow exposed, all an attacker would find is AES-256-GCM ciphertext with no associated decryption key. Without the ShareBolt key envelope, the data is computationally indecipherable.
Audit Ledger for Every Transfer
Every BYOS transfer produces a hash-chained ledger entry including sender, recipient, file hash, file size, and timestamp. Exportable to your SIEM for compliance evidence.
Your Retention Policy Applies
Because data lives in your bucket, your S3 lifecycle rules govern retention — not ShareBolt's. Set encrypted chunks to delete automatically after 30 days, or archive to Glacier. You are in control.

This security model means that for teams operating under HIPAA, GDPR, FedRAMP, or ISO 27001, BYOS is often the only architecturally acceptable option. When auditors ask "where does our data live?", the answer is simple: in your own cloud account, encrypted with keys that only your authorized users hold, never touching a third-party's storage layer. ShareBolt is not a data processor for your files under GDPR — it is a communications relay for cryptographic envelopes. That distinction can meaningfully simplify your compliance posture.

Remove Your File Size Ceiling Today

Start with BYOS on Pro Vault or explore Enterprise options for teams with advanced compliance requirements.

RELATED READING
→ ShareBolt Pricing — Unlock Unlimited File Sizes with Pro → How ShareBolt Works: Any File, Any Size, Any Device → Enterprise File Sharing with No Size Limits