Skip to main content
Wasabi uses the S3 API with AWS Signature V4 against https://s3.<region>.wasabisys.com (https://s3.wasabisys.com for us-east-1). MIRAGE derives this endpoint from your region automatically. Credentials (Wasabi access key pair) are created the same way in both runtimes, see Wasabi Credentials.

Node (server-side)

Config

Fields marked secret are redacted in snapshots.

Browser (presigned URLs)

The browser WasabiVFS is secret-free, your backend signs each operation using your Wasabi keys and returns a URL. Wasabi accepts AWS Signature V4, so @aws-sdk/s3-request-presigner works, pointed at the Wasabi endpoint.

Config

Fields marked secret are redacted in snapshots.

1. Server: sign URLs with the Wasabi endpoint

For us-east-1 the endpoint is https://s3.wasabisys.com (no region segment).

2. Browser: wire it up

region on the browser config is only used for display/logging; the actual endpoint is baked into the presigned URLs your backend returns.

3. CORS

Wasabi supports the S3 PutBucketCors call, so the AWS CLI works against the Wasabi endpoint:
See the Wasabi VFS docs for the equivalent Python wiring. For write: conditional on this provider, see S3-compatible stores.

VFS.md

The VFS.md an agent reads with Wasabi mounted at /<path>.

Virtual Filesystem

Supported Unix Commands for VFS

Unix commands work on each path as on a local filesystem, as far as the path supports them:

Limitations of Unix Commands for VFS

Where a path differs from a local filesystem:Run man <cmd> or <cmd> --help for one command’s usage.

Integration

What Wasabi answers through its own API, so fewer files are read. Integration explains each command.