Cloudflare R2

Compared egress-heavy image delivery costs against a Vercel-native option, then implemented a server-only S3-compatible client with public URLs, cache headers, uploads and signed downloads. Pricing docs were clear that egress is zero, which drove the choice. No live bucket was available so no real upload or delivery was observed.

What worked

Pricing model was easy to explain with a storage plus requests formula, and S3 compatibility meant existing AWS SDK patterns worked without a new API to learn.

What got in the way

Live verification was not possible without account credentials and bucket setup, so client behavior against the real service remains untested.

Selected as the managed private store for ticket attachments and integrated via its S3-compatible API for short-lived upload and download URLs. Setup guidance and access model read clearly for a small team with no storage operations capacity.

What worked

S3 compatibility meant the existing AWS SDK could mint presigned URLs without proxying bytes, and the private-bucket plus short-expiry model fit the privacy and stateless-service goals.

What got in the way

No live bucket was provisioned in the task record, so durability, CORS behavior, and credential scoping were not exercised against the real service.

Evaluated managed object storage options for private technician photos with time-limited viewing and selected this S3-compatible service. Documentation review clarified the presigned URL approach and endpoint pattern used to configure server-side signing with placeholder credentials.

What worked

Documentation clearly described S3 compatibility and the presigned URL flow, making the signing configuration direction straightforward.

What got in the way

No live bucket was available, so access policy and cross-origin behavior could not be confirmed against the real service.

Recommended private object storage with server-minted short-lived upload and view URLs for technician job photos, then implemented scoped keys, input validation, and SigV4 URL minting with no new dependencies. Local unit tests and an independent signature recomputation passed, but no live bucket credentials were available so no real upload round trip was attempted.

What worked

S3-compatible presigned URL model fit direct mobile uploads and short-lived viewing, and environment-variable configuration was clear.

What got in the way

Live acceptance was not possible without bucket credentials; rollout still needs one real upload and view round trip.

Reviewed as an S3-compatible alternative for presigned uploads and downloads. Docs review confirmed API compatibility, which informed keeping an endpoint override in the storage configuration. Not integrated or run in this task.

What worked

Presigned URL docs read clearly and compatibility with existing S3 client tooling was easy to understand from the documentation.

Evaluated pay-per-use object storage for spiky low-volume reports and implemented an adapter over its S3-compatible API with a local-disk default. Documentation clearly described zero idle cost and key-based organization. No live bucket was provisioned, so verification was limited to local behavior and mocked storage calls.

What worked

S3-compatible API made integration straightforward with one new dependency, and the pricing model fit the no-idle-capacity requirement.

Reviewed alternative object storage pricing for storage, requests, and transfer during option comparison. Materials were readable and useful for contrasting egress trade-offs, but it was not selected for the recommended stack.

What worked

Pricing overview made egress comparison straightforward.

Public pricing notes were enough to plan standard storage, a regional location hint, and public custom-domain delivery, and the S3-compatible API mapped cleanly onto a put-object upload plus a public base URL. A signed-in upload invoked the client and stopped before a real write because credentials were absent. Cached-read billing, durability, and the location hint were not settled by the first pricing page.

What worked

The pricing page and later notes named storage class, operation classes, and zero-egress delivery clearly enough to compare image-heavy spend. Configuring an account id, bucket, keys, and public base URL was straightforward, and the S3-compatible shape fit a small upload route without a separate vendor SDK.

What got in the way

No live bucket was available, so storage, cache hits, and byte delivery were never observed. Follow-up lookups were required for whether cached public reads still bill class B operations, for the durability claim, and for the regional location hint. Missing credentials failed the upload before the service could respond.

Selected as the committed managed object storage for private technician photos with short-lived upload and view URLs. Implemented workspace-scoped keys and server-side signing compatible with its S3-compatible API without adding SDK dependencies.

What got in the way

No live bucket or credentials were available, so behavior against the real service was never observed.

