Other S3-compatible storage

Any storage that speaks the S3 protocol can hold a project’s files. In Settings → Storage choose Other as the Provider. This page says what goes in its fields and then, per service, where to find each value and what to watch for. For AWS and Cloudflare R2 there are pages of their own: AWS S3, Cloudflare R2.

Fill in the Other form

Field	What to write
Server address	The service’s S3 address, for example `https://s3.eu-central-1.wasabisys.com`. https only, and an address Plune can reach from the internet: a private address, `localhost` or a server inside your network is refused.
Region	The region the requests are signed for. Many services ignore it, some need a specific value; each section below says which.
Bucket	The bucket’s name.
Folder	`plune`, or another folder; Plune writes, reads and deletes only inside it.
Path-style addresses	Off: the bucket is part of the host name (`my-bucket.s3.example.com`). On: the bucket is in the path (`s3.example.com/my-bucket`).
Access key ID, Secret access key	The key’s pair. The secret is stored encrypted and never shown again.

Path-style matters. With it off, Plune puts the bucket in front of the host name, which works only if the bucket’s name has no dots and the service answers on such host names. With it on, the address is <server>/<bucket>/<key>, which most services accept. When unsure, turn it on. The checks report when the choice is wrong (“turn on path-style”).

Check and connect tests the connection before anything is saved. Every failure has a cause on When something is wrong.

Whatever the service, make the key reach one bucket and no more, and keep the bucket private. CORS for the dashboard is described in general on CORS; the per-service place to set it is below.

Backblaze B2

Server address. B2’s S3 address is https://s3.<region>.backblazeb2.com, for example https://s3.us-west-004.backblazeb2.com. Do not guess it: open B2 Cloud Storage → Buckets and copy the Endpoint of your bucket. An account lives in one region for good, so the address is the same for all its buckets.

Region. The second label of the address, such as us-west-004. B2’s documentation does not name the region string to sign with; this one is taken from the address, and signed links made with it worked against a live B2 bucket (checked 16.10.2026, eu-central-003).

Path-style. Both styles work; a bucket whose name has a dot must use path-style. Turn it on.

The key.

Open Application Keys → Add a New Application Key.
Name it, such as plune. Under Allow access to Bucket(s) choose the one bucket, not All.
Under Type of access choose Read and Write.
Tick Allow List All Bucket Names. It appears once one bucket is chosen, and SDKs and checks on a bucket-restricted key need it.
Leave Duration empty. A key that expires stops uploads without a word.
Create New Key and copy the keyID (the Access key ID) and the applicationKey (the Secret). The application key is shown once.

You may fill File name prefix with plune/ to restrict the key to the folder. B2 maps the S3 operations to its own capabilities: writing needs writeFiles, reading and HEAD need readFiles, and deleting a file needs writeFiles and deleteFiles. Whether the Read and Write preset contains deleteFiles is not spelled out in the pages we read: not yet verified, and the check’s delete step will show it.

Free tier and daily caps

A Backblaze account can run into a limit that is not about the key. What follows is from Backblaze’s own pages, read on 15.10.2026 (the sources are listed at the end of this section); Backblaze changes its terms, so the figures it gives for you are the ones on your account.

In short: Backblaze’s free tier has daily caps on downloads and on read (Class B) and listing (Class C) calls, and a project with many files can use them up in one run. Raise them under Caps & Alerts (the account needs a payment method); they reset at 12:00 AM GMT.

Storage. The first 10 GB is free; beyond that storage is charged.
Daily caps. Backblaze counts usage per day in four groups and lets you set a daily cap, in dollars, on each: storage and the transaction classes below. Counters reset daily at 12:00 AM GMT (UTC).
Class A. Uploads and other writes, including deleting a file. Class A calls are free.
Class B. Downloads and reads: GET (GetObject) and HEAD (HeadObject).
Class C. Listing, and the management of buckets and application keys: ListObjectsV2, ListBuckets and the like.
Download bandwidth. The data read out of the account. Backblaze gives free egress up to three times the average monthly storage and charges $0.01/GB beyond that.
Without a payment method. Backblaze’s API reference says daily transaction caps apply to accounts that do not pay: a call over the cap is refused with 403. The free daily amounts of download bandwidth and of Class B and Class C calls are limited, and their figures are not on the current Backblaze pages we could read: check Backblaze’s current pricing before you rely on a number. Putting a payment method on the account is what lets you raise the caps.

