Cloudflare R2: bucket, CORS and delivery

1. Create your R2 bucket#

1. Sign in to Cloudflare and choose the account that will own the bucket.
2. Open Storage & databases → R2 Object Storage → Overview → Create bucket.
3. Enter a unique bucket name, such as customer-drm-media-example. Select an appropriate location or jurisdiction. Use Standard storage for this walkthrough, then create the bucket.
4. Open the bucket's Settings. Record the bucket name, Cloudflare account ID and General → S3 API endpoint.

For default jurisdiction, the API endpoint is https://<ACCOUNT_ID>.r2.cloudflarestorage.com. If Cloudflare shows a jurisdiction-specific hostname, use that exact hostname. Remove a trailing /bucket-name when entering the endpoint in DRM-X; the bucket name has its own field. This API endpoint is not a public playback URL.

2. Create bucket-scoped credentials#

1. Return to R2 Overview and open Manage API tokens. Choose an R2 account token, or a user token if required by your organization.
2. Select Create API token, give it a recognizable name, and choose Object Read & Write.
3. Choose Apply to specific buckets only and select this bucket. Configure expiry according to your policy. For this walkthrough, leave optional IP filtering unset. If your security policy requires it, validate both DRM-X server access and direct uploads from customer browser networks.
4. Create the token and securely record the Access Key ID and Secret Access Key for DRM-X.

3. Choose your public delivery URL#

12

Option A: connect your domain for production

1. Have a domain with its DNS setup completed in the same Cloudflare account. Choose a subdomain such as media.example.com.
2. In the bucket, open Settings → Custom Domains → Add. Enter the subdomain, review the DNS change, and connect it using this R2 workflow.
3. Wait for the domain and HTTPS certificate to become active. Your delivery origin is https://media.example.com.

Do not create a CNAME pointing to an r2.dev address. Use R2's Custom Domains workflow. The development URL can stay disabled when a custom domain is connected.

Option B: enable Cloudflare's URL for testing

1. Open Settings → Public Development URL → Enable.
2. Review the public-access notice, type allow when requested, and confirm.
3. Copy the actual https://pub-….r2.dev URL displayed by Cloudflare. Do not construct it from your account ID or bucket name.

The r2.dev endpoint is rate-limited and intended for development. Use a custom domain for production, caching and Cloudflare security features.

4. Configure browser upload and playback CORS#

12

1. Open Settings → CORS Policy → Add CORS policy (or Edit).
2. Paste the JSON below in the editor. Replace https://www.example.com with the origin of the website that embeds your player. An origin includes HTTPS and the hostname, but no page path such as /watch.
3. Preserve other required rules if the bucket already has a policy, then select Save.
4. Allow time for propagation, then retry the upload. If custom-domain objects have old CORS headers cached, purge the affected paths and test again.

[
  {
    "AllowedOrigins": [
      "https://6.drm-x.com"
    ],
    "AllowedMethods": [
      "PUT"
    ],
    "AllowedHeaders": [
      "Content-Type",
      "x-amz-meta-drmx-sha256"
    ],
    "ExposeHeaders": [
      "ETag"
    ],
    "MaxAgeSeconds": 3600
  },
  {
    "AllowedOrigins": [
      "https://6.drm-x.com",
      "https://multi-drm.drm-x.com",
      "https://www.example.com"
    ],
    "AllowedMethods": [
      "GET",
      "HEAD"
    ],
    "AllowedHeaders": [
      "Range"
    ],
    "ExposeHeaders": [
      "ETag",
      "Content-Length",
      "Content-Range",
      "Accept-Ranges"
    ],
    "MaxAgeSeconds": 3600
  }
]

The first rule allows signed PUT uploads from DRM-X Console. The second allows GET/HEAD from your player website and DRM-X test pages. R2 custom domains use the bucket's CORS policy. CORS does not grant anonymous upload access.

5. Connect R2 in DRM-X 6.0#

Open Cloud Storage → Connect storage and choose Cloudflare R2.

The examples use a folder called protected. The bucket name is not automatically a folder. With the direct domain-to-bucket mapping used here, include the same storage folder exactly once in the public URL prefix.

Bucket:                      customer-drm-media-example
Protected-content base path: protected
Public URL prefix:           https://media.example.com/protected
File selected for upload:    sample.encrypted.bin
Object key in the bucket:    protected/sample.encrypted.bin
Preview URL:                 https://media.example.com/protected/sample.encrypted.bin

To use the bucket root, leave the base path blank and enter only the delivery origin as the public prefix. Do not append a bucket name unless you deliberately use it as a folder. Leave CloudFront Origin path empty for this mapping.

Choose Use as default CLI upload destination if desired. Select Save and verify. Credentials are encrypted at rest and are not returned after saving. Continue to the real upload test even if verification succeeds.

6. Upload a file and verify that it works#

1. Open Cloud Storage, select this destination and choose Verify location. Success means the DRM-X server can list the bucket. It does not establish write permission, browser CORS or public delivery.
2. Select Upload encrypted files and choose one small encrypted segment from an existing DRM-X package. If you do not have a package, use the disposable encrypted diagnostic below. Do not upload an original video or personal document.
3. Wait for the success message. Check that the filename and size appear in Cloud Storage. Find the same object under protected/ in your provider console.
4. Click Preview URL, and test that same object in a private browser window. It should download or return HTTP 200 without an AWS or Cloudflare login. Test an actual object: a domain's root can return 403/404 even when object delivery works.
5. Check cross-origin delivery from your player website. Its browser Network panel should show Access-Control-Allow-Origin matching the player page's origin. A direct address-bar download does not test CORS. The terminal example below also checks the headers.
6. Remove only your disposable diagnostic object when done. Then follow the Desktop Packager guide, select this storage destination in Package content, and upload the complete encrypted package. Manually uploading a file does not register a Published Content ID.
7. Test the resulting Published file in Universal Playback Lab and your own player website. Verify video, audio, seeking and your required devices. A successful binary download is not proof of DRM playback.

$samplePath = Join-Path (Get-Location) 'drmx-storage-check.encrypted.bin'
if (Test-Path -LiteralPath $samplePath) { throw 'Choose a new folder; this test file already exists.' }
$aes = [System.Security.Cryptography.Aes]::Create()
try {
    $aes.GenerateKey()
    $aes.GenerateIV()
    $encryptor = $aes.CreateEncryptor()
    try {
        $bytes = [Text.Encoding]::UTF8.GetBytes('DRM-X disposable storage check')
        $encrypted = $encryptor.TransformFinalBlock($bytes, 0, $bytes.Length)
        [IO.File]::WriteAllBytes($samplePath, $encrypted)
    } finally { $encryptor.Dispose() }
} finally { $aes.Dispose() }
Get-Item -LiteralPath $samplePath | Select-Object Name, Length

curl.exe -I -H "Origin: https://www.example.com" "https://media.example.com/protected/sample.encrypted.bin"

Replace both URLs. Expect HTTP 200 and an allowed origin matching your player website. For range delivery, a GET request with Range: bytes=0-15 should return HTTP 206 and a valid Content-Range header. Preserve media MIME types: DASH manifests use application/dash+xml, HLS playlists use application/vnd.apple.mpegurl, and media files must use their appropriate media type.

7. Troubleshoot your result#

Official references#

• Create an R2 bucket
• R2 credentials and permissions
• Custom domains and r2.dev
• R2 CORS and cache behavior

Using AWS? Follow Amazon S3 and CloudFront setup.