S3-compatible
Buckets speak the S3 API, so existing SDKs, backup tools, CLIs and WordPress offload plugins work against them. There is no proprietary client to adopt.
Object storage
Create S3-compatible buckets from your dashboard or the API and point your existing tools straight at them. Storage is backed by Cloudflare R2, so getting data back out does not carry an egress charge the way it does on AWS S3. An allowance comes with your hosting plan, and you are metered only above it.
Object storage for the files a website accumulates: images and video, downloads, user uploads, exports and backups. Buckets are created and managed from the dashboard or through the API, and they speak the S3 protocol, so the SDKs, CLIs and plugins you already use will talk to them without being rewritten.
It is backed by Cloudflare R2. The practical consequence is egress: with most object storage, serving a popular file is a charge that grows with your traffic, which quietly discourages you from actually using the storage you pay for. Here, reading your data back out does not carry that fee.
Storage that behaves like the S3 you already know, managed from the same place as your sites.
Buckets speak the S3 API, so existing SDKs, backup tools, CLIs and WordPress offload plugins work against them. There is no proprietary client to adopt.
Create a bucket, list your buckets, inspect one and delete it — from the dashboard or programmatically through the API. Provisioning storage does not require a support ticket.
Backed by Cloudflare R2, so reading data back out is not charged by the gigabyte. Serving a file that becomes popular does not turn into a bill that grows with its popularity.
Move images, video and downloads off the web server and serve them from storage instead. The origin gets smaller and faster, and deployments stop dragging a media library around with them.
A natural destination for database dumps, site archives and anything you need to keep but not serve. It is durable, off the web server, and reachable by any S3-aware tool.
Take uploads from your visitors straight into a bucket instead of onto the application server, and serve static assets through the CDN in front of it.
From nothing to a working bucket in three steps.
Make one from the dashboard, or call the API if you would rather have it created as part of your provisioning scripts.
Configure your existing S3-compatible client, offload plugin or backup tool with the bucket details. Nothing about your application code has to change to accommodate a new protocol.
Write your files and read them back as often as you like, with static assets served through the CDN. Usage counts against your plan's allowance and is metered above it.
Object storage is not a separate subscription. Every hosting plan includes a storage allowance, and you are metered only for what you use above it — so most sites never see a storage line at all. That means there is nothing extra to sign up for, and nothing to cancel if your usage drops back down.
Storage comes with your hosting plan — see the plans page, or talk to us and we will set you up.
There is no egress fee on top, so the amount you serve does not change what you pay. Only the amount you keep does.
Storage is only useful when you are willing to use it. Charging per gigabyte read is what makes teams hesitate before serving media from object storage, keep large files on the web server where they do not belong, or leave a CDN misconfigured because a cache miss costs money. Removing egress charges removes that hesitation.
We priced it as an allowance inside the plan rather than an add-on for the same reason. A separate storage subscription is one more decision, one more invoice and one more thing to forget to cancel, for a capability that nearly every site needs some of. Including it means storage is simply there when you reach for it.
Yes — the buckets are S3-compatible, so the AWS SDKs, S3-aware CLIs, backup tools and WordPress media-offload plugins you already use will talk to them. In most cases you are changing an endpoint and a set of credentials in a config file, not rewriting application code. If a tool can speak to S3, it can speak to this.
No. The storage is backed by Cloudflare R2, whose defining property is that reading data back out is not billed by the gigabyte. This is the main practical difference from AWS S3, where serving a popular file produces a bill that scales with its traffic — and it is why offloading media here does not become more expensive as a site succeeds.
It is included in your hosting plan as an allowance rather than sold as a standalone subscription, and you are metered only on the storage you use above that allowance. There is no separate signup and no minimum commitment. Your plan's allowance is shown on the plans page.
The four common jobs are offloading a site's images and video off the web server, holding backups and archives, receiving uploads from visitors, and serving static files through the CDN. All four keep large files off the application server, which makes deployments smaller and the origin faster. You can use one bucket for all of it or separate buckets per job.
On Cloudflare R2, which sits behind the S3-compatible interface you connect to. You manage buckets through our dashboard and API, and your tools talk S3, so the underlying platform is not something you have to work with directly.
Your plan already includes a storage allowance. Create a bucket from the dashboard, point your existing S3 tooling at it, and get the media off your web server this afternoon.
Get started