Where to see and change them. Sign in to Backblaze, and in the left menu under B2 Cloud Storage click Caps & Alerts. Edit Caps, clear No Cap and enter a dollar amount per day for a category, or select No Cap to remove the cap, then Update Caps. A change may take up to 10 minutes. Without a cap, usage is unlimited and so is what can be charged, so set one that you can afford. Backblaze sends an alert at 75% and at 100% of a cap.

What it looks like in Plune. When a daily limit is used up, Backblaze answers a read with HTTP 403:

<Code>AccessDenied</Code>
<Message>Cannot download file, download bandwidth or transaction (Class B) cap exceeded.
See the Caps & Alerts page to increase your cap.</Message>

The key is fine; the account is out of its day. In Plune:

In Settings → Storage, the check’s read step fails. In versions without the dedicated message it reads like Read denied, the keys can write but not read the file back; newer ones say the provider’s limit is used up.
plune run import prints bucket_unreachable for each file it cannot confirm.

How a report spends Class B. Every file a reporter uploads is confirmed once at the end: Plune asks your bucket for it with a HEAD, about one Class B call per uploaded file. A run with a few thousand screenshots therefore spends a few thousand Class B calls at once, and every time a person opens a file in the dashboard it is a read too. A project with many files per run can use a day’s free Class B calls within one run.

What to do. Add a payment method and raise or remove the caps in Caps & Alerts, or wait until 12:00 AM GMT, when the counters reset; then press Test connection. Nothing needs to change in the key or in Plune.

The key for Plune. Read and Write on the one bucket (a File name prefix is optional), as in the steps above. The applicationKey is shown once when you create it: copy it then, or make a new key.

Sources, read on 15.10.2026: Understand Backblaze B2 Data Caps and Alerts, How to Create and Manage Caps and Alerts, Backblaze B2 API Pricing, B2 Cloud Storage Pricing, b2_authorize_account (error list).

Versions: a delete does not free the space. B2 buckets are always versioned. The default rule is Keep all versions of the file, and deleting a file by name hides it while older versions stay — and stay billed. In Buckets → your bucket → Lifecycle Settings choose Keep only the last version of the file, or add lifecycle rules of your own. Since December 2025 B2 also takes lifecycle rules through the S3 API. What a Plune delete leaves behind under each setting has not yet been verified.

CORS on Backblaze

The last step of Check and connect is CORS lets … read and add files, and on Backblaze it is the one people stop at. Two things make it so: the key you give Plune is for one bucket and cannot change the bucket’s settings, and B2’s web console cannot write the rule Plune needs. In the console, CORS Rules offers only ready-made presets that allow reading (GET): every origin, all HTTPS origins, this one origin. None of them allows PUT or the content-type header, and a preset has a choice of API that is easy to get wrong — a rule for B2 Native API does not apply to S3 requests, which are the ones Plune makes. The result is a rule that exists and a check that stays red with cors_put_missing.

The rule Plune needs is set through B2’s API, with a key that may change bucket settings. There are two ways.

Plune does it: Set up CORS for me

In Backblaze open Application Keys → Add a New Application Key. Name it plune-cors. Under Allow access to Bucket(s) choose All and give it Read and Write: a key for one bucket cannot change settings, and this one needs listBuckets and writeBuckets. Create it and copy the keyID and the applicationKey; the application key is shown once.
In Plune open Settings → Storage, fill the form for your bucket, and choose Set up CORS for me.
Paste the keyID and the applicationKey and choose Set up CORS.
Wait about a minute — B2 applies the rule with a delay — and choose Check and connect. The CORS step turns green.
In Backblaze, delete the plune-cors key. Plune does not need it again.

What the button does, and does not do:

