SFTP for Backblaze B2: a complete setup guide

Backblaze B2 is one of the cheapest places to store bytes, with an S3-compatible API that lets standard tooling talk to it. That makes it a common target for SFTP workloads that are storage-heavy, backups, log drops, archival file exchange, where B2’s per-GB price is the draw. B2 doesn’t speak SFTP natively, so you put a translation layer in front of it.

Here’s how to give a partner an SFTP login that writes straight into your own B2 bucket.

Why B2 specifically

• Low storage cost. B2 is priced well below the first-party clouds for storage, which matters when SFTP is feeding an archive that only grows.
• S3-compatible endpoint. B2 exposes an S3 API alongside its native one, so any SFTP-to-S3 gateway can connect with an access key.
• Generous free egress allowance. B2’s egress is free up to a multiple of your stored data, which softens the download side of an SFTP workload.

Step 1: create a B2 bucket

In the Backblaze console: B2 Cloud Storage → Buckets → Create a Bucket. Keep it private. Note the bucket name and its region (it appears in the S3 endpoint).

Step 2: create an S3-compatible application key

B2’s S3 API uses application keys:

1. Account → Application Keys → Add a New Application Key.
2. Restrict it to the single bucket you created, with Read and Write access (or read-only for download-only users).
3. Save the keyID and applicationKey, the secret is shown once.

Your S3 endpoint follows this shape (the region matches your bucket):

https://s3.<region>.backblazeb2.com      e.g. https://s3.us-west-004.backblazeb2.com

The keyID is your Access Key ID and the applicationKey is your Secret Access Key for S3 clients.

Step 3: connect B2 to a managed gateway

With Firepipe, add B2 as an S3-compatible backend:

1. Choose S3-compatible when adding a connection.
2. Enter the B2 S3 endpoint, the keyID (access key), and applicationKey (secret). The key is stored encrypted and scoped to your bucket, rotate or revoke it whenever you like.
3. Create per-user SFTP credentials, each path-jailed to its own prefix in the bucket.

Partners connect over ordinary SFTP; files stream into your B2 bucket. The gateway custodies nothing, so you keep B2’s storage economics and your data stays yours.

Step 4: per-user access and audit

One credential per partner (SSH key or password), each jailed to its own path, with a full exportable audit trail of connections and transfers. Revoking a credential also ends any live session, and you can pin a credential to specific source IPs. This matters most for the archival use cases B2 attracts, where you’re often granting long-lived access to automated jobs you’ll later need to retire cleanly.

A note on B2’s minimum-charge policies

B2 is cheap but has its own billing rules (storage is billed by the GB-month; check current terms for any minimums). Your B2 usage is billed by Backblaze directly to you, the gateway only meters the throughput passing through it, with no per-operation or per-listing fees.

Roll-your-own alternative

SFTPGo has a native B2 backend if you’d rather run the server yourself; the trade-off is the usual one of owning the infrastructure. The decision tree is the same as for client SFTP access to S3.

Summary

B2 + SFTP suits storage-heavy, cost-sensitive transfer. Create a private bucket, make a bucket-scoped application key, and point a managed gateway at the S3 endpoint, files land in your B2 bucket, access is per-user and revocable, and you keep B2’s low storage price.