Bring Your Own Bucket: Send Processed Images Straight to Your Own S3 or R2

The short answer

Three facts do most of the work in this guide. First, it is write-only: Mochify writes results into the bucket and does not read from it, list it, or touch anything already there. Second, the pipeline is handed a capability, not a credential: a pre-signed URL that can put one named object and expires in minutes. Third, it is available on Seller and Pro, in the web app, and not on Free or on a Day Pass, because a pass has no account to attach a bucket to.

If you run a store, an agency, or a build pipeline that already keeps its image library in object storage, this removes the step everyone dislikes: downloading a zip of optimized files and re-uploading it to the place they were always going to end up.

What Bring your own bucket does (and does not do)

Bring your own bucket is an output destination, not a sync tool. You point Mochify at a bucket from Dashboard → Connections, and from then on processed results are written into that bucket instead of coming back to you as a download to file away.

What it does:

• Writes results into storage you own. Amazon S3, Cloudflare R2, or any bucket that speaks the S3 API. Backblaze B2, Wasabi, DigitalOcean Spaces, MinIO, Tigris, and Hetzner all document S3-compatible endpoints, and the pattern is the same for each.
• Keeps the input path unchanged. Files still upload from your browser to api.mochify.app over HTTPS and are processed in memory. The bucket is where the answer goes, not where the question comes from.
• Stays write-only. The connection exists to put objects. It is not used to read your existing images, enumerate the bucket, or delete anything.

What it does not do, at launch:

• It is a web app feature. The REST API, the CLI, and both MCP servers return results to the caller the way they always have. Do not build a script on the assumption that an API call will land a file in your bucket; that is not how the feature ships today.
• It is not a Free or Day Pass feature. Bucket output is on Seller ($7.99/month) and Pro ($24.99/month). A Day Pass is a $2, 24-hour, no-account unlock, and there is no account for a bucket to belong to.
• It is not a file manager. Mochify does not browse, organize, or clean up your bucket. Your storage stays your business.

Google Drive appears next to it on the Connections screen marked "Coming soon". That is all it is for now, so plan around buckets.

Who holds the key: pre-signed URLs, explained for buyers

The safest way for a service to write into your bucket is for the service to never touch your bucket credential at all, and that is how this works: one isolated component holds your encrypted key, and the processing pipeline only ever receives a short-lived, single-object URL derived from it. Every write-your-own-bucket feature on the market has to answer "who holds my key," and most vendor pages skip the question. Here is the honest version.

A pre-signed URL is a standard object-storage mechanism. Amazon's own documentation puts it simply: "A presigned URL gives you access to the object identified in the URL, provided that the creator of the presigned URL has permissions to access that object," and "the capabilities of a presigned URL are limited by the permissions of the user who created it" (AWS S3 User Guide). Cloudflare R2 implements the same idea through its S3-compatible API and describes it as "granting temporary access to objects without exposing your API credentials" (Cloudflare R2 docs). The URL names one object, one operation, and one expiry. Whoever holds it can do that one thing until the clock runs out, and nothing else. This URL is plumbing between our services and your bucket; you never see it, and it is unrelated to the download link the hosted MCP server returns.

Our architecture and data handling page states how Mochify uses it, and it is worth quoting because this is the one feature where we hold a credential on your behalf:

• "Your keys are encrypted and isolated. The secret is sealed with AES-256-GCM under a key held by a single service. The dashboard cannot decrypt it, and the image pipeline never sees it at all."
• "The pipeline receives a capability, not a credential. When a result is written to your bucket, the processing service is handed a pre-signed URL valid for one object and a few minutes. It cannot choose the destination, list your bucket, or read anything from it."

Two details deserve a plain-English translation. AES-256-GCM is authenticated encryption: it protects the stored key against being read and against being tampered with, and it is specified by NIST in SP 800-38D. Sealing your secret "under a key held by a single service" is the envelope pattern, where the thing that can unwrap the secret lives in one place and the systems that do the work are never given it.

The practical consequence is blast radius. AWS lets a pre-signed URL live for up to seven days when it is minted with long-term credentials; ours lives for minutes and covers one object. If the processing container were ever compromised, the most an attacker could do with what it holds is finish writing the file it was already writing. It could not read your catalog, list your bucket, or pick a different destination, because the URL it was given cannot do any of those things.

Why zero retention is unchanged with a bucket connected

Writing a result into your bucket does not add a copy on Mochify's side, because the result never stops anywhere on Mochify's side: it travels from the processing container straight to your storage, and the processing container itself has no disk to keep it on. The zero-retention line for images and PDFs is unchanged.

It helps to be precise about what that line is, because it is not one blanket claim. Images and PDFs travel to api.mochify.app over HTTPS, are streamed into memory, processed, and discarded, with no disk writes and no logs containing file data. That holds across the web app, the REST API, the CLI, and both MCP servers. The hosted MCP server is the one documented exception: it holds the compressed output in a pickup store for about five minutes so the short-lived files.mochify.app URL can resolve, then evicts it; we wrote up the reasoning in why we relaxed our zero-retention policy for MCP. Video is different again: it is processed in the browser and never leaves your device.

Bring your own bucket sits inside that model, not outside it. The /architecture page says the result "does not pass back through your browser and it is not staged anywhere in between," which is the whole point: there is no Mochify-side copy to retain, expire, or delete. The copy that exists is in your bucket, under your account, subject to your lifecycle rules and your access policy.