It makes one change to the bucket: it adds a rule for the dashboard’s address (https://app.plune.ai; on the beta https://beta.plune.ai) that allows GET, HEAD and PUT and the content-type header. The rules the bucket already has are kept; a rule from an earlier press for the same address is replaced. If the bucket changes while Plune is working, nothing is overwritten.
It does not keep the key. The key goes in the request, is used for that one call and is forgotten: it is not saved, not written to a log or to the audit, and not shown again. The key Plune keeps remains the narrow one for your folder.
Only an owner of the project can press it, and five times a minute at most.

If it fails, the dialog says why, in one line: the key was refused, it may not read or change settings, there is no such bucket, Plune could not reach Backblaze, or the bucket already has 100 rules. In every case nothing was changed. Add the rule by hand, as below.

By hand

Use this if you would rather not hand a key that can change the bucket to anyone. The rule, in B2’s own form, is:

[
  {
    "corsRuleName": "plune-dashboard",
    "allowedOrigins": ["https://app.plune.ai"],
    "allowedOperations": ["s3_get", "s3_head", "s3_put"],
    "allowedHeaders": ["content-type"],
    "maxAgeSeconds": 3600
  }
]

On the beta, write https://beta.plune.ai. Apply it with a key that has writeBuckets (not the key you gave Plune). One command, reading the rule from a file so that quoting does not depend on your shell: save the JSON above as cors.json and run the Backblaze command-line tool’s bucket update with the file, or use any client of B2’s b2_update_bucket call with corsRules set to it. The S3 API’s PutBucketCors against B2’s S3 address is the other way: it answered 200 on a live bucket with a key that may change the bucket’s settings (checked 16.10.2026 with a direct request, not the AWS CLI). It is one list of rules: a rule set through the S3 API showed up in B2’s native listing, and a rule set through the native API showed up in the S3 API’s GetBucketCors. Setting it replaces the whole list in both cases, so include the rules the bucket already has.

Check it and read the answer

Choose Test connection; the CORS step names the problem.

cors_missing — no rule lets the dashboard’s address read. A preset for B2 Native API gives you this.
cors_put_missing — the dashboard may read but not put a person’s file: the rule lacks s3_put, or the content-type header. A this one origin preset gives you this.

Both are explained on When something is wrong. A change takes about a minute to apply. On the production dashboard the origin is https://app.plune.ai; to serve both, put two origins in allowedOrigins, or press the button once on each.

Wasabi

Server address. https://s3.<region>.wasabisys.com. Use the address of the region the bucket was created in; the console shows it beside the region name. The first region has no region in its address.

Region	Server address
US East 1 (N. Virginia)	`s3.wasabisys.com` (also `s3.us-east-1.wasabisys.com`)
US East 2 (N. Virginia)	`s3.us-east-2.wasabisys.com`
US Central 1 (Texas)	`s3.us-central-1.wasabisys.com`
US West 1 (Oregon)	`s3.us-west-1.wasabisys.com`
US West 2 (San Jose)	`s3.us-west-2.wasabisys.com`
CA Central 1 (Toronto)	`s3.ca-central-1.wasabisys.com`
EU Central 1 (Amsterdam)	`s3.eu-central-1.wasabisys.com`
EU Central 2 (Frankfurt)	`s3.eu-central-2.wasabisys.com`
EU West 1 (UK)	`s3.eu-west-1.wasabisys.com`
EU West 2 (Paris)	`s3.eu-west-2.wasabisys.com`
EU West 3 (UK)	`s3.eu-west-3.wasabisys.com`
EU South 1 (Milan)	`s3.eu-south-1.wasabisys.com`
AP Northeast 1 (Tokyo)	`s3.ap-northeast-1.wasabisys.com`
AP Northeast 2 (Osaka)	`s3.ap-northeast-2.wasabisys.com`
AP Southeast 1 (Singapore)	`s3.ap-southeast-1.wasabisys.com`
AP Southeast 2 (Sydney)	`s3.ap-southeast-2.wasabisys.com`

The list is Wasabi’s service-URL page as of October 2026; check it for new regions.

Region. The region in the address (eu-central-1), and us-east-1 for the plain s3.wasabisys.com. Wasabi’s documentation says every region is accepted for version 4 signing and shows us-east-1 in its own examples; that the region should follow the address is inferred, not yet verified.

Path-style. Wasabi recommends path-style. Turn it on.

The key. Wasabi’s access keys have no per-bucket scope of their own: you scope a sub-user with a policy.

In the Wasabi console open Policies → Create Policy and use the JSON below, with your bucket’s name.
Open Users → Create User, choose the Programmatic (create API key) option and attach the policy.
Copy the Access Key and the Secret Key. Wasabi shows the secret once; a user may have two keys.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:GetObject", "s3:DeleteObject"],
      "Resource": ["arn:aws:s3:::<bucket>/plune/*"]
    }
  ]
}

A key of the root user also works but can do everything in the account; do not use it. If the bucket is versioned, deleting a specific version needs s3:DeleteObjectVersion, which Plune does not need. That HEAD is covered by s3:GetObject is the usual S3 rule, not stated in Wasabi’s pages: not yet verified.

CORS. Wasabi’s API page says it answers every request that carries an Origin with permissive CORS headers (any origin, GET, HEAD, PUT and more), and that it does not support PutBucketCors. If so, the dashboard can read your files with no step on your side. Another Wasabi page describes a custom CORS editor in the console under Buckets → your bucket → Settings → Permissions → Cross-Origin Resource Sharing (CORS) and warns that it does not validate every kind of request. The two pages disagree and neither has been tried here: not yet verified. If the CORS check fails, that editor is where to look.

