Servera statiska assets från Cloudflare R2 i stället för S3: fördelar, regler och begränsningar

Statiska assets ser enkla ut tills de blir en stor och svårförutsägbar del av kostnaden. Produktbilder, PDF:er, video, typsnitt, dokumentationsexporter, genererade rapporter och nedladdningsbara byggen hamnar ofta i samma bucket. När trafiken växer är problemet inte längre bara lagring. Det är leverans.

Cloudflare R2 ändrar kalkylen: S3-kompatibel objektlagring, ingen R2-egressavgift till Internet och en tydlig väg att lägga bucketen bakom en Cloudflare-hanterad domän. Men R2 ersätter inte alla former av statisk hosting. Rätt val beror på om du serverar en webbapplikation eller objekt.

Det verkliga problemet är inte bara lagring

Ett publikt assetsystem behöver göra fyra saker:

1. Lagra objekt hållbart.
2. Exponera URL:er under ett kontrollerat hostname.
3. Cacha populära filer aggressivt.
4. Invalidera eller versionera ändringar förutsägbart.

S3 löser detta ofta med CloudFront framför. R2 gör det med en Cloudflare-domän, Cache Rules, WAF, Access och Workers när du behöver logik. Den praktiska skillnaden är inte bara bucket-API:et. Det handlar om var edge-lagret finns och vad du betalar när bytes lämnar lagringen.

När R2 passar bäst

R2 passar särskilt bra för publika filer som läses ofta och ändras sällan:

• hashade assets som app.4f3a1c.css eller vendor.91bc2.js
• bilder, video, typsnitt och Open Graph-media
• PDF:er, whitepapers, rapporter och publika nedladdningar
• releases, dataset, modellfiler och stora arkiv
• statiska kataloger där URL:en ska motsvara en objektnyckel

Fördelen är både ekonomisk och operativ. R2 tar inte betalt för egress från R2 till Internet, fungerar med mycket S3-kompatibel tooling och låter cache, säkerhet och leveransregler ligga i samma Cloudflare-kontrollplan.

SSG eller direkt leverans från R2?

Första frågan är enkel: serverar du sidor eller filer?

Använd SSG för HTML och routes. Astro, Cloudflare Pages, Workers Static Assets, Netlify och Vercel förstår routes som /pricing, SPA-fallbacks, redirects, headers per route, 404-sidor och atomiska deploys. Det är rätt för marketing sites, dokumentation, bloggar och appar där SEO, canonical, structured data och statuskoder spelar roll.

Använd R2 direkt när sökvägen identifierar en fil:

https://assets.example.com/brand/logo.svg
https://downloads.example.com/reports/audit-2026.pdf
https://releases.example.com/app/1.8.4/linux-amd64.tar.gz

R2 antar inte automatiskt att /docs/ ska servera /docs/index.html eller att /app/settings ska falla tillbaka till /app/index.html. Du kan lägga en Worker framför R2 för det beteendet, men då bygger du i praktiken en liten statisk host. Det kan vara rätt, men bör vara ett medvetet beslut.

Produktionsmönster som fungerar

Det säkraste mönstret är att behålla webbplatsen på en SSG-plattform och flytta tunga filer till R2:

www.example.com       -> webbplats eller app
assets.example.com    -> publik R2-bucket
downloads.example.com -> publik R2-bucket

Då ligger HTML-routes, previews, redirects och SEO-signaler kvar i webbplattformen, medan bilder, PDF:er och releases serveras från R2 via Cloudflare-cache.

För publika versionsarkiv kan R2 servera ett objektträd direkt. Använd inte bucket-listning som navigation. Publicera en indexsida från huvudsajten eller ladda upp en explicit index.html om användare behöver bläddra.

Om du behöver autentisering, tokens, path-normalisering eller dynamiska headers, lägg en Worker framför R2. Workern kan validera requesten, lösa objektnyckeln, sätta Cache-Control och returnera filen.

Egen domän, cache och säkerhet

I produktion bör du använda en egen domän som assets.example.com. r2.dev är bra för test, men bör inte vara din huvudsakliga publika yta. Med egen domän kan du använda Cache Rules, WAF, Access, botregler och Workers.

Cachereglerna bör vara tydliga:

• Hashade assets: Cache-Control: public, max-age=31536000, immutable.
• Muterbara filer som latest.zip, catalog.json eller index.html: kort TTL och purge vid deploy.
• Privata eller signerade nedladdningar: bypass cache eller en korrekt designad cache key.
• Cache Everything: bara på bucket-hostnamnet, inte globalt på applikationen.

Upload-pipelinen är lika viktig. Varje objekt behöver rätt Content-Type och rätt cachemetadata. JavaScript som serveras som application/octet-stream, eller SVG med fel typ, kan skapa problem i webbläsare, previews och säkerhetspolicys.

R2 vs S3: praktisk regel

S3 är fortfarande rimligt för företag som redan är djupt AWS-native, med CloudFront, IAM, signed URLs, logging och governance på plats. R2 blir attraktivt när egresskostnaden märks, filerna är publika eller semi-publika och Cloudflare redan är edge-lagret.

Använd tumregeln:

• HTML-sidor och app-routes: SSG, Pages eller Workers Static Assets.
• Stora publika filer och immutabla assets: R2 bakom egen domän.
• Enkla publika filträd: R2 direkt.
• Filträd med auth eller routing: Worker framför R2.
• Privata AWS-native workflows: S3 kan fortfarande vara bäst.

Den bästa arkitekturen är sällan “R2 överallt”. Den är mer precis: behåll sidor i verktyget som är byggt för sidor, flytta publika högvolymsbytes till R2 och lägg cache och säkerhet där trafiken faktiskt kommer in.