Many storage services work the same way as Amazon S3. JUDLEX can store its data in any of them.
Before you start: a space just for JUDLEX
In these services, files are kept in a bucket: a space with its own name inside your account. What we recommend:
A bucket just for JUDLEX, and private.
A key that only opens that bucket, with permission to list, read, write and delete. If someone got hold of it, they could not touch anything else in your account.
In almost every service the secret key is shown only once, when you create it. Copy it there and then.
What JUDLEX asks for
In Settings → Data → Add a connection, choose S3 (Wasabi, Backblaze, MinIO…) and fill in:
Field | What it is |
|---|---|
Service address (endpoint) | Your provider's server address for that region. It starts with |
Region | The region code, such as |
Bucket | The name of the bucket. It must already exist: JUDLEX does not create it. |
Folder inside the bucket (optional) | If you use the bucket for other things too. Only unaccented letters, numbers, “.”, “-” and “_”, with “/” between subfolders. JUDLEX works inside a JUDLEX folder under this one. |
Access Key ID | The first half of the key. |
Secret Access Key | The second half. It is secret: do not send it by email. |
Then there is Path-style addresses: turn it on with MinIO, or if your provider asks for it.
Click Connect and test. If the test fails, the window stays open with your details and the reason in red: correct them and click again.
If an office MinIO uses its own certificate, click Check the certificate next to the address and compare its fingerprint, as with a NAS (see A NAS with its own certificate).
If the test fails
The bucket is in another region: JUDLEX tells you which one, if the service says. Enter it in Region, or leave it empty so that JUDLEX works it out from the address.
That bucket does not exist: check the name (capitals matter) and that the service address is the one for the region where you created it.
It does not let it do this: the key signs in but has no permission on that bucket or folder. Check the key's policy: list, read, write and delete.
The server does not accept this computer's time: the clock is wrong. Set it right, ideally with automatic time.
You change the details with Change the details… in the connection's menu: if you leave the secret key empty, the stored one is kept. JUDLEX tests before saving: if the test fails, the connection stays as it was.
Details for each provider
Provider | Address | Region | Path style |
|---|---|---|---|
Amazon S3 |
|
| No |
Cloudflare R2 |
|
| No |
Backblaze B2 |
| the middle part of the address, such as | Either |
Wasabi |
|
| No |
MinIO | your server's address | whichever one it is set up with | Yes |
Where to create the key
Amazon S3: in IAM, create a user just for JUDLEX with no console access and a policy that lets it list, read, write and delete in that bucket; then, on that user, Security credentials → Create access key.
Cloudflare R2: R2 → Manage API Tokens → Create Account API token, with the Object Read & Write permission and limited to the JUDLEX bucket.
Backblaze B2: Application Keys → Add a New Application Key, with access to that bucket only and Read and Write. The account's master key will not work.
Wasabi: a policy for that bucket, and a user with programmatic access (Programmatic) that has that policy.
MinIO: whoever runs it gives you the key and the address.
Sharing with S3
You can share with a colleague in two ways:
By link: with S3 the link lasts 7 days at most.
With the firm folder: if your colleagues use the same bucket.
See Share a matter or a case file with a colleague.
Cost
Some providers charge for a minimum storage period on each file, even if it is deleted sooner (Wasabi, for example). If you keep only a few daily backups, bear this in mind when you choose a provider.