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)

Browser (presigned URLs)

The browser OCIResource 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.

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 resource docs for the equivalent Python wiring.