feat(storage): add server uploadData storage api

[osama-rizk]

Description of changes

Adds a new server-side uploadData API for Storage, consumable in Next.js Server Components, Route Handlers, and Server Actions. Customers can now upload data directly from server contexts using the same Amplify server context pattern already used by list, getProperties, getUrl, remove, and copy.

This addresses a long-standing customer request to upload files from a Next.js backend (tracked in #13636), which was previously only possible from the client. Enabling server-side upload unblocks common patterns where the file needs to be validated, transformed, or persisted together with database state on the server before being stored in S3.

Usage

import { runWithAmplifyServerContext } from '@aws-amplify/adapter-nextjs';
import { uploadData } from 'aws-amplify/storage/server';

await runWithAmplifyServerContext({
  nextServerContext: { cookies },
  operation: (contextSpec) =>
    uploadData(contextSpec, {
      path: 'uploads/file.jpg',
      data: file,
    }).result,
});

Implementation approach

Rather than duplicating the upload pipeline, this PR refactors the existing internal uploadData implementation to accept an AmplifyClassV6 instance via dependency injection (first positional argument), eliminating its dependency on the global Amplify singleton. The existing client-side API, the advanced internals/apis/uploadData, and the new server-side API all pass their respective Amplify instance to the same shared internal pipeline. This keeps multipart upload, checksum computation, cancellation, and progress reporting logic in a single place.

Key changes

• Refactored providers/s3/apis/internal/uploadData/* to accept amplify: AmplifyClassV6 as first parameter (removes implicit dependency on the global Amplify singleton).
• New public API: providers/s3/apis/server/uploadData.ts — thin wrapper that injects getAmplifyServerContext(contextSpec).amplify into the internal pipeline.
• Updated client-side providers/s3/apis/uploadData.ts to explicitly pass Amplify.
• Updated advanced internals/apis/uploadData.ts to explicitly pass Amplify.
• Exported the new uploadData from providers/s3/apis/server/index.ts; automatically flows through the existing @aws-amplify/storage/server → aws-amplify/storage/server re-export chain.
• Fixed providers/s3/utils/readFile.ts to fall back to Blob.arrayBuffer() when FileReader is unavailable, so server-side uploads (which depend on this path for CRC32/MD5 checksum calculation on sliced parts) work under Node.js runtimes.

Server-side behavior notes

• resumableUploadsCache (used for pause/resume on the client) is intentionally NOT injected on the server path, since every server request runs in an isolated context and there is no consistent cross-request storage for upload state. task.pause() / task.resume() are gracefully handled as no-ops in this case (already supported by createUploadTask).
• Multipart uploads work end-to-end on the server for files above the default 5 MiB part size threshold.

Issue #, if available

Closes #13636

Description of how you validated changes

Unit tests

All 796 storage unit tests pass (yarn test from packages/storage), including:

• Updated: internal/uploadData/index.test.ts (18 tests), internal/uploadData/putObjectJob.test.ts (19 tests), internal/uploadData/multipartHandlers.test.ts (93 tests), providers/s3/apis/uploadData.test.ts (client wrapper), internals/apis/uploadData.test.ts (advanced API) — all updated to pass an Amplify instance as first argument.
• New: providers/s3/apis/server/uploadData.test.ts — 4 tests covering path-based input, key-based input, verification that resumableUploadsCache is NOT injected server-side, and verification that the server context's amplify (not the global singleton) is used.
• Added: server-side fallback test in providers/s3/utils/readFile.test.ts.

Build

yarn build in packages/storage passes with no type errors.

Manual E2E validation in a Next.js 16 (App Router, Turbopack) sample app

• Small file upload (<5 MiB) via Route Handler using the new uploadData from @aws-amplify/storage/server — succeeded, single PutObject path.
• Large file upload (9 MiB and larger) via Route Handler — succeeded, multipart upload path (2+ parts) with CRC32 checksum on each part.
• Same scenarios validated through a Next.js Server Action — succeeded.
• Verified authentication via Amplify server context (HTTP-only cookie) flows through to S3 request signing.

Checklist

• PR description included
• yarn test passes
• Unit Tests are changed or added
• Relevant documentation is changed or added (and PR referenced)

Checklist for repo maintainers

• Verify E2E tests for existing workflows are working as expected or add E2E tests for newly added workflows
• New source file paths included in this PR have been added to CODEOWNERS, if appropriate

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[changeset-bot]

🦋 Changeset detected

Latest commit: 12af5cf

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@aws-amplify/storage	Minor
aws-amplify	Minor
@aws-amplify/predictions	Patch
@aws-amplify/adapter-nextjs	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[bobbor]

just some small nit. let me know what you think

[bobbor]

in JSDoc, the first paramter is the type.

@throws {ErrorType} Description of when this error is thrown.

Suggested change

	* @throws An `S3Exception` when the underlying S3 service returned error.
	* @throws A `StorageValidationErrorCode` when API call parameters are invalid.
	* @throws S3Exception when the underlying S3 service returned error.
	* @throws StorageValidationErrorCode when API call parameters are invalid.

[osama-rizk]

JSDoc description updated ✅

[bobbor]

see previous comment

[osama-rizk]

✅

[soberm]

Should we add/update E2E tests for this feature?

[osama-rizk]

Should we add/update E2E tests for this feature?

Yes, E2E tests will be added as a follow up PR.