Upload files to Cloudflare R2 from Mac

Upload file to R2 from Mac: setup

To upload files to Cloudflare R2 from Mac, choose your own R2 bucket and enter its connection details in Yuzu Drag's Upload settings. Drag a file, open Actions, and drop on UPLOAD. The operation sends files to your own S3-compatible bucket over the network; Yuzu does not provide hosted storage or make the bucket public.

Shortcut note: These steps use the default drag shortcuts. While holding the files, briefly press and release ⌘ for Tools; tap it again for Actions. ⇧ opens Convert. If you changed the shortcuts in Yuzu, use your configured keys instead.

A successful upload does not automatically make an object public. Decide separately who should be able to retrieve the file and whether you need a public URL at all.

Start with the provider's browser interface

macOS Finder does not include an R2 bucket connection. For an occasional upload, use Safari or another browser to open your Cloudflare dashboard, select the intended bucket, and use its upload interface. This avoids installing a desktop client or giving one a storage credential.

After the upload, inspect the object in the dashboard. Confirm its name, destination bucket, and intended access. For one-off administration or changing bucket policies, the provider dashboard is the clearer place to work because those policies are outside a file-dragging utility's role.

Use a desktop uploader when the bucket is already configured and repeatedly opening the dashboard is the part you want to avoid. Keep the dashboard available for checking objects, access rules, credentials, and account usage.

Prepare your own bucket and credentials

Before configuring Yuzu, collect the endpoint, bucket name, access key ID, and secret access key from your provider account. For Cloudflare R2, the region is auto. Use the actual endpoint supplied for your account rather than copying another person's example endpoint.

Give the credential only the permissions needed for the intended bucket and workflow. Keep it out of documents, screenshots, shell history, and shared messages. Yuzu stores the secret in Keychain, but that does not remove your responsibility to protect and revoke the credential in your provider account.

Choose a small, non-sensitive test file. The first test should establish which bucket and path receive the object, not transfer a complete working folder before you have checked the settings.

Configure Upload in Yuzu Drag

Install the app from the download page. Open its Upload settings and enter the fields shown in the form:

1. Endpoint: your S3-compatible service endpoint.
2. Bucket: the existing bucket you own or are authorized to use.
3. Access Key ID: the corresponding credential identifier.
4. Secret: the secret access key, stored in Keychain when saved.
5. Region: auto for Cloudflare R2.
6. Path prefix: an optional prefix for objects uploaded through this setup.
7. Public URL: an optional public URL base for generating links.

Use Test connection to check the draft configuration. The connection test performs a bucket check; it does not save the edited values. Click Save separately when you want to keep them. A successful connection check is useful evidence about connectivity, but it is not a complete upload-and-download test.

The public URL field is optional. Enter a base that actually serves the uploaded objects if you want usable public links. Typing a URL does not change the bucket's access policy or create a public domain for it.

Upload and inspect the result

1. Begin dragging the test file in Finder.
2. Tap ⌘ for Tools, then ⌘ again for Actions. Some mixed-kind selections open directly in Actions.
3. Drop on the UPLOAD wedge.
4. Wait for the job result.
5. Inspect the uploaded object in your provider dashboard.
6. Paste the copied result into a private note and check whether it is a URL or an object key.

The wheel also uses ⇧ for Convert; that group is separate from uploading. UPLOAD is an Action, and it accepts files rather than folders.

With a public URL base configured, Yuzu copies links after upload. Without one, it copies object keys. For a batch, the copied results are separated by newlines. Inspect them before pasting into a message: an object key is not a recipient-ready download link.

The upload creates a remote object and leaves the local source file in place. If an existing remote object already uses the intended name, Yuzu tries a numbered name rather than intentionally replacing it. Confirm the final key instead of assuming the original filename was used unchanged.

Public access, costs, and failures

Only share a public link when that access is appropriate for the file. Test the link without relying on an already authenticated dashboard session. If the object should remain private, keep it private and use your organization's approved access method instead of entering a public base merely for convenience.

Storage, retrieval, and provider limits belong to your account. Yuzu is not a backup service, a bucket-policy editor, or a promise that a link will remain available. Manage deletion and retention in the provider dashboard.

If a batch partly succeeds, check its job result before retrying the whole selection. Completed objects can remain present even if later items fail or you cancel the rest. A retry may create additional numbered objects, so reconcile the bucket contents with the files you meant to send.

For connection errors, recheck the endpoint, bucket, region, and credential scope before changing unrelated settings. The actions hub and guides index help distinguish uploading from local file organization.

Related links

• Browse the tools hub
• Read the guides
• Download Yuzu Drag