Storage provider
s3nd with Wasabi
Flat-rate storage with no egress charge, on a regional endpoint.
import { createBucket } from 's3nd'
const store = createBucket({
bucket: 'transfers',
region: 'eu-central-1',
endpoint: 'https://s3.eu-central-1.wasabisys.com',
credentials: {
accessKeyId: process.env.WASABI_ACCESS_KEY!,
secretAccessKey: process.env.WASABI_SECRET_KEY!,
},
})Why this one
Wasabi
Wasabi is S3-compatible, priced per stored terabyte with no egress or request fees, and reached through a regional endpoint. It works with s3nd like any other endpoint-based provider: set the endpoint and the region, and hand it a key pair.
From the command line
A starter configuration, and what is left to do.
init writes the file with ${VAR} references rather than secrets, so it is meant to be committed; the env file it points at is not.
s3nd init --provider wasabi --bucket transfers{
"bucket": "transfers",
"region": "eu-central-1",
"endpoint": "https://s3.eu-central-1.wasabisys.com",
"prefix": "transfers",
"expiresIn": "24h",
"envFile": ".env",
"credentials": {
"accessKeyId": "${WASABI_ACCESS_KEY}",
"secretAccessKey": "${WASABI_SECRET_KEY}"
}
}Then
- 01Put WASABI_ACCESS_KEY and WASABI_SECRET_KEY in .env.
- 02Add a lifecycle rule on the transfers/ prefix.
- 03Run
s3nd doctor. It performs the operations s3nd needs and reports what happened.
Worth knowing
Notes on Wasabi.
Minimum storage duration
Wasabi bills deleted objects for a minimum retention period. Transfers are small, so it rarely matters, but it is the one line on the invoice that surprises people.
Expiry cleanup
expiresIn stops a transfer being handed over; only a lifecycle rule deletes the object. Give the prefix a rule that expires objects after a day or two, and s3nd doctor turns green.
Other providers
The endpoint is the only difference.
Put a file. Hand over the code.
Point it at the bucket you already pay for. Nothing to deploy, nothing to sign up for, nothing in the middle.
npm install -g @s3nd/clis3nd init --provider r2 --bucket drops3nd put ./anything.zip