Skip to content

Backblaze B2

Backblaze B2 keeps files such as customer attachments in cloud storage that your app can read and write.

Visit Backblaze B2

What does your app need to start storing files?

Create a private bucket, the storage container for your app’s files. Your server can connect through Backblaze’s own API or the S3-compatible interface. Use the endpoint shown for your bucket and an application key scoped to the necessary work.

Save the file key, which is the name your app uses to find the object, alongside the customer record. Keep that mapping in your app’s database so you can check which account owns the file.

Can a customer download a file without making the whole bucket public?

Yes. First have your app check that the signed-in account is allowed to open the file. Your server can then create a short-lived signed download link using B2’s S3-compatible interface. Anyone who has the link can use it while it remains valid.

In B2’s S3-compatible interface, file visibility inherits the bucket’s public or private setting. A single file cannot be made private with an object ACL inside a public bucket. Keep customer files apart from publicly readable assets.

When can downloading files add to the bill?

Pay-as-you-go B2 currently lists US$6.95 per TB per 30 days, measured over time by byte-hour. It includes outbound data up to three times your monthly average stored amount. The first 10 GB of storage is free. Beyond the included outbound amount, downloads are generally US$0.01 per GB. Check whether your delivery path qualifies for a partner exception.

For example, if your monthly average is 100 GB, the included amount under that rule is 300 GB. Estimate your uploads, normal downloads and a possible move to another host separately. Request classes A, B and C are listed as free. The published Class D table covers specific event notification operations with a separate daily allowance and fee.

How can you check access and plan a move before uploading anything?

Draw a private bucket on paper and invent a receipt file for a fictional account. Use no real files, addresses or access keys. Plan the outcomes you would later verify with a disposable setup.

  1. Follow an owner and a second account
    Mark whether each account should receive a link. A signed-out visitor and a different account should be refused before your app issues a link.
  2. Trace what a forwarded link can do
    Expect a recipient to be able to open a still-valid bearer link. If forwarding must never grant access, plan an app download that rechecks the account on each request.
  3. Keep the file and its app record together
    Write down which objects to copy and the database keys that point to them. Include the bucket settings and old download cost in the move plan. Check file counts and open a sample before switching.