Who can do what

One project has one connection to one bucket, and only an owner of the project can change it.

Who	What they can do
Owner of the project	Connect a bucket, replace the key, test the connection, disconnect. Owners and admins of a company become owners of a project when they join it; being in the company alone gives no access (Members).
Member and reader	See what is connected — the provider, the bucket, the folder, who connected it and when. Never the secret; of the access key ID, only its last four characters.
Every member of the project	Open the project’s files by a link that lives 10 minutes. The link is made after Plune checks the membership; a file of someone else’s project answers not found, the same as a file that does not exist.
The project’s CI token	Get a link to write a file into the project’s results, valid for 15 minutes. It never sees the bucket’s secret.
An owner or a member in the dashboard	Get a link to write a file they add to a case or to the case being marked, valid for 15 minutes. A reader gets none.
Plune	Only what the key allows, in the folder you gave. No change of the bucket’s settings.
People outside the project	Nothing. The bucket is private; if it is public, the check warns you.

The key

The secret access key you give is stored encrypted, and neither the dashboard nor the API ever shows it again — not to the owner who typed it, not in logs. Plune’s side of the connection shows only the last four characters of the access key ID, enough to tell two keys apart.

The links Plune hands out are signed with the key, and a signed link carries the access key ID in its address (not the secret). A person who copies a link can see which key signed it, and can use the link only until its minutes are over.

A key can be right and still be refused when the provider’s own daily limit is used up, as on Backblaze B2’s free tier: Provider cap.

Give the key the least it needs: write, read and delete inside one folder of one bucket. Each provider page shows how: AWS S3, Cloudflare R2, the others.

Replace a key

When a key is rotated, expires or leaks, an owner opens Settings → Storage and chooses Replace keys. Enter the new pair (and change the other fields if needed) and press Check and save. The keys already saved keep working until the new ones pass the checks, and nothing is saved before — a mistyped secret does not break a working connection.

You can leave the secret empty only when the access key ID is the same one; a different key needs its own secret.

Revoke a key

Deleting the key at the provider (the IAM user’s access key, the R2 token, the B2 application key …) cuts Plune off at once, whatever Plune remembers. The next link fails and Test connection reports bad credentials. That is the reliable way when a key has leaked.

Disconnect in Settings → Storage forgets the connection in Plune. The files stay in your bucket, and Plune opens them again only if the same bucket and folder are connected again. New screenshots go back to Plune’s built-in storage; traces and videos are kept as names only. Deleting the key at the provider afterwards is yours to do.

Why the bucket must be private

The files hold what your tests saw: pages, responses, logs, sometimes a person’s data. A bucket that anyone can read hands all of it to anyone who knows the address. Plune never needs a public bucket — every read goes through a link that expires — so keep Block public access (or the provider’s same switch) on. When the check finds the bucket readable by anyone it does not fail, it warns: see Bucket is public.

What the CI sees

The CI holds a project token (Authentication). When it has a file to send, it asks Plune for a link to write that one file, and sends the bytes straight to your bucket with that link. It sees the link and nothing else: not the key, not the bucket’s other files, and not a link that is older than 15 minutes.