// the find
haydenbleasel/files-sdk
A unified storage SDK for object and blob backends. One small, honest API. Web-standards I/O.
files-sdk wraps ~40 different storage backends (S3, GCS, Azure, R2, Vercel Blob, local filesystem, FTP, Dropbox, and more) behind a single eight-method API using Web-standard types. It is aimed at TypeScript developers who need to swap providers without rewriting file-handling code, or who are building AI agents that need storage tool calls. The plugin system (encryption, versioning, soft-delete, tiering, failover, etc.) is more complete than you would expect from a project this young.
The escape hatch via `files.raw` is the right call — it avoids the trap every abstraction library falls into where you get 80% coverage and then are stuck. Using `Blob`/`ReadableStream`/`Uint8Array` as the I/O types means no provider-specific types leak into application code, which is genuinely useful. The adapter-per-entry-point structure is tree-shakeable by design — you pay only for what you import. The AI tool wrappers (Claude, OpenAI Agents, Vercel AI SDK) with approval-gating defaults show someone thought about the agentic use case seriously rather than bolting it on.
1,240 stars with 37 forks and no visible test directory in the tree is a yellow flag — it is unclear how the adapter surface area is tested at this scale. The plugin system (compression, encryption, versioning, tiering, failover, dedup) is ambitious and each plugin is a separate concern that compounds with others; the interaction matrix is not small and there are already changeset entries for edge cases like `resumable-abort-begin-race` and `bulk-signal-timeout`, which suggests the happy path is solid but the corners are still being found. The project is a monorepo with Bun as the runtime, which adds friction for teams that are not already on Bun. There is no mention of streaming large files through transformations (encryption + compression in series) which is exactly where abstraction layers tend to break.