Minimum storage time: a deleted file is still billed. Deleting an object before the minimum storage period ends still bills the days that remain. Wasabi’s own worked example uses 90 days, which can be changed to 30 on request. Test artifacts that you keep for two weeks are billed as if they lived for the whole period. Plan the lifecycle with that in mind.

Lifecycle. Buckets → your bucket → Settings → Lifecycle → Create New Rule: scope it to the prefix plune/, expire current versions, and permanently delete noncurrent versions if the bucket is versioned.

IDrive e2

Server address. Your own. IDrive e2 says every account has its own region addresses, and its keys work only with the address of their region. Open the Dashboard, find Enabled regions, and copy the endpoint of the region that holds your bucket. IDrive’s public pages also list addresses of the form s3.<region>.idrivee2.com (for instance s3.eu-central-1.idrivee2.com); whether they work for every account is not stated, so prefer the one from your Dashboard. Write it with https://.

Region. us-east-1. IDrive’s partner guides tell to enter us-east-1 as the region for all e2 regions. Not yet verified with Plune.

Path-style. Turn it on; IDrive’s own examples are path-style.

The key.

Open the Access Key tab and choose Create Access Key.
Name it, and choose the region that holds the bucket.
Set an expiry date and time. Choose a far date: an expired key stops uploads.
For permission choose Read and write, allow deleting objects and do not allow deleting buckets.
Under the buckets, choose the one bucket (all are selected by default).
Create Access Key and copy the Access Key ID and the Secret Access Key.

A key cannot be edited; to change it, delete it and create another.

CORS. Buckets, hover the bucket, the settings icon, Bucket CORS → Add CORS, choose JSON and Apply. The page of IDrive that describes it does not show what the JSON looks like, so we cannot give you a rule to paste; the S3 API takes the usual AWS rule as XML. Whether a key scoped to one bucket may call the CORS API is not stated, so use the console. Not yet verified. The region-wide CORS screen has been discontinued.

Versioning and the minimum. The bucket-creation dialog has optional toggles for versioning, object locking and retention; leave them off — with versioning on, a delete only adds a marker. IDrive e2 enforces a minimum storage duration of 30 days: deleting earlier still bills the remainder.

Lifecycle. The bucket’s settings icon, Object Lifecycle → Add Rule, with the prefix plune/. IDrive documents it (an older comparison that says e2 has no lifecycle rules is out of date).

MinIO

Your own server, so most values are yours.

Server address: the https:// address of your MinIO, reachable from the internet. Plune refuses private addresses and does not follow redirects, so a MinIO on localhost or inside a private network cannot be used — put it behind a public address with a certificate from a public authority, or the check says tls.
Region: any; MinIO accepts any.
Path-style: on. MinIO needs it.
Key: make a user or service account with a policy for one bucket and the plune/ folder: the same three actions (s3:PutObject, s3:GetObject, s3:DeleteObject) on arn:aws:s3:::<bucket>/plune/*.
CORS and lifecycle: set in MinIO itself; see MinIO’s own documentation. Not yet verified.

DigitalOcean Spaces

Not yet verified; the values below are taken from how other S3 tools document Spaces, not from a run here.

Server address: https://<region>.digitaloceanspaces.com, such as https://ams3.digitaloceanspaces.com.
Region: the same short name (ams3).
Path-style: try it on; if the check complains, turn it off.
Key: a Spaces access key pair from the control panel’s API section.
CORS and lifecycle: in the Space’s settings in the control panel; see DigitalOcean’s documentation.

Google Cloud Storage

Not yet verified; the values below are taken from how other S3 tools document Cloud Storage.

Cloud Storage speaks S3 in its interoperability mode, with HMAC keys instead of the service account’s JSON key.

Server address: https://storage.googleapis.com.
Region: the bucket’s location, such as us-east1.
Key: an HMAC key for a service account. In the Google Cloud console open Cloud Storage → Settings → Interoperability to create it; give the service account only the rights to the one bucket (the object rights to read, write and delete).
CORS and lifecycle: set on the bucket with Google’s own tools (gcloud storage buckets update), not through the S3 side; see Google’s documentation.

If a service is not here

Anything that speaks S3 may work with Other: Server address from the service’s S3 page, a signing region the service accepts, Path-style if it asks for it, a key for one bucket. Run Check and connect and read the cause. Which services Plune lists is a choice, not a limit.