Storage Capability Matrix

This page is a quick reference, not a tutorial

Per-backend onboarding steps live in the Storage Backends tutorials; the storage policy and policy group concepts live in Storage Policies and Policy Groups. This page only answers “what can each backend do” and “which path do uploads / downloads take”.

Capability Quick Reference

Backend	Deployment scope	Browser direct upload	Direct download	Capacity	Storage-native processing	Credential mode
Local	Instance-local	No	No	Yes	No	None
S3	Shared across Primary instances	Presigned	Yes	No	No	Static secret
Alibaba Cloud OSS	Shared across Primary instances	Presigned	Yes	No	No	Static secret
SFTP	Shared across Primary instances	No	No	No	No	Static secret
Azure Blob	Shared across Primary instances	Presigned	Yes	No	No	Static secret
Tencent COS	Shared across Primary instances	Presigned	Yes	No	Thumbnail + media metadata	Static secret
Remote	Shared across Primary instances	Presigned	Yes	Yes	No	None
OneDrive	Shared across Primary instances	Provider-direct	Yes	Yes	No	Delegated OAuth
Qiniu Kodo	Shared across Primary instances	Presigned	Yes	No	No	Static secret

The table shows each connector’s static capability ceiling; policy settings and deployment topology can narrow the usable paths. For example, remote-node presigned transfer requires direct mode and a browser-reachable follower base_url, while its capacity result depends on the remote storage target.

Static secret and Delegated OAuth describe how credentials are acquired, not a plaintext database format. Every connector-managed static secret, authorization-application secret, and OAuth token is encrypted at rest with AES-256-GCM using [auth].storage_credential_secret_key. Preserve that key across backups and migrations. See Authentication and Sessions.

relay_stream vs presigned

This section is the single authoritative explanation of upload / download modes; each backend tutorial only covers its own enablement conditions and differences.

Mode	Data path	Upside	Cost
relay_stream	Browser ↔ AsterDrive ↔ storage backend	Browser never touches the backend directly, no CORS pitfalls; works with intranet backends; easier to troubleshoot	Traffic flows through AsterDrive, consuming node bandwidth and connections
presigned / direct	Browser ↔ storage backend (AsterDrive only signs URLs)	Offloads AsterDrive bandwidth; steadier for large files and high concurrency	Browser must reach the backend; requires CORS, HTTPS certificates, and exposed response headers

Suggested order: bring up any new backend with relay_stream first — uploads, downloads, previews, shares — and switch to presigned per the tutorial only after it proves stable.

Before switching to presigned, confirm:

• Browsers can directly reach the object storage endpoint or the follower base_url (usually a real HTTPS hostname)
• Backend CORS allows the AsterDrive site’s origin and exposes the response headers downloads and Range requests need
• Public shares, image previews, and PDF / video Range requests were all re-validated under the new mode

OneDrive is the exception: cross-origin support for its frontend_direct upload is provided by Microsoft, so no extra CORS setup is needed on the AsterDrive or object-storage side.