Concepts

Five things describe everything in Storey: regions, tiers, buckets, access keys, and grants.

Regions#

A region is a named, independent location where your data lives — currently nlsouth and nlwest, both in the Netherlands.

Regions are independent, not paired. Within a region your objects are stored across three separate datacentres, so losing one building does not lose your data. Losing an entire region is a different risk, and Storey does not silently protect you from it: if you need that, create a second bucket in the other region and write to both. Nothing is replicated across regions unless you do it.

A bucket's region is chosen at creation and cannot be changed afterwards. Copying an object between regions is deliberately not offered as a one-click operation, because it moves data across a residency boundary — that has to be a decision you make knowingly.

Tiers#

A tier describes the durability and performance class of storage. Today there is one: standard — three-way redundancy on spinning disk, suited to backups, archives, media and general object storage.

A bucket is created in one (region, tier) pair, called a placement. The console and GET /v1/placements list the placements you may order.

Buckets#

A bucket is a namespace for objects, scoped to your tenant. Bucket names are private to your tenant: two customers can both have a bucket called backups without collision, which is why bucket names do not have to be globally unique the way they do on some other services.

Names must be 3–63 characters, lowercase letters, digits and hyphens. Dots are not allowed — a dot in a bucket name breaks TLS certificate matching for virtual-host-style addressing.

Deleting a bucket requires it to be empty, and you confirm by typing its name.

Access keys#

An access key is what an S3 client authenticates with: an access key ID and a secret. Keys are created through the console or management API, never through the S3 API.

Two properties matter:

• The secret is shown exactly once, when the key is created. Storey does not store it and there is no endpoint to retrieve it later. If you lose it, rotate the key.
• A key belongs to one region. A key created for nlsouth cannot be used against nlwest, and attaching it to a bucket in another region is refused with a clear error rather than failing mysteriously at signing time.

Grants#

A grant attaches an access key to a bucket with read, write, or owner permission. A key with no grants can authenticate but reach nothing.

This is deliberately simpler than IAM policy documents: there are no per-prefix rules, no conditions, and no policy language. A key either reaches a bucket or it does not. If you need finer separation, use more buckets or more keys.

Tenants and roles#

Everything above belongs to a tenant. Within a tenant, roles decide what you may do:

Resellers (partners) can administer tenants they created, but reaching inside one requires an explicit, time-boxed impersonation that is recorded in your audit log — a partner cannot look at your data without you being able to see that it happened.