Evidence Storage Settings

Evidence files — the documents, exports and screenshots attached to your evidence items — are written to an object store. Settings → Evidence storage is where an organisation administrator sees which store is in force and, if you would rather hold your own evidence, points the organisation at a store of your own.

Everything on this screen is scoped to one organisation. Configuring a store here changes where this organisation’s evidence goes and nothing else.

If this card says “MinIO — bundled”, your evidence is in an end-of-life store

The bundled MinIO container exists so a self-hosted install works before anyone has a cloud account. MinIO archived its community edition in April 2026, the image the platform ships is the last one published, and security advisories have been raised against it that have no community fix — two of them allow writing objects without authenticating. It is an evaluation and pilot store, not a place to keep evidence you would be asked to produce in an audit.

Point this organisation at a store of your own below. The platform copies what is already there and checks every object as it goes. Operators can read the detail in the troubleshooting guide.

What the card shows

The top of the card answers one question: where does this organisation’s evidence go right now? The answer is resolved, not guessed — your own active configuration if you have one, otherwise the platform default, otherwise whatever the installation’s environment names. A chip says which of those three it is.

What you see	What it means	Can you change it here?
MinIO — bundled, installed by the installer	The object store the installer set up alongside the platform. This headline appears only for that store, which the platform records on the configuration row itself — a MinIO the operator set up by hand is shown as a platform default instead	Not directly, but you can switch this organisation to your own store
Managed by operator (platform default)	A store whoever runs the platform configured for every organisation	Same: switch this organisation to your own
Managed by operator (environment)	No active configuration applies to this organisation — neither one of its own nor a platform default — so the store named in the installation’s environment is in use. Draft configurations may well exist; a draft is not in force	Same
Managed in app	This organisation’s own store, created on this screen	Yes — edit, test, rotate, retire
No evidence store is configured	Nothing is in force and the environment names nothing either — the API reports this as configured: false. Evidence uploads are refused until something is configured	Yes — create one here

While an organisation is in that last state, uploading or downloading an evidence file is refused with a message naming this screen: “No evidence store is configured for this organisation, so evidence files cannot be uploaded or read.” Evidence delivered to the inbox is refused the same way and recorded as failed, with the same message on the delivery, so nothing is silently dropped. The refusal is a property of this organisation’s configuration, not an outage — the rest of the platform is working, and only an administrator here can clear it.

A store that belongs to the operator is shown read-only, with no edit, rotate or delete action. That is not a permissions quirk: it is the operator’s to change, on the host. What you can always do is give this organisation a store of its own, which then takes precedence.

Adding your own store

Use a different store opens the editor. Choose a provider first — the provider decides which fields you are asked for.

Provider	What you supply	Notes
Amazon S3	Bucket and region	The endpoint is Amazon’s own, derived from the region. Leave the key pair blank to use the instance role the platform already runs under
Google Cloud Storage	Bucket and an HMAC key pair	Reached over the S3-compatible XML API at storage.googleapis.com. Create the key pair under Interoperability in the Cloud Storage settings — a service account JSON key will not work
MinIO	Endpoint, bucket and a key pair	Your own MinIO, not the bundled one
Other S3-compatible	Endpoint, bucket and a key pair	Any store that speaks the S3 API

Two rules apply to every address you type, whatever the provider:

• It must be https.
• It must not resolve to a loopback, private, carrier-grade NAT or link-local address.

Both are refused when you save, and checked again when the platform actually connects. The bundled store is the single exception, and no request can create one — only the installer does.

Saving creates a draft. A draft is inert: nothing resolves it, and no evidence is written to it.

Test before it goes live

Test connection writes a small object to the store, reads it back and deletes it, then reports each step separately — the address check, the write, the read-back and the delete. A failure names the step and the class of error, never anything the store sent back.

Activate stays disabled until a test has passed. Activating re-runs the same probe on the server and refuses if it fails, so a configuration cannot go live without having been proved reachable at the moment it went live.

Activating a new configuration retires the previous one in the same step. One configuration is active per organisation.

Rotating the credential

Rotate key replaces the stored secret without touching the address or the bucket. An active configuration is probed with the new credential before anything is stored, so a wrong secret leaves the working one in place rather than taking evidence storage down.

Every worker picks the new credential up within a couple of seconds. No restart, and nothing to do on the host.

Secrets are write-only throughout. The platform encrypts one when you save it and never shows it again: a configured store displays a fixed mask of eight characters, the same mask whatever the secret is. There is no reveal, and there is no way to read a stored secret back out of the platform.

Retiring and deleting

Retire takes a configuration out of service while keeping the row, so evidence written under it is still readable. The organisation falls back to the platform store, and then to the environment.

Delete removes it entirely, and is refused while the configuration is active or while any evidence file is still stored under it. The refusal says how many files those are.

Switching a store does not move your files

This is the important one. Changing where evidence is written changes it for new uploads. Files already in the old store stay there, and stay readable — each file remembers the configuration it was written under.

So do not delete or empty the old store after switching. Move existing evidence, further down the card, is how you bring them across.

Moving existing evidence

Once the new store is active, the card offers to copy this organisation’s evidence into it from wherever that evidence currently is. Choose the store to copy from; the store in force now is always the destination. There is a confirmation step, and then a progress bar that polls the server — the copy runs in the background, so you can leave the page and come back to it.

The common case: off the bundled store

Most installations start bundled: evidence is written to the store that came with the platform, and the organisation brings its own later. Those earlier files sit in that bundled, platform-managed store, so that is what the list offers as the source, labelled managed by the platform, shared.

It is shared, and that changes one thing about the copy. Every other organisation on this installation is still writing to the same store, so a copy out of it never retires it and never empties it. When the copy finishes, the card says the source was left in service and why. That sentence is the one to read before touching a bucket: a platform store is never yours to empty, and the copy will not tell you it is.

A store of this organisation’s own is different — it is retired once no evidence file references it any more, and the card says so in as many words.

What the copy guarantees, and what it does not:

Every object is verified	Each file is read back out of the new store after it is written and checked by size and by SHA-256 checksum. A file that does not match is counted as failed and left pointing at the old store. This verifies the copy; it is not an ongoing tamper-evidence check on either store
One file at a time	Each file is committed on its own, so a copy that is interrupted has moved exactly the files it reports and no others. Running it again picks up where it stopped rather than starting over
Nothing is deleted	The copy never removes anything from the store it is reading. If it fails halfway, both copies exist and every file is still readable
Retirement is earned, not assumed	A store of this organisation’s own is retired only once no evidence file references it any more. If any file was left behind, the card says so and the configuration stays in service
A shared store is never retired	The bundled, platform-managed store stays in service whatever the copy reports, because other organisations are still writing to it

Files that could not be copied are listed by key, with the class of failure — a missing object, a size disagreement, a checksum mismatch. Fix the cause and run the copy again; the files already moved are skipped.

Only after a copy reports that the source configuration has been retired is that store safe to empty — and that answer only ever comes back for a store belonging to this organisation. If the card says the source was left in service, it is still in use, by this organisation or by another one.

If saving is refused

What you see	What it means
SCF_SECRET_KEY is not configured	The platform has no encryption key, so it will not store a credential at all. An operator has to set one on the host. A store supplied by the operator keeps working meanwhile
A refusal naming the address	The endpoint is not https, or it resolves to an address the platform will not dial
The connection test fails on write	The credential can reach the store but cannot write to that bucket
You cannot change this	You are a member of the organisation but not an administrator of it. Evidence storage is an organisation administrator’s to configure

Operators will find the underlying endpoints, states and resolution order in the admin quick reference.