If you’re running apps on a VPS, cloudflare r2 vs s3 is no longer an academic debate—it directly affects your bandwidth bill, latency, and how painful “oops, we egressed 20TB” feels at the end of the month.
What R2 and S3 are (and what VPS builders care about)
Amazon S3 is the default object storage API for the internet: durable, feature-rich, and supported by basically every tool. Cloudflare R2 is a newer S3-compatible object store designed around one big idea: no egress fees (at least from R2 itself). In VPS hosting workflows, object storage usually backs:
- Static assets and media uploads
- Backups/snapshots (app-level, not hypervisor-level)
- Log archives and data exports
- CDN origins for websites
If you host on providers like digitalocean or hetzner, you’re typically trying to keep costs predictable while still getting global performance. Object storage is the easiest place to accidentally blow that up.
Pricing and egress: the real differentiator
My opinion: for most VPS-hosted web apps, the object storage bill is dominated by bandwidth, not capacity.
S3 economics:
- Storage is competitively priced, but egress is where you pay.
- Requests, lifecycle transitions, replication, and “nice-to-have” features can add line items.
- If you put S3 behind CloudFront, you may optimize delivery but you’re still in AWS billing land.
R2 economics:
- The headline is $0 egress from R2.
- You still pay for storage and operations.
- Data transfer from Cloudflare to the broader internet is typically handled inside Cloudflare’s network, which is exactly what you want when you’re serving public assets.
For a VPS hosting stack, that changes architecture decisions:
- With S3, you often end up caching aggressively just to avoid bandwidth cost.
- With R2, it’s easier to use object storage as an origin for a CDN without fear.
Caveat: “no egress” doesn’t mean “no network cost anywhere.” If your VPS pulls lots of data from R2, your VPS provider may still charge for outbound bandwidth, and some providers charge for inbound at scale. But R2 removes the biggest surprise bill most teams hit: object store egress.
Performance and latency: where your users notice
S3 performance is excellent, but it’s region-centric. You pick a region, and requests travel there unless you layer caching/CDN on top.
R2 is designed to live close to Cloudflare’s edge network, and it plays especially well with Cloudflare’s caching. In practice, for typical “VPS + global visitors” scenarios:
- S3: great if your app is mostly in one region and you can keep traffic local (e.g., app servers in us-east-1, S3 in us-east-1).
- R2: great if you want global read performance with minimal setup and you’re already using Cloudflare in front.
If you’re hosting on hetzner (popular in Europe) but have visitors worldwide, R2 + Cloudflare caching can reduce perceived latency without deploying multi-region infrastructure. If your workload is internal (backups, data pipelines), S3’s regional model may be totally fine.
Compatibility and features: S3 is the baseline, R2 is “enough”
S3 has decades of features: event notifications, inventory, object lock/governance modes, deep lifecycle controls, multiple storage classes, and a huge ecosystem.
R2’s pitch is different: be S3-compatible enough that your tools work, and optimize for cost + edge delivery.
Here’s the practical checklist for VPS hosting:
- API compatibility: R2 supports the S3 API, but not every obscure S3 feature. Test before committing.
- Tooling: Most backup tools and SDKs that speak S3 will work with an endpoint + keys.
- Lock-in: S3 is “lock-in by gravity” (everything supports it). R2 is “lock-in by workflow” if you lean heavily into Cloudflare’s edge features.
My rule: if you need advanced compliance controls or niche S3 capabilities, S3 wins. If you just need object storage that won’t punish you for serving files, R2 is often the better default.
Actionable example: using R2 with an S3 client on a VPS
Below is a minimal AWS CLI-style setup many VPS users already know. You can use it on a box hosted at digitalocean or hetzner to push backups to R2.
# 1) Configure a named profile for R2
aws configure set aws_access_key_id "$R2_ACCESS_KEY" --profile r2
aws configure set aws_secret_access_key "$R2_SECRET_KEY" --profile r2
aws configure set region auto --profile r2
# 2) Upload a backup (R2 is S3-compatible, so use the S3 commands)
aws s3 cp ./backup.tar.gz s3://my-bucket/backups/backup.tar.gz \
--endpoint-url https://<accountid>.r2.cloudflarestorage.com \
--profile r2
# 3) (Optional) List objects
aws s3 ls s3://my-bucket/backups/ \
--endpoint-url https://<accountid>.r2.cloudflarestorage.com \
--profile r2
This is the kind of migration that takes minutes, not days—provided your app doesn’t rely on S3-only features.
So, which one should you choose for VPS hosting?
If you’re building typical VPS-hosted sites/apps (WordPress, Laravel, Node, Django) and you serve lots of public assets, I’m bullish on R2 as the default: egress is the silent killer, and cloudflare built R2 to remove that pain.
Choose S3 when:
- You need the full S3 feature set or strict compliance options
- Your compute is already in AWS and data locality matters
- You’re doing heavy internal workflows that don’t benefit from edge delivery
Choose R2 when:
- You expect high public download/streaming volume
- You want predictable costs and simple CDN-friendly architecture
- You’re already using Cloudflare for DNS/WAF/CDN
In a VPS hosting context, a common setup is: VPS on hetzner or digitalocean, object storage on R2 for user uploads and backups, and keep the app stateless. If you later outgrow your VPS, that separation makes migration easier—without forcing you into a hard commitment today.
Some links in this article are affiliate links. We may earn a commission at no extra cost to you if you make a purchase through them.
Top comments (0)