Where files are stored

The File Service keeps every tenant’s bytes in a storage account. Most tenants use the platform storage; a tenant can also have its files in storage of its own. Your code does not change either way. This page says what a platform administrator can change, what stays the same when files move, and the one rule your code must follow: treat every URL as opaque.

The platform storage and a tenant’s own storage

	Where the bytes are	Who sets it up
The platform storage (`default`)	The File Service’s own storage	Nothing to do: every tenant starts here
A tenant’s own storage	A bucket in an object store the tenant (or Central Code Station for it) controls, reached through its endpoint and access keys	A platform administrator, on request; see Storage accounts

Either way the service enforces the same permissions, quotas, scanning, renditions, audit and retention: the storage holds bytes, nothing else. Access keys are stored encrypted and never shown again; no tenant user or backend client ever sees them.

What a move keeps

A platform administrator can assign a tenant to another storage account (its new files go there from then on) and move its existing files. While a move runs, and after it:

Ids and records stay. Every file_id, folder_id, version number, revision, external_ref, access entry and share link is unchanged. Your database needs no update.
Downloads keep working. Each version is served from the old storage until its copy in the new one is complete and checked, then from the new one. URLs signed against the old storage keep working until they expire: the old copies are deleted only once every URL signed against them has expired.
Uploads keep working. New files and new versions go to the new storage at once.
Nothing is lost. Every copy is read back and compared with the original’s checksum before the original is deleted. Files under a legal hold are moved like any other, with the same check.
Usage and quota are unchanged: the same bytes are counted once.

If the storage a file lives in cannot be reached, the routes that need its bytes answer 503 storage_unavailable; retry later.

What can change: the public URL

A public file’s public_url and public_renditions name where its public copy is stored. They change when the tenant’s files move to another storage account, and when a new version becomes current. Keep a copy on your record if it saves you a call, but read it from the file again (GET P/files/:file_id) when it stops answering, and when a file.ready event arrives for the file (a new version is published once it is processed). Signed URLs are minted per call anyway; never store them.

Every URL is opaque

Upload URLs, part URLs, download and preview URLs and public URLs may point at an object store, a content delivery network or the File Service’s own host, depending on where the tenant’s files are stored. Two files of one application, or two versions of one file during a move, can have URLs on different hosts.

Use each URL exactly as the service returned it. Never build one, change its query string, or parse it for a host, a path or an expiry: the answer carries expires_at where it matters.
Send an upload PUT with exactly the headers the ticket lists, and nothing else (Upload protocol).
If your app restricts the hosts it talks to (a content security policy, an allow list in a mobile app), ask your platform administrator which hosts your tenant’s storage uses before a move, and allow them first.