Wasabi

Wasabi is S3-compatible, so Sliick talks to it through the same S3-Compatible provider form as Amazon S3. Everything in the Amazon S3 pages applies. This page covers what is different about Wasabi, in the order you need it.

The step people miss is the bucket CORS rule, and it fails in a way that looks like a broken component rather than a configuration gap: the connection test keeps passing, because it runs server-to-server and never touches the browser path. “Uploads fail but the connection test is green” is the expected shape. Do the CORS rule before you test an upload.

What works on Wasabi, and what does not

Capability	On Wasabi	Notes
Upload, download, delete	Yes	Browser-direct uploads, same as AWS
Version history	Yes	Sliick’s own version history, independent of bucket versioning
Media processing (HEIC conversion, thumbnails)	Yes	Signs with your credentials against your endpoint
Deleted Files and restore	Needs bucket versioning on	See the verification note below
Migration from Salesforce Files	Yes	Premium feature
Folder path templates	Yes
Share links	Yes, for external providers	Off until switched on for your org
Two-way sync	No	Wasabi has no event-notification service to point at

Two-way sync is not available on Wasabi

Sliick’s S3 sync integration is wired through an AWS SNS topic that publishes bucket events. Wasabi provides no equivalent, so there is nothing to point the notification at and no ARN to enter.

In practice: changes made directly in the Wasabi bucket, such as renaming or deleting an object in the Wasabi console, are not reflected back into Salesforce. Everything done through Sliick works normally. If bucket-side change detection is a requirement, use Amazon S3, Google Cloud Storage, Azure Blob Storage or SharePoint instead.

1. Create the bucket

1. Sign in to the Wasabi console.
2. Buckets → Create Bucket.
3. Name it. Bucket names are globally unique across Wasabi, for example acme-salesforce-files.
4. Choose the region deliberately. It fixes your endpoint URL and your data residency.
5. Enable Bucket Versioning. This is not optional if you want Restore to work. Sliick’s delete removes the object’s bytes immediately; with versioning on, that leaves a delete marker, and Restore works by removing that marker to un-delete the object. With versioning off, deletes are permanent and Restore reports the file as gone.
6. Leave Object Lock and object logging off unless you have a separate reason for them.

Bucket versioning and Sliick’s version history are two different things. The version panel in the file list is Sliick’s own and works regardless of this setting. Bucket versioning exists here purely to power Restore from the Deleted Files tab.

2. Note your endpoint URL

Wasabi’s endpoint is region-specific, and getting it wrong produces a signature or host error rather than a helpful message.

The pattern is https://s3.<region>.wasabisys.com, for example https://s3.eu-central-1.wasabisys.com. The original us-east-1 region is the exception and also answers on the bare https://s3.wasabisys.com.

Read the exact value from the console rather than assembling it from memory. The bucket’s Settings → Properties panel shows its region, and Wasabi publishes the current region-to-endpoint list in their documentation. New regions are added over time.

You enter this as Endpoint in Sliick Settings. Unlike AWS, it is not optional for Wasabi.

3. Create an access key

1. In the console, open Access Keys under your account menu.
2. Create New Access Key. Scope it to a sub-user rather than the root account if your plan supports sub-users.
3. Copy the Access Key and Secret Key now. The secret is shown once.

The key needs seven operations, scoped to this bucket:

Scope	Actions
Bucket	ListBucket, GetBucketLocation, ListBucketVersions
Object	GetObject, PutObject, DeleteObject, DeleteObjectVersion

The two version-related actions are what Restore needs: Sliick lists the key’s versions to find its newest delete marker, then deletes that marker to un-delete the object. Omit them and uploads still work while Restore silently cannot recover anything.

If you use a Wasabi sub-user with an explicit policy, mirror the policy shape from Create the access key. The policy grammar is S3-compatible.

4. Configure CORS on the bucket

1. Open the bucket → Settings → CORS.
2. Add a rule allowing GET, PUT and HEAD from your Salesforce origins, exposing the ETag header. Use the same JSON as Configure CORS on the bucket.
3. Save.

