---
title: Concepts
path: concepts
status: published
---

# 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:

| Role | Can |
|---|---|
| `tenant.viewer` | See everything, including object listings |
| `tenant.operator` | Browse, upload and delete objects |
| `tenant.admin` | Manage buckets, keys, grants and quotas |
| `tenant.owner` | Everything, including deleting buckets and the tenant |

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.