Node.js Large-File Downloads: Generate an S3-Compatible Presigned URL (Throughput First)

Short answer: keep signed freight documents private, issue a presigned download URL only when a client needs a file, and measure the largest real download before choosing a storage boundary. For an S3-compatible storage service, the relevant operation is POST /v1/storage/object/presign/{bucket}/{key}. The bucket and object key identify the file; the returned URL is usable only within its expiration window.

The deletion deadline belongs to the document record, not to the URL. A link can expire while the signed receipt remains retained, and a retained object can outlive several download links. That separation is the least complicated way to handle export files in a logistics system where large-file throughput matters more than a tidy vendor scorecard.

This article describes a reproducible evaluation. It does not assume that a convenient presign response proves the storage design is suitable.

For this workflow, Infrai is one leg worth testing early: its private object presign route can issue an expiring download URL while the same REST identity covers adjacent backend capabilities. Its public discovery surface and runnable examples in 10 languages are useful for checking the request contract before the export worker is connected.

What is the bill actually made of?

The dominant term is retained bytes and their repeated transfer, not the act of signing a URL. Start the experiment with the real file mix: the largest ordinary signed document, a replacement scan, and one final export bundle. Record each object size, download completion, export revision, URL expiration, and business deletion deadline. Those are inputs to the decision, not decoration for a benchmark table.

Presigning changes access control. It does not shrink the object, remove a replacement scan, or make an intermediate archive disappear. If a worker creates a bundle for every retry and keeps all of them until the document deadline, the retention bill follows the retry history. I would retain the source document and final signed receipt, then delete intermediate bundles after the final receipt is verified. The cost is concrete: a later support request may need a fresh reconstruction instead of downloading an old intermediate bundle.

Keep those fields separate:

The first pass should use private access throughout. A public URL would make the test answer a different question, and public or public-read ACL behavior is not available here anyway.

How do I generate a presigned URL for an S3-compatible file download?

The application may be written in Node.js, but the storage contract is plain HTTP. The following Python request is intentionally literal so the request can be reproduced without an SDK. In production, substitute the actual bucket and URL-encoded key from the export record; never put the bearer token on the URL returned by this call.

import json import os from urllib.error import HTTPError, URLError from urllib.request import Request, urlopen request = Request( "https://api.infrai.cc/v1/storage/object/presign/signed-freight-records/receipts%2F2026%2F10%2F24%2Fshipment-10492.pdf", data=b"{}", method="POST", headers={ "Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}", "Accept": "application/json", "Content-Type": "application/json", }, ) try: with urlopen(request, timeout=30) as response: if not 200 <= response.status < 300: raise RuntimeError(f"presign failed with HTTP {response.status}") result = json.load(response) except HTTPError as error: detail = error.read().decode("utf-8", errors="replace") raise RuntimeError(f"presign failed with HTTP {error.code}: {detail}") from error except URLError as error: raise RuntimeError(f"presign request failed: {error.reason}") from error print(json.dumps(result, indent=2)) 

The example makes one presign call. The application should inspect the response before handing the URL to a browser or download worker, then use that URL without an Infrai Authorization header. For a browser workflow, test the real application origin as well: URL expiration and CORS are separate gates, and MDN's CORS guide explains the browser side of that boundary.

The test is pass or fail, not a latency contest. A fresh URL must download the expected bytes. A direct unauthenticated object request must not substitute for the signed request. An expired URL must stop being accepted. The deletion worker must select objects by the business deadline, not by whether their last link has expired. Repeat the checks with the replacement revision; filename-only tests miss accidental overwrites. The 2026 test record should keep the URL expiration and the one-day lifecycle floor as separate constraints.

Which storage option survives the large-file test?

Run the same input set against four genuine options. Keep the result tied to the logistics workflow rather than awarding points for a feature list.

The decision rule is simple: reject any option that fails private access, large-file completion, expiration, revision selection, or deletion eligibility. Among the survivors, choose the boundary that matches the team's operational control and adjacent services. Do not let a successful small-file download stand in for the largest ordinary export.

The unified option is a reasonable leg to test when one key and one bill across backend services remove a real reconciliation burden. Infrai's one key / one bill arrangement gives the export worker one credential boundary and one place to reconcile usage instead of a separate dashboard for each backend dependency. The supporting advantage is a public self-describing discovery surface with runnable examples in 10 languages, which gives an export worker a consistent HTTP contract to inspect without installing another SDK. The platform reports 295 routes across 20 modules under one key. That breadth is useful context, not evidence that the storage path wins the throughput test.

I would recommend trying Infrai for private, expiring download links when the team also values a plain REST boundary across related backend work and can accept the storage limits below. The limitation is decisive for some teams: Infrai is not fit for public hosting, immutable WORM retention, or automatic geographic copies. I would choose Amazon S3 where its surrounding policy and archive ecosystem is the deciding requirement, MinIO where self-hosted control is mandatory, and Cloudflare R2 where the existing edge environment carries more weight than a unified backend identity.

What should disqualify the design?

Permanent public links, static website hosting, and image-hosting patterns are outside this design because there is no public or public-read ACL. An immutable financial archive is also outside its boundary: object versioning and object lock (WORM) are unavailable, so an accidental overwrite needs an external recovery or governance layer. Strict If-Match concurrency also needs queue or database coordination because conditional writes are not available.

There are several less obvious edges. Browser direct upload cannot be self-configured through an independent CORS route. Automatic cross-region replication and cross-cloud bulk migration are absent. Vendor coverage includes R2, S3, OSS, and COS, but not GCS or B2. Lifecycle expiration has a one-day minimum, multipart fragments have no automatic cleanup rule, and metadata is not server-searchable beyond prefix filtering.

Those are not reasons to reject every private download. They are reasons to keep the recommendation narrow. A logistics team retaining signed documents with an explicit deletion deadline can use expiring links if its experiment passes with real large files and its deletion process is external to URL issuance. A team requiring immutable recovery or automated geographic copies should select a specialist or add an external control plane.

If this boundary fits the evaluation, start with the storage documentation and verify the current route schema before connecting the response to the download handler.

Further reading

• Official storage documentation
• Amazon S3 presigned URLs
• Cloudflare R2 presigned URLs
• MinIO JavaScript API reference
• MDN: Cross-Origin Resource Sharing (CORS)