Backup destinations
MinIO, Wasabi & other S3-compatible providers
Almost every object storage provider speaks S3. Tusk works with all of them. Here are the ones we know people use.
Tusk supports any service that speaks the S3 protocol. The form in Tusk doesn't change. You enter an endpoint URL, bucket name, and a credential pair, and Tusk handles the rest. The differences below are about where to find each provider's endpoint and how to generate access keys.
MinIO (self-hosted)
MinIO is the most popular self-hosted S3-compatible server. Run it on a NAS, a Synology, a homelab box, or a VPS. Tusk treats it like any other S3 destination.
1
Note your MinIO endpoint
The endpoint is the host and port of your MinIO server (e.g. minio.local:9000 or 192.168.1.20:9000). If MinIO is behind HTTPS, include the scheme: https://your-minio:9000.
2
Create a bucket
From the MinIO console, create a bucket named e.g. tusk-backups.
3
Create access keys
Under Access Keys, generate a new key pair. MinIO Identity Manager lets you scope keys to specific buckets; do that for Tusk if you can.
4
Add the destination in Tusk
In the Tusk S3 form, paste the endpoint, bucket, folder, and key pair. Tusk does a real round-trip during the connection test.
Self-signed certificates
Wasabi
Wasabi is a managed S3-compatible service with simple, low pricing and no egress fees up to a certain ratio of stored data. Setup is similar to AWS.
1
Create a bucket
From the Wasabi console, create a private bucket. Note the region you pick (e.g. us-east-1, eu-central-1).
2
Create an IAM-style access key
Wasabi has its own IAM clone. Create a user, attach a policy allowing s3:PutObject, s3:GetObject, s3:DeleteObject, and s3:ListBucket on your bucket only, then create an access key for that user.
3
Get the endpoint
Wasabi's endpoint follows the pattern s3.<region>.wasabisys.com (e.g. s3.us-east-1.wasabisys.com). Confirm against the Wasabi docs for your region.
4
Add the destination in Tusk
Same form as the others. Endpoint, bucket, folder, key pair.
Other providers we've seen people use
The same setup works for any S3-compatible service. A non-exhaustive list of ones that work:
- iDrive e2 — endpoint
<region>.idrivee2.com - Storj — endpoint
gateway.storjshare.io(with the gateway you create), uses S3 access keys - Scaleway Object Storage — endpoint
s3.<region>.scw.cloud - Linode Object Storage — endpoint
<region>.linodeobjects.com - DigitalOcean Spaces — endpoint
<region>.digitaloceanspaces.com - Hetzner Object Storage — endpoint
<region>.your-objectstorage.com - Vultr Object Storage — endpoint per cluster from the Vultr dashboard
For each of these, the recipe is the same: create a bucket, create a credential pair scoped to that bucket, paste the endpoint plus credentials into Tusk's S3 form, test the connection, save.
What to check if a connection test fails
The connection test does a real PUT and GET. The most common failure modes:
- Wrong endpoint URL:typically a missing or extra subdomain. Copy from the provider's bucket details page rather than the marketing pages.
- Region mismatch:some providers fail silently if the region in the endpoint doesn't match the bucket's region.
- Insufficient permissions:the credential doesn't allow
s3:ListBucket(Tusk uses this for its connection check). Add it to the policy. - TLS errors:usually a self-signed certificate (most often with self-hosted MinIO). Add the cert to your Mac's System keychain as trusted.
Screenshot
S3 destination form in Tusk filled in for a non-AWS S3-compatible provider, e.g. Wasabi or iDrive e2. Show the endpoint, bucket name, and folder path with placeholder values to indicate the same form supports any S3-compatible service.
alt: The S3 destination form with an alternative provider's endpoint
Related