Organisations & buckets

The shape of an account

An organisation owns its buckets, credentials and team membership. People belong to an organisation; a credential belongs to exactly one. Nothing is shared between organisations, and the edge checks that on every request — a valid signature from one organisation cannot reach another’s bucket even if it knows the name.

A bucket lives in one region and holds objects under keys, exactly as it does on S3. Buckets are named pc-<org>-<label>: the prefix keeps names unique across the platform, and the label is yours.

One organisation can create multiple buckets. The internal prefix and shared storage pool are implementation details: the dashboard shows only that organisation’s buckets, and every bucket receives its own restricted upstream key so an edge mistake cannot cross the tenant boundary.

Creating them

Buckets are created in the dashboard, or with POST /v1/buckets. Not over the S3 API — and this is the single most common surprise for anyone whose tooling expects to provision its own bucket on first run.

The reason is that a bucket here is more than a namespace. Creating one allocates storage-account capacity, mints the internal key that signs upstream, and installs the CORS rules the dashboard’s own file browser needs. An S3-level CreateBucket would produce half of that, and the half it left out would fail later, somewhere less obvious.

Tiers

Each bucket is created in one of two tiers, and the tier is fixed for its lifetime. This replaces per-object storage classes, which do not exist here.

To store colder data, create a cool-tier bucket and write to it — there is no automatic tier transition and no restore step, because nothing is ever archived out of reach. Bucket settings can separately remove older/deleted versions and abandoned multipart uploads after a retention period; those cleanup controls never move an object between Hot and Cool.

Canada East production currently has Hot capacity. Cool becomes available to an organisation only when the platform has assigned a healthy Cool storage pool; do not select it during the internal rollout unless the dashboard shows that capacity.

Storage cleanup

Overwriting or deleting an object can leave an older version consuming storage, and an interrupted multipart upload can leave uploaded parts behind. The Usage page shows both in the last measured storage table.

Open a bucket’s Settings → Storage cleanup to choose how long to keep older/deleted versions and when to cancel unfinished multipart uploads. Cleanup runs asynchronously after the selected number of days; the latest visible object is never removed by these controls.

Visibility

A bucket is either private or public, and public means exactly one thing:

• Private — every request must carry a valid signature, or be a presigned URL you issued.
• Public — anonymous GET and HEAD work, with no credential at all. Writes still require a real, scoped identity. Public never means writable.

See public buckets & presigned URLs for which one to reach for.