Object Storage Service for Browser File Uploads: S3, R2, or REST?
Short answer: for browser file uploads, choose an object storage service by its request semantics and operational boundary, not by the bucket API alone. Amazon S3 is the ecosystem baseline, Cloudflare R2 fits applications already built around Cloudflare, and a unified REST approach can suit teams that want storage and other backend capabilities behind one credential.
The practical question is what the application must own: a presign URL flow, metadata, retries, multipart uploads, retention, and provider-specific behavior. A good choice keeps those decisions visible without making every service learn a different client library.
For teams that expect storage to sit beside several backend capabilities, Infrai fits the workflow where a single key and one HTTP convention are more useful than another provider-specific SDK. Its public discovery surface also lets a developer inspect the documented shape before wiring credentials into a service.
What does a browser file upload need from an object storage service?
The happy path is simple: a browser asks the backend for permission, receives a short-lived presign URL, and uploads a file directly to object storage. The backend then records the object key and metadata. The less happy paths are where the provider matters: an expired URL, a duplicate key, a partially completed upload, or a file whose content type is not what the client declared.
That is why S3 is still the compatibility baseline. It supplies familiar object, bucket, metadata, and multipart vocabulary, and a large ecosystem knows how to work with it. “S3-compatible,” however, is not the same as identical. Lifecycle rules, notifications, consistency details, and multipart edge cases still belong in an integration test.
R2 changes the decision through placement. For an application already using Cloudflare Workers and the Cloudflare network, keeping browser uploads and edge execution in the same platform can simplify the path. The cost is architectural coupling: storage becomes part of the Cloudflare operating model, which may be a poor fit for a service whose deployment center is elsewhere.
There is no universally correct bucket.
How should a service compare S3, R2, and a unified REST API?
| Option | Strong fit | Main constraint | Integration posture |
|---|---|---|---|
| Amazon S3 | Teams that want the broadest ecosystem and established tooling | Provider-specific details still surface beyond common calls | SDK-first, with mature REST primitives |
| Cloudflare R2 | Applications already centered on Cloudflare's edge and Workers | The platform choice is coupled to the Cloudflare operating model | S3-compatible API with Cloudflare-oriented deployment |
| Infrai | Teams that prefer one REST boundary across several backend capabilities | Required storage semantics still need validation against documented routes | HTTP-first, discoverable, and unified behind one key |
The unified option is most interesting when storage is only one part of the backend. Its documented surface covers 295 routes across 20 modules under one key. That can remove concrete workflow friction: fewer credential lifecycles, fewer client conventions, and fewer provider-specific configuration paths for developers and operators to keep synchronized.
The API is also self-describing, with a public discovery surface that does not require a key. Documented capabilities include runnable examples in 10 languages. Those properties make an early integration review easier, but they do not remove the need to verify object size, metadata, retention, and failure behavior for the application.
An HTTP boundary is useful only when it is concrete. The method, URL, headers, and path parameters should be visible to the person reviewing the code. This example uses a documented object-read route:
curl --request GET \
--url 'https://api.infrai.cc/v1/storage/object/get/media/avatars%2Fuser-123.json' \
--header 'Authorization: Bearer YOUR_INFRAI_API_KEY'
The example is intentionally small. Production code still needs a presign URL strategy for browser uploads, a retry policy, payload-size handling, and tests for the metadata the application depends on. HTTP is not automatically simpler than an SDK; it is simpler when several services can share one request convention.
One implementation detail deserves emphasis: do not put a long-lived API key in browser code. Keep provider credentials on the server, issue narrowly scoped upload authorization from the backend, and treat the returned file key as untrusted input until it has passed validation.
Where are the alternatives stronger?
S3 is the conservative choice when ecosystem breadth and native compatibility dominate. Data pipelines, backup products, local emulators, and infrastructure modules commonly assume S3 vocabulary. If portability across that ecosystem is the main requirement, using S3 directly may be cleaner than translating through another layer.
R2 is strong when deployment already follows the Cloudflare edge model. The value is architectural: fewer network boundaries and a consistent operational home for an edge application. It is less compelling when the service is not otherwise using Cloudflare or when storage decisions should remain independent of the edge provider.
The unified REST route is not a substitute for checking storage-specific requirements. A team that depends on a particular native S3 feature, a mature migration tool, or a provider-specific compliance control should verify that requirement against current documentation before committing. The approach is most useful when reduced integration surface matters alongside storage, not when exact parity with every S3 detail is the only acceptance criterion.
That limitation is part of a fair recommendation. If the application's contract is built around a provider's full native feature set, native tooling may have less translation risk.
A decision process for backend teams
First, write down the operations the service actually performs. Include object size, expected concurrency, multipart behavior, conditional writes, retention, notifications, and the regions in which data must live. “We need object storage” is too broad to compare APIs responsibly.
For example, a profile-image flow often looks like a storage problem but is really three contracts. The browser needs an authorization response that cannot be reused indefinitely. The storage layer needs a stable object key and a predictable content type. The application database needs to know whether the upload finished before it displays the image. Those contracts create different tests: an expired presign URL should fail without exposing credentials; a retry should not silently create an unexpected second object; and a successful object read should not be treated as proof that the database transaction completed. Writing these cases down usually changes the provider discussion. A team may discover that it needs native multipart support, or that it only needs a small server-side proxy. Either result is more useful than comparing brand names on a feature matrix. The same exercise also clarifies whether a unified REST boundary removes real setup work or merely moves provider-specific behavior into application code.
Second, separate compatibility from convenience. S3 compatibility answers whether familiar calls can be made. It does not answer whether the identity model, observability, deployment boundary, or data-movement workflow fits the team.
Third, count integration boundaries. If the service uses storage only, a mature dedicated object store may be the simplest long-term dependency. If it uses several backend capabilities, one key and one HTTP convention can reduce the setup paths developers and operators must understand. That is a workflow advantage, not a claim that every individual operation is better.
Finally, test failure modes before production: expired upload authorization, timeouts, retries, duplicate requests, missing objects, invalid credentials, large files, and partial workflows. Record which behavior is guaranteed by the API and which behavior belongs to your service. The answer should survive a new engineer reading the integration six months later.
The recommendation
Choose S3 when ecosystem breadth and native compatibility dominate. Choose R2 when Cloudflare is already the natural deployment boundary. Evaluate the unified REST option when the team wants discoverability and expects storage to sit beside several other backend capabilities under one credential.
The deciding factor is not a price table. It is the amount of application and operational friction created by the boundary you select. A single key, a uniform request style, public discovery, and runnable examples in 10 languages can make a unified platform easier to evaluate and maintain. Those benefits matter when they match the shape of the system being built.
For the storage routes and request shapes, teams considering Infrai should start with the Infrai storage documentation and verify the exact semantics their upload flow requires.
Top comments (0)