SFTP for Cloudflare R2: a complete setup guide

Cloudflare R2 is S3-compatible object storage with one headline difference: no egress fees. That makes it a natural fit for SFTP, where partners and jobs are constantly pulling files back out, on most clouds, downloads are where the bill quietly grows. The catch is that R2 speaks the S3 API, not SFTP, so you need something in between to translate.

Here’s how to give a client a normal SFTP login that reads and writes straight into your own R2 bucket.

Why R2 specifically

• Zero egress. You pay for storage and operations, not for bytes leaving the bucket. For an SFTP workload with heavy downloads, this is the whole game.
• S3-compatible API. Anything that speaks S3, including an SFTP-to-S3 gateway, can talk to R2 with an access key and a custom endpoint.
• Cloudflare-native. If you’re already on Cloudflare, your data sits next to your CDN and Workers.

Step 1: create an R2 bucket

In the Cloudflare dashboard: R2 → Create bucket. Pick a name and a location hint. That’s the bucket your SFTP users will land in.

Step 2: mint a scoped R2 API token

R2 uses S3-style access keys, created as R2 API tokens:

1. R2 → Manage R2 API Tokens → Create API token.
2. Scope it to Object Read & Write (or read-only if the user should only download).
3. Restrict it to the specific bucket you just created, not your whole account.
4. Save the generated Access Key ID and Secret Access Key. You won’t see the secret again.

You’ll also need your S3 endpoint, which looks like:

https://<ACCOUNT_ID>.r2.cloudflarestorage.com

Your account ID is shown on the R2 overview page.

Step 3: connect the bucket to a managed gateway

R2 doesn’t offer SFTP itself, so the cleanest route is a managed bring-your-own-bucket gateway. With Firepipe you connect R2 as an S3-compatible backend:

1. Add a connection and choose S3-compatible.
2. Paste the R2 endpoint, the Access Key ID, and the Secret. The key is stored encrypted and scoped to your bucket: least-privilege access you can rotate or revoke at any time.
3. Create per-user SFTP credentials, each jailed to a path prefix inside the bucket.

Your partner now connects over plain SFTP; their files stream straight into your R2 bucket. Nothing is custodied on the gateway side, and you keep R2’s zero-egress economics.

Step 4: hand out per-user access

Give each partner their own credential (SSH key or password) rather than a shared login, so you can revoke one without breaking the rest. Each user is path-jailed to their own prefix, you get a full exportable audit trail of every connection and transfer, and revoking a credential also tears down any live session. You can pin a credential to specific source IPs if a partner connects from a fixed range.

The alternative: roll your own

You can run SFTPGo or OpenSSH + rclone against R2 on your own VM. You get full control and no gateway in the path, at the cost of operating a server (patching, HA, monitoring, key rotation). Fine if you enjoy that; a tax if you don’t. See how to give a client SFTP access to your S3 bucket for the same trade-off discussion on AWS.

Summary

R2 + SFTP is a strong pairing precisely because R2 doesn’t charge for egress and an SFTP workload pulls a lot of data back out. Create a bucket, mint a bucket-scoped R2 API token, and point a managed gateway (or your own server) at the S3 endpoint. Either way, the files stay in your R2 bucket. Start on the pricing that fits, or read the multi-cloud picture if you span more than one provider.