For the agency and regulated-data audience, that distinction matters in contract terms as well. Under GDPR a processor may only engage a further processor with the controller's authorization, must apply security measures appropriate to the risk, and must not keep personal data longer than necessary. A pipeline that holds nothing has very little to account for on the retention side, and a result written to your own bucket is stored by you, under your controls, rather than by a sub-processor. Our Data Processing Agreement covers the processing itself; note that it describes in-memory processing and the MCP pickup exception, and does not add any bucket-related retention, because there is none to add. If you need the DPA language for a specific client review, privacy and image optimization for agencies walks through how to read it.

Where the output goes next: buckets, CDNs, and your storefront

Once the file is in your bucket, the CDN you already have in front of that bucket serves it, and nothing new has to be hosted. This is the step every tutorial on "image processing with S3" stops short of, and it is the step the forum threads keep asking about ("how can we show the processed images from the AWS S3 bucket as product pictures?").

The two mainstream patterns:

• Cloudflare R2 behind a custom domain. Cloudflare's documentation notes that "domain access through a custom domain allows you to use Cloudflare Cache to accelerate access to your R2 bucket" (R2 public buckets). A processed hero.webp written to the bucket is a cacheable https://img.yourdomain.com/hero.webp a moment later.
• Amazon S3 behind CloudFront with origin access control. The bucket stays private; CloudFront is the only principal allowed to read from it (CloudFront developer guide). The same object, served from the edge, with S3 Block Public Access still on.

Two honest caveats. Object storage does not transform anything on its own; as one Cloudflare community answer puts it, "R2 is just an object storage bucket. It doesn't offer such transformations natively." That is exactly the gap this feature fills: the transformation happens at Mochify, and the bucket receives the finished asset. And if your images are listed on a marketplace or a hosted storefront, the bucket is your master library, not the listing. Shopify, for example, serves product media from its own CDN and accepts images up to 5000 x 5000 pixels and under 20 MB (Shopify Help Center); you still upload to the platform, but you upload the optimized file from a bucket you control rather than a downloads folder. For the per-platform limits, see our marketplace product image requirements guide.

Why bother optimizing before the file ever reaches the bucket? Because image bytes are still the largest thing on the page. The 2025 HTTP Archive Web Almanac reports the median mobile home page carrying 911 KB of images and the median desktop page 1,058 KB, more than any other resource type (Web Almanac: Page Weight), and images are the Largest Contentful Paint element on 76.0% of mobile pages and 85.3% of desktop pages (Web Almanac: Performance). A bucket full of unoptimized originals behind a fast CDN is still a slow site.

What it costs on your side

Bring your own bucket is included in Seller and Pro; the only new line item is your own bucket's storage and requests, which for most stores and agencies is small change next to the plan. The numbers depend on the provider:

• Cloudflare R2 publishes $0.015 per GB-month for Standard storage, $4.50 per million Class A operations (writes), $0.36 per million Class B operations (reads), and no egress charge: "egressing directly from R2 ... does not incur data transfer (egress) charges and is free" (R2 pricing). Each processed image is one write, so a 10,000-image catalog refresh costs a few cents in operations.
• Amazon S3 publishes per-region storage and request rates on its pricing page, with the first 100 GB per month of data transfer out to the internet free across AWS services. Beyond that allowance, egress is the number to watch on AWS; it is the reason many image-heavy sites put CloudFront or a third-party CDN in front of S3 rather than serving from the bucket.
• S3-compatible providers each publish their own rates. Several compete on egress; check the provider's page rather than assuming S3's model.

The cost you are not paying is the pipeline. The build-it-yourself route (a Lambda function, an image library, an API gateway, a queue, and someone to keep it patched) is free in cloud fees and expensive in hours. This feature is for the team that would rather not own that.

Scoping the key on your side

Whatever service you connect to a bucket, the right posture on your side is a key that can only do what the feature needs, on only the bucket it needs, and Bring your own bucket is write-only by design, so a narrowly scoped key lines up with how it is used. This section is general object-storage hygiene rather than a Mochify setup manual; the Connections screen tells you what it asks for.

• Dedicated bucket or prefix. Give processed output its own bucket, or its own prefix in an existing one. It keeps the blast radius small and makes the lifecycle rules simple.
• Least privilege. AWS's own guidance is to "grant only the permissions that are required to perform a task" (S3 security best practices), and its example bucket policies include an s3:PutObject-only grant for a third party (example bucket policies). On R2, API tokens can be scoped to specific buckets with read-only or read-and-write permission (R2 tokens).
• Keep the bucket private. Block Public Access on S3, and serve through the CDN. Encryption at rest is on by default: since January 2023 every new S3 object is encrypted with SSE-S3 unless you choose another option.
• Rotate on your schedule. A dedicated key for one integration is easy to rotate or revoke without touching anything else in your account.

One more reason the pre-signed model is worth insisting on from any vendor: because the pipeline only ever holds a one-object URL, a narrowly scoped key is all it can ever exercise. A service that instead ships your long-lived credential to every worker cannot make that promise, whatever its permissions policy says.

Mochify Workflow: connect once, process in plain English

The workflow is the normal Magic Flow workflow with one setup step in front of it. Magic Flow is Mochify's natural-language interface: you describe the outcome ("compress these for the product grid, max 2048 px, strip location data"), a language model parses the request, and the native C++ engine executes it. With a bucket connected, the results of that request are written into your storage.

For developers: the REST API (POST /v1/squish on api.mochify.app, authenticated with Authorization: Bearer <key>), the mochify CLI, and the local and hosted MCP servers all return results to the caller as before. Bucket output is a web app feature at launch. If your automation needs files in a bucket today, write them there from the client that receives the result, using your own scoped key, which is the same pattern we use on our side.

Cheat Sheet: where does my file go on each Mochify surface?

Bring your own bucket: Seller and Pro only, web app only at launch, write-only, S3 / R2 / S3-compatible. Not on Free, not on a Day Pass.

FAQ