File upload and storage: the agent answers

I’d use **Cloudflare R2 behind a Cloudflare custom domain/CDN**.

For small traffic with repeatedly viewed screenshots, it offers the best balance of predictable cost, fast delivery, and straightforward Node/React integration. R2 currently includes 10 GB of Standard storage, 1 million writes, and 10 million reads per month; beyond that, storage is $0.015/GB-month and reads are $0.36 per million. Internet egress is free. [Cloudflare R2 pricing](https://developers.cloudflare.com/r2/pricing/)

Recommended design:

1. Your Node API authenticates the support agent and generates a short-lived presigned `PUT` URL.
2. React uploads directly to R2, avoiding your application server.
3. Store the resulting object key—not the signed upload URL—in the article record.
4. Serve it from `assets.yourdomain.com`, which activates Cloudflare’s edge cache. [Presigned uploads](https://developers.cloudflare.com/r2/api/s3/presigned-urls/) and [R2 caching](https://developers.cloudflare.com/cache/interaction-cloudflare-products/r2/)
5. Give every upload an immutable name such as `articles/{articleId}/{uuid}.png`, with a long cache lifetime. Replacing an image should create a new key, eliminating cache-invalidation problems.

The important caveat is access control. A custom-domain R2 bucket is effectively public for reads. That is ideal for public help articles, but not for internal or customer-specific screenshots. Private content would need authenticated delivery through a Worker, Cloudflare Access, or another signed-delivery layer. Cloudflare documents those options here: [R2 public buckets and access control](https://developers.cloudflare.com/r2/buckets/public-buckets/).

What I considered:

| Provider | Why it was considered | Why I wouldn’t choose it here |
|---|---|---|
| Amazon S3 + CloudFront | Mature, extremely durable, excellent controls, natural choice if your infrastructure is already AWS | More components, IAM and cache configuration, and less predictable bandwidth billing. It becomes my choice if you already operate heavily in AWS or require its governance features. |
| Cloudinary | Excellent upload UI, resizing, compression, format conversion, asset management, and CDN delivery | Screenshots generally do not justify an image-management platform. Its credits combine storage, transformations, and bandwidth, making it substantially richer—and potentially costlier—than needed. The free plan currently provides 25 combined monthly credits. [Cloudinary plans](https://cloudinary.com/documentation/billing_and_plans) |
| Vercel Blob | The least code if the React app already runs on Vercel; it has a pleasant client-upload flow | Delivery is billed, its asset network uses regional hubs rather than the main city-level CDN, and it adds platform coupling. Still a reasonable “ship it today” option for an all-Vercel application. [Vercel Blob](https://vercel.com/docs/vercel-blob) |
| Upload-focused services | Fastest initial developer experience | Another vendor and abstraction for something the AWS S3 SDK already handles cleanly against R2. |
| Storing images in the database | Simple backup story | Poor fit for hot binary delivery, inflates backups, and places unnecessary load on the application/database. |

Before shipping, I would also enforce authentication, file-size limits, an allowlist of PNG/JPEG/WebP, decoded-image validation rather than trusting the MIME header, randomized keys, and removal of screenshot metadata. Support screenshots frequently contain customer information, so I would establish retention/deletion behavior and confirm your organization’s data-processing and regional-storage requirements.

Bottom line: **R2 is my default choice; S3 + CloudFront wins only if you are already deeply invested in AWS or need stricter private-content controls, and Cloudinary wins if automatic image transformations become a real product requirement.**

I’d use **Cloudflare R2 behind Cloudflare’s CDN**, optionally adding Cloudflare Images for resizing and modern formats.

It fits this workload unusually well:

- Screenshots are simple immutable objects, so a full digital-asset-management platform is unnecessary.
- R2 is S3-compatible, works with the AWS JavaScript SDK, and supports browser uploads through presigned `PUT` URLs.
- Delivery through a custom domain such as `help-assets.example.com` is cached at Cloudflare’s edge.
- R2 currently includes 10 GB storage, 1 million writes, and 10 million reads monthly; beyond that, standard storage is $0.015/GB-month, with no internet-egress charge. [R2 pricing](https://developers.cloudflare.com/r2/pricing/)
- Cloudflare explicitly recommends a custom domain and cache for production delivery; `r2.dev` is only a development endpoint. [R2 caching](https://developers.cloudflare.com/cache/interaction-cloudflare-products/r2/)

### How I’d implement it

1. Your Node API authenticates the support agent and generates a short-lived presigned upload URL.
2. React uploads directly to R2, avoiding a trip through your Node server.
3. Store objects under unguessable, immutable keys such as `articles/{articleId}/{uuid}.png`.
4. Return the permanent custom-domain URL and use a long cache policy: `public, max-age=31536000, immutable`.
5. Never overwrite an existing key—upload a new version so CDN invalidation is unnecessary.
6. Validate size and declared type before signing, then verify or inspect the object after upload. R2 presigned URLs can bind the permitted `Content-Type`; configure bucket CORS narrowly for your application origin. [Presigned URL guidance](https://developers.cloudflare.com/r2/api/s3/presigned-urls/)

If page weight becomes important, add Cloudflare Images transformations on top of R2 for width limits and automatic WebP/AVIF. The first 5,000 unique transformations per month are currently free, then $0.50 per 1,000; repeated delivery of the same cached transformation does not create another unique transformation charge that month. [Cloudflare Images pricing](https://developers.cloudflare.com/images/pricing/)

### What I considered

| Option | Why I didn’t choose it |
|---|---|
| **AWS S3 + CloudFront** | Most mature and the natural choice if your infrastructure is already deeply AWS-based. It has more configuration and a more complicated bill for this small workload, including CDN request and regional transfer dimensions. CloudFront does include a substantial free allowance, so this is a close second—not a bad choice. [CloudFront pricing](https://aws.amazon.com/cloudfront/pricing/) |
| **Cloudflare Images alone** | The lowest-operations option: direct creator uploads, predefined variants, automatic optimization and cache invalidation. I would use it if your team wants a turnkey image service. R2 is cheaper and more portable when you primarily need original screenshots rather than extensive transformations. Cloudflare itself describes R2 plus Images as the more controllable, typically cost-effective arrangement. [Storage comparison](https://developers.cloudflare.com/images/get-started/introduction/) |
| **Cloudinary** | Excellent upload UI, transformations, moderation and asset management, but those are more capabilities—and more pricing complexity—than help-center screenshots usually justify. Its free plan may be sufficient initially, but migration becomes more involved because URLs and transformations are Cloudinary-specific. [Cloudinary pricing](https://cloudinary.com/pricing) |
| **Supabase Storage** | Attractive if you already use Supabase Auth and Postgres because access policies integrate neatly. Otherwise, its minimum production platform cost and metered cached egress make it less compelling as a standalone hot-image store. Pro currently starts at $25/month and includes 100 GB storage plus 250 GB cached egress. [Supabase pricing](https://supabase.com/pricing) |
| **Uploading to the Node server’s filesystem** | Poor fit for deployments, horizontal scaling, backups and CDN delivery. |
| **Storing images in the database** | Adds database load and backup volume while providing no delivery advantage. |

One decision could change my recommendation: if help articles are private or screenshots may contain customer data, do not expose the bucket as an unrestricted public custom domain. Serve them through an authenticated Worker or another authorization layer, strip image metadata, and define retention/deletion rules. Cloudflare notes that attaching a custom domain makes the R2 content publicly reachable unless additional access controls are applied. [R2 access considerations](https://developers.cloudflare.com/cache/interaction-cloudflare-products/r2/)

I’d use **Cloudflare R2 behind a Cloudflare-cached custom domain** such as `help-assets.example.com`.

It fits this workload unusually well: inexpensive object storage, S3-compatible Node tooling, globally cached delivery, and no bandwidth-egress charge. R2 Standard currently includes 10 GB storage, 1 million writes, and 10 million reads per month; beyond that, storage is $0.015/GB-month and reads are $0.36/million. [Cloudflare R2 pricing](https://developers.cloudflare.com/r2/pricing/)

For example, 25 GB of screenshots would cost roughly $0.23/month for storage beyond the free allowance, before request charges. The CDN should prevent most hot-image requests from reaching R2 at all.

### How I’d implement it

- Keep the bucket private for writes.
- Have Node authenticate the support agent, validate the filename/type/size, generate a random immutable object key, and return a short-lived presigned `PUT` URL.
- Upload from React directly to R2 rather than passing image bytes through the Node server. R2 supports this through the standard AWS JavaScript SDK. [Presigned URL documentation](https://developers.cloudflare.com/r2/api/s3/presigned-urls/)
- Serve published images through `help-assets.example.com`, because R2’s custom-domain path enables Cloudflare caching. [R2 custom-domain caching](https://developers.cloudflare.com/r2/buckets/public-buckets/)
- Set something like `Cache-Control: public, max-age=31536000, immutable` and create a new object key whenever an image changes.
- Restrict bucket CORS to your helpdesk origin, and allow only the headers and methods the uploader needs. [R2 CORS guidance](https://developers.cloudflare.com/r2/buckets/cors/)
- Validate the actual file signature after upload—not merely the browser-provided MIME type—and reject SVG unless you explicitly sanitize it.
- Store the object key, dimensions, checksum, uploader, and article association in your database.

If screenshots may contain private customer data, don’t publish them through a public cached hostname. Use a separate private bucket and authenticated or signed delivery; an unguessable URL is not access control.

### What I considered

**Amazon S3 + CloudFront**  
This is the conservative enterprise choice: mature permissions, excellent durability, and strong private-origin controls. CloudFront now has a free flat-rate tier offering 100 GB transfer, one million requests, and 5 GB of included S3 storage. [CloudFront pricing](https://aws.amazon.com/cloudfront/pricing/) I would choose it instead if you already operate heavily in AWS, need its compliance controls, or want one vendor and IAM system. Otherwise, it is more infrastructure and policy surface than this small workload needs.

**Cloudflare Images**  
This is attractive if automatic resizing, format conversion, and multiple variants are central. Its paid hosted-image pricing is $5 per 100,000 stored images plus $1 per 100,000 deliveries. R2-hosted images can also use Cloudflare transformations, with 5,000 unique transformations monthly on the free plan. [Cloudflare Images pricing](https://developers.cloudflare.com/images/pricing/) For ordinary inline screenshots, R2 alone is simpler; add transformations later if page weight becomes a problem.

**Backblaze B2 + Cloudflare**  
B2 has lower raw storage pricing—starting at $6.95/TB-month—and its Cloudflare integration avoids origin-transfer charges. [B2 pricing](https://www.backblaze.com/cloud-storage/pricing), [Cloudflare integration](https://www.backblaze.com/docs/cloud-storage-cloudflare-integrations) It is a good value option, but introduces a second vendor and extra origin/CDN configuration to save what will probably be pennies at your scale.

**Supabase Storage**  
Its authorization model and image transformations are pleasant if the application already uses Supabase. Production pricing starts at $25/month; Pro includes 100 GB storage and 250 GB cached egress. [Supabase pricing](https://supabase.com/pricing) I wouldn’t adopt the whole platform solely to host help-article screenshots.

My decision would therefore be **R2 Standard, direct presigned uploads, custom-domain CDN delivery, and immutable object keys**. The main reason to override that choice is organizational: if AWS or Supabase is already deeply established in your stack, reducing operational sprawl may be worth more than R2’s cleaner economics.

I’d use **Cloudflare R2 behind a Cloudflare-cached custom domain**.

It fits this workload unusually well: screenshots are simple objects, traffic is modest, repeated reads dominate, and R2 removes bandwidth-egress anxiety. R2 Standard currently includes 10 GB of storage, 1 million writes, and 10 million reads monthly; beyond that it costs $0.015/GB-month, with free internet egress. A custom domain enables Cloudflare’s edge cache, so hot screenshots are served close to readers without repeatedly hitting R2. [R2 pricing](https://developers.cloudflare.com/r2/pricing/) and [caching documentation](https://developers.cloudflare.com/r2/buckets/public-buckets/).

### How I’d implement it

- Keep the bucket non-public for management access, but expose the required objects through something like `help-images.example.com`.
- Have Node authenticate the support agent, authorize the article, and issue a short-lived presigned `PUT` URL. React uploads directly to R2, avoiding load on your application server. R2 uses the familiar AWS JavaScript SDK and S3 signing model. [Presigned URL documentation](https://developers.cloudflare.com/r2/api/s3/presigned-urls/)
- Generate immutable keys such as `articles/{articleId}/{uuid}.png`; don’t overwrite files in place.
- Serve them with a long cache lifetime, for example `Cache-Control: public, max-age=31536000, immutable`. Replacing an image creates a new key, which also avoids stale-cache problems.
- Accept only formats you actually need—probably PNG, JPEG, and WebP. Reject SVG unless you deliberately sanitize it, verify the real file signature rather than trusting `Content-Type`, and impose pixel-dimension and byte-size limits.
- Store the object key, dimensions, uploader, article ID, checksum, and accessibility text in your application database.
- Add a cleanup job for uploads that were created but never attached to an article.

One caveat: presigned upload URLs use R2’s S3 endpoint, not your delivery domain, so browser CORS must be configured for your helpdesk origin. Also, the delivery URL should not depend on the original filename; filenames leak information and complicate cache invalidation.

### What I considered

| Option | Why I didn’t choose it |
|---|---|
| **Cloudflare Images** | The easiest fully managed image product, including variants, optimization, and CDN delivery. It costs $5 per 100,000 stored images and $1 per 100,000 deliveries. Good if you need automatic thumbnails or AVIF/WebP variants, but screenshots in help articles usually need little transformation, so R2 is simpler and cheaper. You can add Images transformations over R2 later; the first 5,000 unique transformations per month are free. [Images pricing](https://developers.cloudflare.com/images/pricing/) |
| **Amazon S3 + CloudFront** | The conservative enterprise choice, with excellent controls and ecosystem support. But it means configuring two services, cache behavior, origin access, and more complicated pricing. I’d choose it if you are already deeply committed to AWS or require specific AWS compliance and audit integrations. [S3 pricing](https://aws.amazon.com/s3/pricing/) |
| **Cloudinary** | Best when image manipulation, asset search, editorial workflows, or a polished upload widget are central requirements. Its credit system meters storage, transformations, and bandwidth together, which is harder to predict and unnecessary for mostly unchanged screenshots. [Cloudinary plans](https://cloudinary.com/documentation/billing_and_plans) |
| **Supabase Storage** | Attractive if you already use Supabase Auth and row-level policies. It has a CDN, but cached and uncached egress are metered after plan quotas; current overage rates are $0.03/GB cached and $0.09/GB uncached. That is less attractive for hot images than R2’s free egress. [Supabase egress pricing](https://supabase.com/docs/guides/platform/manage-your-usage/egress) |
| **Backblaze B2 + Cloudflare** | Economical and credible, but adds a second vendor and integration boundary while arriving at essentially the same Cloudflare delivery setup. I’d use it for existing B2 estates, not a small greenfield feature. |

If the help articles are **private**, don’t expose the bucket directly as a public custom domain. Put a Worker in front of R2 to authorize requests, and design caching so authorization does not accidentally expose one customer’s screenshots to another. For public help articles, the direct cached-domain architecture is the choice I’d make this week.

I’d use **Cloudflare Images**.

It fits this workload unusually well: support agents can upload directly from the React client using one-time upload URLs, images are automatically delivered through Cloudflare’s CDN, and responsive variants can be generated without building your own image-processing service.

### Recommended design

1. React asks your Node API for an upload URL.
2. Node verifies the agent’s permission and requests a one-time Cloudflare upload URL.
3. React uploads directly to Cloudflare, keeping image bytes away from your application servers.
4. Store the returned image ID—not the complete delivery URL—against the help article.
5. Render a predefined variant such as `article`, plus a smaller `thumbnail` if needed.

Cloudflare’s Direct Creator Upload URLs expire and do not expose your API token. They can also carry private metadata such as your article or user ID. [Cloudflare upload documentation](https://developers.cloudflare.com/images/storage/upload-images/direct-creator-upload/)

### Why I’d choose it

- **Fast delivery:** CDN-backed image delivery without separately configuring an object store and CDN.
- **Minimal Node/React plumbing:** your server only authorizes uploads and records image IDs.
- **Responsive screenshots:** predefined variants avoid sending a 3–5 MB desktop screenshot to every mobile reader.
- **Predictable small-scale pricing:** currently $5 per 100,000 stored images per month and $1 per 100,000 delivered images. [Cloudflare Images pricing](https://developers.cloudflare.com/images/pricing/)
- **Private-content support:** images can require expiring signed URLs if draft or internal articles may contain customer information. [Cloudflare private-image documentation](https://developers.cloudflare.com/images/optimization/hosted-images/serve-private-images/)

For example, 5,000 screenshots and 500,000 image requests in a month would be roughly **$10/month** under the published unit pricing: one $5 storage unit plus five $1 delivery units.

### What I considered

| Option | Why it was considered | Why I wouldn’t start there |
|---|---|---|
| **Cloudflare R2 + Cloudflare CDN** | Extremely inexpensive storage, S3-compatible APIs, free egress, and 10 GB/10 million reads in the monthly free tier. [R2 pricing](https://developers.cloudflare.com/r2/pricing/) | You own more of the pipeline: validation, resizing, format conversion, cache behavior, cleanup, and possibly Workers. Best if original-file ownership or the lowest possible cost matters more than convenience. |
| **Amazon S3 + CloudFront** | Mature, durable, flexible, and often the default if everything already runs in AWS. AWS explicitly supports S3 as a CloudFront origin. [CloudFront documentation](https://s3.amazonaws.com/awsdocs/CF/latest/cf_dg.pdf) | More configuration and billing dimensions, while image transformations still need another component. I’d choose it if AWS consolidation, compliance controls, or portability were overriding requirements. |
| **Cloudinary** | Excellent upload widget, media library, CDN, transformations, and asset-management experience. Its free plan includes 25 monthly credits. [Cloudinary pricing](https://cloudinary.com/pricing) | The first meaningful paid tier is comparatively expensive, and its credit model mixes transformations, storage, and bandwidth. It becomes attractive if editors need a real DAM, sophisticated cropping, tagging, revision management, or broader video support. |
| **R2 alone** | Likely close to free for this traffic profile; it supports presigned browser uploads using the standard AWS JavaScript SDK. [R2 presigned URLs](https://developers.cloudflare.com/r2/api/s3/presigned-urls/) | Object storage alone does not provide the polished image lifecycle that Cloudflare Images does. |

### Things I’d settle before implementation

- Decide whether published screenshots are public while drafts remain signed/private.
- Limit file size and pixel dimensions; accept only decoded PNG, JPEG, or WebP—not merely a claimed MIME type.
- Strip EXIF metadata, because screenshots and uploaded photos can contain identifying information.
- Use opaque generated image IDs rather than filenames supplied by users.
- Track upload ownership and status in your database.
- Delete abandoned uploads and define what happens when an article or image is replaced.
- Use immutable URLs plus long-lived cache headers for published versions.
- Keep the original screenshot available for zooming, but embed a width-limited optimized variant.

The main reason I would change this recommendation is if screenshots are merely the first file type and you expect PDFs, logs, ZIPs, or arbitrary attachments soon. In that case, I’d choose **R2 as the underlying attachment store**, place it behind a custom Cloudflare domain and cache, and add Cloudflare image transformations only for supported images.

I’d use **Cloudflare R2 Standard behind a Cloudflare custom domain/CDN**.

It fits this workload particularly well: screenshots occupy little storage, while repeated viewing makes delivery bandwidth and caching more important. R2 has S3-compatible APIs, free internet egress, and Cloudflare can cache the files globally when the bucket is connected to a custom domain. Current pricing includes 10 GB storage, 1 million writes, and 10 million reads monthly; beyond that, Standard storage is $0.015/GB-month and reads are $0.36/million. [R2 pricing](https://developers.cloudflare.com/r2/pricing/) [R2 caching](https://developers.cloudflare.com/cache/interaction-cloudflare-products/r2/)

For example, 20 GB of screenshots would cost roughly **$0.15/month for storage after the free allowance**, before any billable operations. Bandwidth remains free. Use Standard—not Infrequent Access—because these are hot objects.

### How I’d implement it

- Keep the bucket writable only through your Node backend.
- Have Node generate short-lived presigned `PUT` URLs using `@aws-sdk/client-s3`; React uploads directly to R2 without sending image bytes through your application server. R2 supports presigned URLs for up to seven days. [Presigned URL documentation](https://developers.cloudflare.com/r2/api/s3/presigned-urls/)
- Serve images from something like `https://help-images.example.com/<random-id>.webp`, using the custom domain—not the development `r2.dev` endpoint, which is not intended for production caching. [Public bucket documentation](https://developers.cloudflare.com/r2/buckets/public-buckets/)
- Use immutable object names, such as a UUID or content hash, and send `Cache-Control: public, max-age=31536000, immutable`.
- Validate MIME type, extension, decoded dimensions, and file size server-side. Generate the object key yourself; never accept an arbitrary bucket path from React.
- Store the object key, dimensions, alt text, uploader, and article association in your database.
- If useful, add WebP/AVIF and width variants later. Cloudflare currently includes 5,000 unique image transformations monthly and charges $0.50 per additional 1,000 on the paid Images plan. [Cloudflare Images pricing](https://developers.cloudflare.com/images/pricing/)

One subtlety: **presigned uploads use R2’s S3 API hostname, not your custom domain**. Public reads use the custom domain so they receive CDN caching.

### What I considered

| Provider | Why I didn’t choose it here |
|---|---|
| **Cloudinary** | Best option if your real requirement is a full media platform: polished upload widget, media library, automatic resizing, moderation, and extensive transformations. But its credit-based pricing and tighter platform coupling feel unnecessary for ordinary help-center screenshots. Its free plan has 25 monthly credits, shared across storage, bandwidth, and transformations. [Cloudinary pricing](https://cloudinary.com/pricing) |
| **Amazon S3 + CloudFront** | Excellent default if you already operate heavily in AWS or require its IAM, audit, compliance, and replication ecosystem. It introduces more configuration and billing dimensions than R2 for this small workload, although CloudFront now offers bundled plans, including a free allowance with 5 GB of S3 storage, 100 GB transfer, and 1 million requests. [CloudFront pricing](https://aws.amazon.com/cloudfront/pricing/) |
| **Backblaze B2 + CDN** | Very inexpensive storage—currently $6.95/TB-month, with the first 10 GB free—and good S3 compatibility. But pairing it with Cloudflare or another CDN creates a two-provider setup when R2 already combines both parts. [B2 pricing](https://www.backblaze.com/cloud-storage/pricing) |
| **Bunny Storage + Bunny CDN** | A credible simple, inexpensive alternative, especially if most readers are in Europe or North America. CDN delivery there starts at $0.01/GB with a $1 monthly minimum. R2 wins for this case because egress is free and its S3/Node integration is straightforward. [Bunny CDN pricing](https://bunny.net/pricing/cdn/) |
| **Vercel Blob** | Probably the quickest integration if the React application is already hosted on Vercel. However, storage is $0.023/GB and public delivery is billed at $0.05/GB before included allowances, so hot images make it less attractive. [Vercel Blob pricing](https://vercel.com/docs/vercel-blob/usage-and-pricing) |

The main decision that could change my recommendation is privacy. If these screenshots appear in **public help articles**, R2 plus a public cached domain is ideal. If they contain customer data or must inherit article-level authorization, keep the bucket private and serve authorized, short-lived URLs or an authenticated Worker; public CDN URLs should never be treated as access control. Also enable versioning or maintain a second backup if accidental deletion would be costly—R2’s eleven-nines durability does not protect against someone deleting the object. [R2 durability](https://developers.cloudflare.com/r2/reference/durability/)

I’d use **Cloudflare R2 behind a Cloudflare custom domain** such as `help-assets.example.com`.

It fits this workload unusually well:

- Screenshots are ordinary immutable objects; you probably don’t need a full media-management platform.
- R2 is S3-compatible, so your Node backend can use the AWS JavaScript SDK.
- Cloudflare’s edge cache serves hot images close to readers, avoiding repeated storage reads. A custom domain is required for production caching; `r2.dev` is development-only. [Cloudflare caching documentation](https://developers.cloudflare.com/cache/interaction-cloudflare-products/r2/)
- Internet egress from R2 is free. Standard storage is currently $0.015/GB-month, with a monthly free tier of 10 GB, 1 million writes, and 10 million reads. [R2 pricing](https://developers.cloudflare.com/r2/pricing/)

For example, 20 GB of screenshots with upload and origin-read counts inside the free allowances would cost roughly **$0.15/month**, regardless of how much cached image bandwidth users consume.

### Architecture I’d ship

1. React asks your authenticated Node API for an upload URL.
2. Node verifies that the user is a support agent and creates an unpredictable, versioned key such as `articles/{articleId}/{uuid}.png`.
3. Node returns a short-lived presigned `PUT` URL.
4. React uploads directly to R2, keeping image bytes away from your application server.
5. The article stores the permanent URL: `https://help-assets.example.com/...`.

R2 supports presigned uploads through the standard AWS SDK and allows the signature to restrict the expected content type. [Presigned URL documentation](https://developers.cloudflare.com/r2/api/s3/presigned-urls/) Cloudflare also documents this direct-upload pattern specifically for user-generated content. [Reference architecture](https://developers.cloudflare.com/reference-architecture/diagrams/storage/storing-user-generated-content/)

Set long-lived caching on immutable keys, for example:

```http
Cache-Control: public, max-age=31536000, immutable
```

Never overwrite a published key—create a new key when replacing an image. Otherwise, edge caches can continue serving the previous object until expiry or purge. [R2 consistency notes](https://developers.cloudflare.com/r2/reference/consistency/)

### What I considered

| Option | Why I didn’t choose it |
|---|---|
| **Cloudflare Images** | The best alternative if you need automatic WebP/AVIF conversion, resizing, crops, or a polished upload API. It has direct creator uploads and predefined variants, but screenshots displayed mostly at original size do not justify another image-specific abstraction and per-delivery pricing. Cloudflare itself describes R2 plus optional transformations as the more cost-effective, controllable route. [Cloudflare Images guidance](https://developers.cloudflare.com/images/get-started/introduction/) |
| **Cloudinary** | Excellent image workflow, media library, transformations, and CDN. Its free plan includes 25 monthly credits, but paid service currently starts at $249/month monthly; bandwidth, storage, and transformations all consume credits. That is hard to justify for straightforward help-center screenshots. [Cloudinary pricing](https://cloudinary.com/pricing) |
| **Amazon S3 + CloudFront** | Mature, dependable, and the conservative choice if you already operate heavily in AWS or require AWS-specific governance. It adds more configuration and a more complicated request/CDN pricing model without providing a clear benefit for this small workload. S3 also supports the same direct presigned-upload pattern. [AWS presigned URLs](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html) |
| **Storing images in your app/database** | Increases deploy size, database backup volume, application bandwidth, and coupling. It also makes CDN caching and lifecycle management unnecessarily awkward. |

Before launch, I would enforce file-size limits, decode and verify that uploads are real PNG/JPEG/WebP images rather than trusting MIME type alone, reject or sanitize SVG, strip sensitive EXIF metadata, configure restrictive CORS, and keep the bucket’s `r2.dev` endpoint disabled. If articles are private, do not expose a public bucket directly—put authorization in a Worker or use signed delivery instead.

I’d use **Cloudflare R2 behind a Cloudflare custom domain/CDN**.

For a small upload workload with frequently viewed images, it hits the right balance: very low cost, fast cached delivery, S3-compatible Node tooling, and little infrastructure to operate.

### Why R2

- **Hot images don’t create bandwidth anxiety.** R2 charges no Internet egress fees. Standard storage is $0.015/GB-month, with 10 GB storage, 1 million writes, and 10 million reads included monthly. For example, 50 GB stored with fewer than 10 million origin reads would be roughly **$0.60/month**, before optional services. [R2 pricing](https://developers.cloudflare.com/r2/pricing/)
- **Delivery is straightforward.** Attach something like `help-images.example.com` to the bucket, set appropriate cache headers, and Cloudflare serves cached images from its edge network. The `r2.dev` development URL is not CDN-cached, so the custom domain matters. [R2 caching documentation](https://developers.cloudflare.com/cache/interaction-cloudflare-products/r2/)
- **Node integration is familiar.** R2 supports the AWS S3 SDK and presigned `PUT` URLs, allowing React to upload directly without passing image bytes through the Node server. URLs can be restricted by object, operation, expiry, and content type. [Presigned URL documentation](https://developers.cloudflare.com/r2/api/s3/presigned-urls/)
- **The storage characteristics are appropriate.** R2 documents strong consistency and eleven-nines annual durability. [Consistency](https://developers.cloudflare.com/r2/reference/consistency/) and [durability](https://developers.cloudflare.com/r2/reference/durability/)

I’d implement this flow:

1. An authenticated support agent asks the Node API for an upload URL.
2. The API generates a random, immutable key such as `articles/{articleId}/{uuid}.png` and a short-lived presigned `PUT`.
3. React uploads directly to R2.
4. The backend validates the completed object—actual file signature, size and permitted format—and records its URL in the article.
5. Published images use `Cache-Control: public, max-age=31536000, immutable`.
6. Replacing an image creates a new key rather than overwriting the old one, avoiding stale CDN content.

Screenshots can inadvertently contain credentials or customer data, so I would also enforce authentication, a conservative size limit, PNG/JPEG/WebP-only validation, and deletion/audit tooling. If articles are private, I would **not** expose the bucket directly: reads should go through a Cloudflare Worker or another authorization layer. A custom-domain R2 bucket is otherwise publicly readable, and cached deletions or overwrites require cache purging.

### What I considered

| Option | Why consider it | Why I wouldn’t choose it here |
|---|---|---|
| **AWS S3 + CloudFront** | Most mature ecosystem, strong IAM, excellent choice if everything already runs in AWS | More configuration and pricing surface for a small asset service. I’d choose it instead if AWS consolidation, compliance controls, or existing Terraform/operations outweigh simplicity. |
| **Cloudinary** | Upload widget, CDN, asset management, automatic resizing and format conversion | Excellent product, but more platform and expense than ordinary help-article screenshots need. Its free plan provides 25 monthly credits; storage, bandwidth, and transformations all consume credits, while the listed paid plan starts at $249/month monthly. [Cloudinary pricing](https://cloudinary.com/pricing) |
| **Uploadcare** | Polished uploader, CDN, malware filtering, responsive images and transformations | Attractive if you want a finished media workflow, but its production Pro plan is listed at $66/month and pricing includes operations plus CDN traffic. [Uploadcare pricing](https://uploadcare.com/pricing/) |
| **Store files in the application/database** | Initially simple | Poor caching and backup behavior, larger deployments, and unnecessary application-server bandwidth. |
| **Cloudflare Images** | Automatic resizing, WebP/AVIF and edge transformations | Worth adding only if responsive variants become useful. R2 can remain the source; Cloudflare currently includes 5,000 unique transformations monthly, then charges $0.50 per 1,000. [Cloudflare Images pricing](https://developers.cloudflare.com/images/pricing/) |

The main exception to my R2 recommendation is organizational: if your application is already deeply established in AWS, I would accept the modest extra complexity and use **S3 + CloudFront** to avoid introducing another critical vendor. Otherwise, R2 is the cleaner choice for this particular workload.

I’d use **Cloudflare R2 behind a Cloudflare custom domain/CDN**.

It fits this workload unusually well: inexpensive S3-compatible storage, direct uploads from React, fast cached delivery, and no bandwidth-egress charge—the part that can become disproportionately expensive when a small collection of screenshots is viewed repeatedly.

As of September 2026, R2 Standard includes 10 GB of storage, 1 million writes, and 10 million reads monthly; beyond that, storage is $0.015/GB-month, with free Internet egress. Your workload will probably stay near $0 or a few dollars per month. [R2 pricing](https://developers.cloudflare.com/r2/pricing/)

### How I’d implement it

- Keep the R2 bucket private for writes.
- Have Node authenticate the agent, validate filename/type/size, generate a short-lived presigned `PUT` URL, and record the resulting object key.
- Upload directly from React to R2 so screenshots do not pass through your Node server.
- Serve through `assets.yourdomain.com`, not the development `r2.dev` address. A custom domain enables Cloudflare edge caching, WAF, cache rules, and tiered caching. [Caching R2 objects](https://developers.cloudflare.com/cache/interaction-cloudflare-products/r2/)
- Use immutable keys such as `articles/{articleId}/{uuid}.png`, rather than overwriting files. Return `Cache-Control: public, max-age=31536000, immutable`.
- Restrict CORS to your application origins and allow only the headers and methods the uploader needs. [R2 browser-upload CORS](https://developers.cloudflare.com/r2/buckets/cors/)
- Enforce limits server-side: image MIME allowlist, roughly 10–20 MB maximum, randomized keys, and ideally malware/content scanning before publication.
- Store the object key—not the complete provider URL—in your database. That preserves an easy migration path.

One R2 quirk worth knowing: presigned URLs use the S3 API hostname, not your custom delivery domain. That is fine—upload through the presigned S3 endpoint and display through `assets.yourdomain.com`. [R2 presigned URLs](https://developers.cloudflare.com/r2/api/s3/presigned-urls/)

If your helpdesk data must remain in Europe, create the bucket with the EU jurisdiction at the beginning; jurisdiction cannot subsequently be changed. [R2 data location](https://developers.cloudflare.com/r2/reference/data-location/)

### What I considered

| Option | Why I didn’t choose it first |
|---|---|
| **AWS S3 + CloudFront** | The conservative enterprise choice: mature, extremely capable, and especially sensible if the rest of your infrastructure is already AWS. It has more configuration and billing dimensions than this modest workload needs. I would choose it instead if AWS consolidation, IAM governance, audit tooling, or organizational familiarity outweigh simplicity. |
| **Cloudinary** | Best if automatic resizing, format conversion, cropping, asset search, revision management, or a polished media UI are real requirements. For merely attaching and displaying screenshots, it is more product and potentially more cost than necessary: paid plans begin at $99/month, while the free plan uses a shared 25-credit allowance across storage, transformations, and bandwidth. [Cloudinary pricing](https://cloudinary.com/pricing) |
| **Cloudflare Images** | Attractive if you later want automatic AVIF/WebP conversion or responsive variants. For now I would retain originals in R2 and add Images transformations only when required. Cloudflare itself describes R2 plus optional transformations as the more controllable, typically cost-effective path. The free transformation tier currently covers 5,000 unique transformations monthly. [Images pricing](https://developers.cloudflare.com/images/pricing/) |
| **Backblaze B2 + CDN** | Excellent raw-storage economics—$6.95/TB-month, 10 GB free, and generous egress terms—but it introduces a separate CDN relationship or a less unified delivery setup. It becomes compelling when stored volume is large relative to traffic. [B2 pricing](https://www.backblaze.com/cloud-storage/pricing) |
| **Storing images in the app/database** | Operationally easy at first, but it bloats backups, consumes application bandwidth, scales poorly, and makes CDN caching and independent retention harder. |

The main decision that could change my recommendation is access control. If these help articles are public, public cached image URLs are ideal. If articles contain customer-sensitive screenshots, don’t expose the bucket as an unrestricted public origin: use an authenticated Worker or another signed-delivery layer, and establish deletion, retention, and redaction rules. CDN-cached URLs should never be treated as authorization merely because their names are difficult to guess.

I’d use **Cloudflare R2 Standard behind a Cloudflare-cached custom domain**.

It fits this workload particularly well: inexpensive object storage, S3-compatible Node tooling, direct browser uploads, global CDN delivery, and no internet-egress charge. R2 currently includes 10 GB of storage, 1 million writes, and 10 million reads per month; beyond that, Standard storage is $0.015/GB-month and reads are $0.36/million. [Cloudflare R2 pricing](https://developers.cloudflare.com/r2/pricing/)

### Recommended design

1. React requests an upload from your Node API.
2. Node verifies that the agent may upload and generates a random, immutable object key and a short-lived presigned `PUT`.
3. React uploads directly to R2, keeping image bytes away from your Node servers.
4. Store the object key, dimensions, size, checksum, and article relationship in your database.
5. Serve it through something like `help-images.example.com`, with long-lived caching for immutable keys.

R2 supports presigned uploads using the standard AWS JavaScript SDK. Restrict the signed request’s content type and configure bucket CORS for only your helpdesk origin. [Presigned URL documentation](https://developers.cloudflare.com/r2/api/s3/presigned-urls/) A custom domain activates Cloudflare caching and its related controls; the `r2.dev` address is intended for development rather than production. [Public bucket documentation](https://developers.cloudflare.com/r2/buckets/public-buckets/)

Still validate the decoded image—not merely its filename or browser-provided MIME type—and cap dimensions and file size. Use UUID/content-hash filenames rather than permitting overwrites. Screenshots can contain secrets, so deletion and retention controls matter too.

### What I considered

| Option | Why I didn’t select it |
|---|---|
| **Cloudflare Images** | Excellent if you need automatic WebP/AVIF conversion, resizing, cropping, or many thumbnail variants. For mostly unchanged screenshots, R2 is simpler and more portable. You can add Cloudflare image transformations later; 5,000 unique transformations per month are currently free. [Images pricing](https://developers.cloudflare.com/images/pricing/) |
| **Cloudinary** | The strongest managed image pipeline and asset-management experience. It includes upload tooling, transformations, and CDN delivery, but introduces its credit-based pricing and greater vendor coupling. I’d choose it if non-engineers need a media library or you expect substantial image manipulation. [Cloudinary pricing](https://cloudinary.com/pricing) |
| **S3 + CloudFront** | Mature, highly configurable, and the natural answer if you already operate heavily in AWS. For this small workload it means more configuration and billing surface. CloudFront does now offer flat-rate plans, including a free plan with 5 GB S3 storage, 1 million requests, and 100 GB transfer. [CloudFront pricing](https://aws.amazon.com/cloudfront/pricing/) |
| **Vercel Blob** | Very convenient if the application already lives entirely on Vercel, but delivery is metered: current listed rates start around $0.023/GB-month for storage and $0.05/GB transferred, plus platform CDN metrics. [Vercel Blob pricing](https://vercel.com/docs/vercel-blob/usage-and-pricing) |
| **Storing images in the database or Node filesystem** | Poor caching and backup behavior, larger database operations, and problems when Node instances scale or redeploy. |

One important exception: if help articles are private or customer-specific, do **not** expose the bucket as a generally public CDN origin. Keep R2 private and authorize reads through a Worker or another signed-delivery layer. If the articles are public or all authenticated users may see every image, R2 plus a cached custom domain is the option I’d settle on this week.

Postawiłbym na **Cloudflare R2 + cache na Cloudflare edge** (ewentualnie Cloudflare Images, jeśli kiedyś dojdzie potrzeba automatycznych wariantów/resize). S3-kompatybilne API, więc integracja z Node przez `aws-sdk` jest banalna, zero opłat za egress, a skoro obrazki są "gorące", to i tak trafiają do edge cache CDN i serwują się szybko bez dodatkowej konfiguracji. Główny kompromis: mniej dojrzały ekosystem i słabszy model uprawnień niż w AWS.

Co jeszcze rozważałem i odrzuciłem:
- **S3 + CloudFront** - branżowy standard, ale przy tak małym ruchu to więcej roboty (osobna dystrybucja CloudFront, invalidacje cache) za podobny efekt końcowy.
- **Cloudinary / imgix** - mocne w transformacje obrazków na żądanie, ale to zrzuty ekranu do artykułów pomocy, nie resize/crop w locie - płacilibyście za funkcje, których nie użyjecie.
- **Supabase Storage / Vercel Blob** - sensowne tylko jeśli już siedzicie w tym ekosystemie; jeśli nie, to kolejny provider bez wyraźnej korzyści.

Jeśli wolisz zostać w AWS (np. ze względu na resztę infry), S3 + CloudFront też jest w porządku - to bardziej pytanie o to, ile configu chcesz ogarniać w tym tygodniu.

**Cloudflare R2.** Storage kompatybilny z S3, ale bez opłat za egress, plus CDN na krawędzi w cenie. Przy małym ruchu, ale "gorących" (często odczytywanych) obrazkach to jest właśnie ten koszt, który przy S3 rośnie bez sensu, a integracja z Node/React to zwykłe `@aws-sdk/client-s3` ze zmienionym endpointem, więc mieścisz się w tydzień.

Co odrzuciłem po drodze:
- **S3 + CloudFront** - dojrzały standard, ale egress + osobna konfiguracja CDN to więcej ruchomych części niż trzeba na start, a przy hot images koszt egress realnie boli.
- **Cloudinary/imgix** - mocne w transformacje obrazów w locie, ale to kolejny vendor i wyższa cena za funkcję, której nie potrzebujesz (to są screenshoty do artykułów, nie galeria wymagająca resize/crop na żądanie).
- **Uploadthing/Vercel Blob** - najszybszy start pod względem DX, ale mocniejszy lock-in i mniej kontroli, gdyby treści pomocy miały żyć długo.
- **Supabase Storage/DO Spaces** - też S3-compatible i sensowne, ale bez przewagi zerowego egressu R2, więc nie widziałem powodu, żeby wybrać je zamiast niego.

Główny kompromis: R2 ma uboższy ekosystem transformacji obrazów niż Cloudinary, ale dla zrzutów ekranu to nieistotne, a jakby kiedyś zaszła potrzeba, można dołożyć Cloudflare Images na tym samym buckecie.

Chcesz, żebym spiął to z konkretnym uploadem w Node (presigned URL + endpoint) czy to na razie tylko decyzja do zapisania?

Wybrałbym **Cloudflare R2** za backend uploadów, serwowany przez Cloudflare CDN. Powód: S3-kompatybilne API (ten sam SDK `@aws-sdk/client-s3` w Node), zero opłat za egress więc "gorące" obrazy nie generują kosztu przy każdym odczycie, a cache na edge daje szybkie serwowanie bez dodatkowej konfiguracji CDN.

Rozważałem jeszcze: S3 + CloudFront (branżowy standard, ale przy tym ruchu to głównie dodatkowa konfiguracja dystrybucji i koszt egress bez realnej korzyści), Vercel Blob (najprostszy start, jeśli już hostujecie na Vercelu, ale droższy przy wzroście i lock-in), oraz zapis na dysku serwera (odpadło od razu, brak CDN i skalowania, ryzyko przy redeployu).

Wziąłbym **Cloudflare R2** (S3-compatible storage, zero opłat za egress) w parze z ich CDN-em/cache do serwowania - przy małym ruchu ale "hot" plikach liczy się głównie brak kosztów transferu i szybki cache na brzegu, a integracja z Node przez zwykłe S3 SDK jest banalna. Rozważałem też S3+CloudFront (ten sam model, ale egress kosztuje i trzeba samemu spinać CDN), Cloudinary (świetny gdy potrzebujesz transformacji obrazków w locie, ale to nadmiarowa złożoność i koszt dla zwykłych screenshotów) oraz Vercel Blob/Uploadthing (najszybszy start, ale słabsza kontrola i wyższy koszt przy skalowaniu).

Główny tradeoff: R2 nie ma wbudowanej optymalizacji/resize obrazków jak Cloudinary - jeśli support agenci wrzucają duże, nieoptymalizowane screeny, będziesz to musiał obsłużyć sam (np. prostym resize przy uploadzie). Pasuje to do Waszego stacku i skali?

Dla tego przypadku (małe screenshoty, mały ruch, ale "hot" czyli częste odczyty) postawiłbym na **Cloudflare R2 + cache na edge'u Cloudflare** - zero opłat za egress, API kompatybilne z S3 (działa ze standardowym `aws-sdk` w Node), a "hot" odczyty obsługuje właśnie edge cache, nie sam storage. Jeśli macie już konto AWS albo Cloudflare, to naturalnie przeważa wybór w tamtą stronę.

Co jeszcze brałem pod uwagę i czemu odpadło:
- **S3 + CloudFront** - dojrzały, dobrze udokumentowany, ale więcej configu (IAM, dystrybucja CloudFront) i opłaty za egress, które przy R2 są zerowe. Jeśli już żyjecie w AWS, i tak jest to solidny wybór.
- **Cloudinary / imgix** - świetne gdy potrzebujesz transformacji obrazków w locie (resize, webp), ale dla zwykłych screenshotów w artykułach pomocy to dodatkowa usługa i koszt bez realnej korzyści.
- **UploadThing** - wygodny DX pod Node/React, ale mniejszy, młodszy dostawca - ryzykowne przy małym zespole bez potrzeby tej wygody.
- **Lokalny dysk / wolumen na serwerze** - odpada od razu: brak trwałości przy restarcie/skalowaniu i brak CDN pod "hot" ruch.

Jedno pytanie zanim zamkniesz temat: czy macie już konto AWS albo Cloudflare w firmie? To rozstrzygnie między R2 a S3+CloudFront, bo funkcjonalnie są niemal równoważne.