Frontend · Backend · JavaScript

Bun 1.2 Ships a Native S3 Client That Works Across Alibaba, Tencent, and Huawei Cloud

By 半刻纬度 · Jul 2, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Multi-cloud object storage has been a grind of incompatible SDKs, heavy dependencies, and slow cold starts. A native S3 client in the runtime collapses that complexity: one API, no node_modules bloat, and a 10x speedup that makes serverless and edge deployments far cheaper to run.

Summary

The S3 protocol has become the universal object-storage interface, and every major Chinese cloud vendor now offers 100% S3-compatible endpoints. Bun 1.2 is the first JavaScript runtime to embed an S3 client directly, eliminating the need for vendor-specific SDKs like ali-oss or cos-nodejs-sdk-v5. A single S3Client instance handles uploads, downloads, presigned URLs, and streaming across Alibaba, Tencent, and Huawei with only an endpoint change.

Performance benchmarks show Bun's Zig-based HTTP layer delivering roughly 10x the throughput of the Node.js aws-sdk v3, while cold-start overhead drops from 80 MB to zero. The client also supports direct fetch-to-storage streaming, meaning a network resource can be saved to a bucket without buffering it in memory first.

A factory pattern wrapping the three providers' configs lets teams switch clouds by flipping one string. Presigned upload URLs work identically across all three, enabling browser-to-cloud direct transfers that keep file traffic off application servers and cut CDN costs.

Takeaways

— Bun ≥ 1.2 includes a native S3Client that speaks the S3 protocol directly, with no npm install required.

— Alibaba OSS, Tencent COS, and Huawei OBS all expose fully S3-compatible endpoints; switching clouds means changing the endpoint URL.

— Tencent COS bucket names must include the account APPID suffix (e.g., my-bucket-1250000000), or requests return 404.

— Region formats differ across vendors: Alibaba uses oss-cn-hangzhou, Tencent uses ap-guangzhou, and Huawei uses cn-north-4.

— Bun.S3Client is roughly 10x faster than aws-sdk v3 in official benchmarks, reaching 3.2 GB/s for small-file reads.

— Cold-start memory drops from ~80 MB with aws-sdk to zero because the client is built into the Bun binary.

— write() accepts a fetch Response directly, streaming network resources to object storage without buffering in memory.

— Presigned URLs work uniformly across all three Chinese clouds using AWS Signature v4, enabling browser-to-cloud direct uploads.

— S3File extends Blob and supports .text(), .json(), .bytes(), and .stream() — identical to Bun.file().

— A factory function wrapping per-vendor config lets application code call getS3('aliyun') and remain agnostic to the underlying provider.

Conclusions

Baking an S3 client into the runtime is a strategic bet that S3 compatibility has won as the universal object-storage interface, making vendor-specific SDKs legacy cruft.

The 10x performance gap comes from bypassing Node's HTTP stack entirely; Bun's Zig-based client avoids V8 and libuv overhead that dominates cold-start and throughput in serverless environments.

Direct fetch-to-storage streaming eliminates a whole class of memory-pressure bugs that appear when proxying large files through Node.js servers.

Presigned URL support across Alibaba, Tencent, and Huawei with a single API call removes the last excuse for routing upload traffic through application servers, which is both expensive and slow.

Multi-cloud portability stops being a architectural tax when the runtime itself provides the abstraction; the factory pattern shown here is trivial because the hard work moved into the platform.

Concepts & terms

S3 protocol

An HTTP REST API for object storage defined by AWS, using PUT/GET/DELETE/LIST verbs plus AWS Signature v4 authentication. It has become the de facto standard that nearly every cloud object store now implements.

Presigned URL

A time-limited URL generated with a cryptographic signature that grants temporary access to upload or download a specific object, allowing browsers to interact with object storage directly without going through an application server.

AWS Signature v4

The signing process that authenticates S3 API requests by hashing request details with secret credentials. All S3-compatible services, including Chinese clouds, use this same signing scheme.

Path-style vs. virtual-host-style

Two URL formats for addressing S3 buckets. Virtual-host-style puts the bucket in the hostname (my-bucket.s3.amazonaws.com); path-style puts it in the URL path (s3.amazonaws.com/my-bucket). Chinese clouds default to path-style, but Bun handles the difference automatically.

APPID (Tencent Cloud)

A unique numeric identifier appended to Tencent COS bucket names (e.g., my-bucket-1250000000). Omitting it causes 404 errors because the full bucket name is required for request routing.

From the discussion

The lone comment challenges the article's implied architecture, arguing that externalizing configuration eliminates the need for a strategy pattern and that a hardcoded approach breaks when a new cloud provider appears.

— Externalizing configuration makes the strategy pattern unnecessary for multi-cloud S3 compatibility.

— Hardcoding provider-specific logic leaves the system fragile when an unsupported cloud provider is introduced.

Featured comments

JohnYan

By that logic, why not just externalize all the configs? Do you even need the strategy pattern? Tomorrow a new cloud comes along, and you're stuck, right?

See top comments, translated →

Source: juejin.cn ↗ Google Translate ↗ Backup ↗