List every domain users will upload from: production, each sandbox, any Experience Cloud site, and your scratch orgs if you are developing. There is no subdomain wildcard: https://*.lightning.force.com does not work. Find your domains under Setup → My Domain.

The GET rule also powers the photo editor: images over 4 MB load straight into the canvas from your bucket. Without GET, or with your origin missing, large images open view-only instead of editable.

5. Add lifecycle rules

Sliick stages browser uploads under input/ and writes processed images under processed/. If processing ever fails, the staged original would otherwise sit in the bucket indefinitely.

1. Open the bucket → Settings → Lifecycle.
2. Add a rule named expire-input-prefix, prefix input/, expiring objects after 7 days.
3. Add a second rule expiring noncurrent versions after 100 days, to match Sliick’s Deleted Files retention window. With bucket versioning on, every deleted object leaves a noncurrent generation behind, and without this rule they accumulate forever.

Read the billing note below before relying on lifecycle rules or deletes to control cost.

6. Salesforce setup

Nothing extra. The packaged trusted site covers every region-specific Wasabi host, so there is nothing to add in Setup, and the credential grant is the same as Amazon S3. See Salesforce setup.

7. Connect

1. Open Sliick Settings.

2. Provider = S3-Compatible. It is the same form as Amazon S3.

3. Enter:

   Field	Value
   Access Key ID	From step 3
   Secret Access Key	From step 3
   Bucket Name	From step 1
   Region	For example eu-central-1, and it must match the bucket
   Endpoint	Your Wasabi endpoint from step 2. Required

4. In Integration User, enter the username of the dedicated user you set up in Set up the Integration User.

5. Click Connect, then Test connection once the credential grant is in place.

On success the status flips to Active. To rotate keys later, update the Access Key ID and Secret here and reconnect.

8. Verify, in this order

Each step isolates a different layer:

1. Test connection → Active. Proves credentials, endpoint, region and the permission grant. Proves nothing about the browser path.
2. Upload a small PDF from a record’s file list. Proves CORS.
3. Upload a JPEG and watch it leave the Processing state. Proves media processing can read and write your bucket.
4. Download it back, then delete it and confirm it appears under Deleted Files.

If step 1 passes but step 2 does nothing, look at the CORS rule.

Verify Restore before relying on it

Restore on the S3-compatible providers works by listing the key’s versions, finding the newest delete marker, and deleting that marker. Wasabi supports bucket versioning, but this is the one capability whose end-to-end behaviour has not been verified on Wasabi specifically. Before depending on it in production:

1. Enable versioning and grant the two version actions.
2. Upload a test file through Sliick, delete it, and confirm it appears in Deleted Files.
3. Click Restore and confirm the file comes back and downloads. A row returning to the list is not proof the bytes came back.

If Restore reports the file as gone, the usual causes in order: versioning was off when the delete happened, so no delete marker was created and enabling versioning afterwards does not create one retroactively; or the key lacks ListBucketVersions or DeleteObjectVersion.

Billing note: Wasabi’s minimum storage duration

Wasabi bills a minimum storage duration per object. An object deleted before that period elapses continues to be billed for the remainder. Confirm the exact number for your plan in your Wasabi contract or console; it is commonly 90 days on pay-as-you-go.

This interacts with Sliick in three places:

• Deleting a file does not immediately stop its storage cost. Sliick’s delete removes the bytes right away and keeps a restorable entry for 100 days; Wasabi keeps charging until the minimum duration is up.
• The input/ lifecycle rule expires staged uploads after 7 days, well inside the minimum duration, so those deletions reclaim space but not cost. It is still worth having, to stop unbounded growth of orphaned staging objects.
• The noncurrent-version rule has the same limitation. Versioning is still the right setting, because it is what makes Restore possible at all, but budget for deleted files continuing to bill for a while after deletion.

This is how Wasabi prices storage, not a malfunction. It does mean “delete files to reduce the bill” behaves differently here than on AWS.