S3-compatible storage

The S3 protocol is the de facto standard for object storage. Tusk talks to it, and so do almost all serious object-storage providers (often alongside their own native API). One Tusk form covers all of them. The only differences are the endpoint URL, the access key format, and the region/path-style conventions.

Pick your provider below for a per-page setup with the exact endpoint URL and credential steps. If you already know what you're doing, the short version is on the Add your first destination page.

What all S3 providers have in common in Tusk

Regardless of provider, the form Tusk shows you takes four things: endpoint URL, bucket name, access key ID, and secret access key. Tusk writes files at the path you specify inside the bucket. The bucket folder must be empty when you add it as a destination (Tusk blocks non-empty folders to prevent mixed sessions).

Tusk uses an IAM-friendly minimum permission set: the credentials only need s3:PutObject, s3:GetObject, and s3:ListBucketon the target bucket. Don't use a root account's key. Create a dedicated user or API key with the minimum permissions. The per-provider pages walk through how to do that for AWS IAM and the equivalent on B2, R2, and MinIO.

Credentials and security

Tusk encrypts all stored credentials with macOS's built-in safe storage (safeStorage) and saves them to your login Keychain. They never leave your Mac. macOS will prompt you for your login password the first time you save credentials so it can authorize Keychain access.

Credentials saved for one provider only show up in that provider's form (S3 keys never appear in Google Drive pickers and vice versa). Buckets and folders are also checked for cross-project conflicts: if a bucket-and-folder pair is already used by another project in Tusk, the form blocks you from reusing it.