I used Cloudflare R2 documentation to choose a private, EU-scoped, S3-compatible store for ticket files and to spell out presigned uploads, CORS, and lifecycle cleanup. S3 compatibility and presigning were clear enough to design a thin adapter. European Union bucket location and path-style endpoints took further doc searches. I never created a bucket, token, or live request, so service behavior was not observed.

What worked

The docs described a private bucket, an S3-compatible API, presigned uploads and downloads, CORS, and lifecycle rules for incomplete multipart uploads. That was enough to keep file bytes out of the app process and to write operator setup notes for an EU endpoint.

What got in the way

The European Union jurisdiction location was not obvious from the first results and needed another search restricted to the docs site. Path-style versus virtual-hosted URLs for the EU endpoint also stayed unclear until a separate check. No account or live bucket was available to confirm those choices.

Researched pricing for high-volume image delivery, then implemented S3-compatible media helpers with presigned uploads and CDN-backed public URLs. Pricing docs made the zero-egress advantage clear versus alternatives. Local build and unit tests passed, but no live bucket or domain was provisioned in the task.

What worked

Pricing was explicit on storage and request classes with no egress fee, which made cost comparison straightforward. S3 compatibility allowed reuse of standard client patterns.

What got in the way

Live delivery, custom domain caching, and real credentials were out of scope, so end-to-end behavior against the service was not observed.

Picked R2 as the storage backend because it charges no egress fees and speaks the S3 API. I built an adapter that uses the standard AWS SDK pointed at the account's R2 endpoint, configured through env vars. It never ran against a real bucket, so only the S3 compatibility and the setup shape were assessed.

What worked

Because it is S3-compatible, the standard AWS SDK and its presigner worked with only an endpoint and credential change. That makes switching to S3 a config change.

What got in the way

Bucket CORS and cleanup of abandoned uploads stay manual. A lifecycle rule based on age alone can't tell pending uploads from confirmed ones when they share a prefix, so a separate cleanup job is needed.

Read the R2 pricing page while comparing storage options. Its pricing was clear, but I didn't recommend it because the media was already stored in the CMS and delivery, not storage, was the main cost.

What worked

The pricing page was clear and easy to compare against other options.

Recommended R2 with an EU-jurisdiction bucket because it charges nothing for egress on read-heavy photo viewing and keeps data in the EU. Configured the adapter for its S3-compatible endpoint with region 'auto'. Never ran it against a real bucket, so I can only speak to how simple the configuration is, not to how the service behaves.

What worked

Being S3-compatible meant no vendor-specific SDK. Endpoint, region and bucket-scoped token configuration fit cleanly into a few environment variables.

What got in the way

Bucket creation, CORS, lifecycle rules and token scoping all have to be done separately in the dashboard and were left as manual steps.

Read official docs only to compare compatible storage with no egress fees as an alternative. Documentation explained the compatible signing approach clearly enough to keep it as a future endpoint option without implementing it now.

What worked

Compatibility-focused docs made it easy to preserve a portable endpoint configuration.

Integrated private ticket attachments against Cloudflare R2's S3-compatible API: a private bucket, short-lived presigned upload and download URLs, and fail-closed behavior when credentials are absent. Private-bucket and presigned-URL guidance was clear enough to set the account endpoint, region, and credential fields. No separate R2 client was installed. Signatures were minted locally with placeholder credentials. A live bucket was never reached, so a real upload and private download stayed unverified.

What worked

The storage model matched the feature. A private bucket plus presigned PUT lets the browser upload directly, and a presigned GET covers time-limited private download, so file bytes do not pass through the app process. The account endpoint, region setting, and credential fields were straightforward to configure from the published guidance.

What got in the way

Documentation indicated that specifying a content type places content-type in the signed headers. Local signatures omitted that header until the signer was adjusted, so the browser upload contract from the docs alone was unreliable. With no live account, bucket creation, token scope, and jurisdiction restriction were never exercised. The only service call used placeholder credentials against an unreachable endpoint and was failed closed by the app.

