Skip to main content
OCI’s S3 Compatibility API accepts AWS Signature V4 against https://<namespace>.compat.objectstorage.<region>.oci.customer-oci.com. MIRAGE derives this endpoint from your namespace + region automatically. Credentials (bucket, namespace, region, customer secret key pair) are created the same way in both runtimes, see OCI Credentials.

Node (server-side)

Config

Fields marked secret are redacted in snapshots.

Browser (presigned URLs)

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

Config

Fields marked secret are redacted in snapshots.

1. Server: sign URLs with the OCI endpoint

OCI requires path-style URLs (forcePathStyle: true), virtual-hosted style is not supported on the S3 Compatibility API.

2. Browser: wire it up

3. CORS

OCI’s S3-compatibility endpoint ships with permissive default CORS rules that echo back whatever Origin the browser sends, so local dev typically “just works” without any bucket configuration. For production origins you can tighten the policy through the OCI Console (Bucket → Pre-Authenticated Requests / CORS) or via the native OCI CLI:
OCI’s CORS is not configurable via the S3-compat PutBucketCors call, the schema differs. Use the native OCI Console or CLI.
See the OCI 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 OCI Object Storage 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 OCI answers through its own API, so fewer files are read. Integration explains each command.