File Storage
Upload, store, and serve user-generated files — documents, images, and media.
Options
Storage Backend*
File Processing
Decision Points
Will the app run on more than one server?
If yes
Object storage is required — local disk breaks horizontal scaling.
If no
Local disk works for prototypes; switch to S3-compatible before scaling.
Do users upload files directly via presigned URLs?
If yes
Issue short-lived (5–15 min) presigned PUT URLs so uploads skip your server — cheaper, faster, and sidesteps body-size limits.
If no
Proxying uploads through your API is simpler but caps throughput at your server bandwidth — fine for small files only.
Do you need chunked/multipart uploads for large files?
If yes
Use S3 multipart upload for anything over ~100MB — single-PUT uploads fail expensively on flaky networks.
If no
For small files (photos, documents under 10MB), a single PUT is simpler and sufficient.
Resumable uploads required?
If yes
Use tus.io protocol or S3 multipart with client-side state so users can resume after network drops — critical for mobile video uploads.
If no
Small-file workflows can safely require restart-on-failure.
Auto image/video transcoding or thumbnail generation?
If yes
Pipe uploads to a transcoding service (Cloudinary, Mux, Lambda@Edge with sharp/ffmpeg) — async, never block upload completion.
If no
Skip transcoding for document-heavy workflows where files are not consumed as media.
Access model: files public, private, or signed-URL access?
If yes
Private by default with short-lived signed URLs issued per authenticated request — safest for user-generated content.
If no
Fully public buckets are fine for static assets (logos, public images); never for user data.
Do you need client-side encryption at rest?
If yes
Encrypt on the client before upload with customer-managed keys — required for strict compliance (healthcare, legal).
If no
Server-side encryption (SSE-S3, SSE-KMS) is enough for most workloads and is transparent to clients.
Store file metadata in DB or only in object storage?
If yes
Keep a files table in your DB with upload metadata, owner, status, and a content hash — drives permissions and search.
If no
Object storage alone is sufficient only for truly anonymous, throwaway uploads.
Do you need cold-storage tiering for old files?
If yes
Use S3 Intelligent-Tiering or lifecycle rules to move files untouched for 30/90 days to Glacier — dramatic cost savings on archival data.
If no
Skip tiering for small storage footprints or hot-access workloads where retrieval latency matters.
Track storage usage per user/tenant for quotas/billing?
If yes
Aggregate usage in a separate table, updated on upload/delete events — do not scan object storage for totals in real time.
If no
Skip metering for internal tools or flat-rate products without storage-based billing.
CDN fronting for downloads?
If yes
Put Cloudflare or CloudFront in front of downloads — cuts global latency 5–10x and offloads bandwidth cost. Use signed CDN URLs for private content.
If no
Direct object-storage serving is fine when users are regional and file access is infrequent.
Deduplicate identical uploads (content-addressed)?
If yes
Hash files on upload and store by content hash — saves storage on duplicate assets but complicates deletion (reference counting).
If no
Skip dedup for user-facing products where each upload is semantically distinct regardless of bytes.
Strip EXIF/metadata from uploaded images for privacy?
If yes
Strip GPS and camera metadata on upload — critical for public-facing photos where location leakage is a real privacy risk.
If no
Keep EXIF for creative-workflow tools (photography, mapping) where metadata is a feature, not a leak.
Retain prior versions of files (file versioning)?
If yes
Enable S3 object versioning and track versions in your files table — required for collaborative document editing and compliance workflows.
If no
Overwrite-in-place is simpler and sufficient for user-managed assets where history is not valuable.
Soft-delete with trash/recycle bin?
If yes
Mark files deleted in DB but retain objects for 30 days — dramatically reduces "help, I lost my file" support tickets.
If no
Hard delete is appropriate for compliance-driven retention where files must be gone when requested.
Tradeoffs
Not horizontally scalable; lost on server replacement without backup
Higher monthly cost; requires cache invalidation strategy
Upload latency increases; requires AV service integration