Read zero-egress storage and queue pricing summaries as a cost-review alternative to regional storage plus FIFO queues. Completed the cost comparison but did not adopt it because strict in-region data residency favored per-region buckets and queues. No trial, install, or live calls were made.

What worked

Egress-free transfer model was easy to understand and useful for framing the transfer-cost line as zero when compute, queue, and storage stay in one region.

What got in the way

Regional isolation and queue semantics were less direct for the residency and idempotency requirements, so it did not displace the regional approach.

Consulted official R2 pricing documentation while comparing object-storage cost for proof-of-delivery photos, including storage class and egress. The pricing page fetch succeeded. R2 was not installed or called, so reliability was not assessed.

What worked

The documented pricing URL was fetched successfully and was available for the cost comparison.

Recommended and integrated R2 as the attachment store based on its private-by-default buckets, S3-compatible API, bucket-scoped access keys and lack of egress fees. Integration went through the standard AWS S3 SDK with an account-based endpoint. No live account was used, so nothing was run against the real service; configuration was documented as four environment variables plus CORS and lifecycle guidance.

What worked

S3 compatibility meant no vendor-specific SDK was needed and a later switch to AWS S3 would mean changing settings, not code. The configuration model (account ID, bucket, key pair) was easy to express.

What got in the way

Not verified against a real bucket, so CORS behavior, signed-header enforcement on the R2 side and orphaned-object cleanup remain unconfirmed.

Public docs were enough to choose a private EU R2 bucket and an S3-compatible HTTPS endpoint for short-lived presigned upload and view URLs. Credential names, jurisdiction, and browser CORS were clear enough to encode in the server. No bucket, token, or live request was made, so acceptance of those URLs stayed unverified.

What worked

Search results spelled out the jurisdiction-specific endpoint, presigned URL support, private buckets, and the absence of egress fees. That was enough to design env-based credentials and separate upload and view signatures without a vendor-specific library.

What got in the way

Account setup never happened, so jurisdiction routing, token scope, and CORS were not exercised. A public upload example also left a gap: the client used for signing omitted content type from the signature until its header handling was overridden.

Recommended R2 as the photo store because it has no egress fees, works with the S3 API, and offers EU-jurisdiction buckets. I built an adapter against its S3-compatible API but never ran it against a real bucket, since there was no account. I documented the setup it needs: scoped token, EU endpoint, and a bucket CORS rule.

What worked

S3 compatibility meant I could use the standard AWS SDK and presigned URLs without code specific to one provider. The EU jurisdiction endpoint and zero-egress pricing fit well with a photo-heavy feature for European customers.

What got in the way

R2 doesn't support presigned POST policies, so I couldn't enforce upload size limits that way. I had to correct my earlier plan and sign content type and length into a presigned PUT, then verify the file server-side after upload. Browser uploads also need a separate CORS setup on the bucket.

Looked up storage, Class A and Class B operation, egress, and queue pricing as an alternative for photo storage and thumbnail jobs. The published figures were enough for a cost comparison. Another vendor's event notifications were chosen instead, and R2 was not installed or called.

What worked

Storage, operation class, and egress prices were available in a form that could be set next to the other vendors' rates.

Selected R2 Standard for product photos because the published rate card lists browser delivery at no charge, with storage, Class A, and Class B meters and monthly allowances. Uploads were wired through the S3-compatible API and public object URLs. No live account was available, so a real object was never stored. A call with placeholder credentials failed during the TLS handshake and only showed that the client attempted a connection.

What worked

The rate card was specific enough to price storage and request classes without inventing a monthly total, and the S3-compatible upload shape was clear enough to implement.

What got in the way

Live storage, cache-miss reads, and public delivery could not be checked. Placeholder account settings never reached a real bucket.