Do file bytes ever pass through our application server?

No. The server only signs intent: a 10-minute upload URL and 5-minute download URLs. The transfer itself is browser to provider.

What happens if the uploaded bytes do not match the checksum?

confirmObjectUpload reads the provider object and compares size and SHA-256. On a mismatch the object is marked quarantined and the confirmation fails, so it never becomes downloadable.

Who can reach a file?

Access requires membership: viewer to list and download, editor to upload and delete. A project-scoped object additionally verifies that the project belongs to the organization claiming it.

Are meeting transcripts stored here?

No. A transcript lives in its meeting record in PostgreSQL, not in object storage. This capability covers uploaded files and generated artifacts such as data exports and document attachments.

What is under the hood of an upload?

The request validates name, content type, size up to a 5 GiB single-upload ceiling, SHA-256 checksum and classification, requires the editor role, records a pending object under a tenant-scoped key, and returns a 10-minute signed PUT URL. Confirmation reads the provider object outside any open transaction and compares size and checksum. Deletion flips the object to deleting and emits an outbox event; the job claims each provider attempt with a durable attempt number, retries up to 7 times, and marks exhaustion as delete_failed.

The foundation under itDeveloper platform

Private files

Files go straight to private storage, and every byte is checked.

A document attachment, a form upload or a generated export goes from the browser to private storage without passing through the app server. The server signs a short-lived link first, then compares the stored size and fingerprint to what was declared. Only a match becomes downloadable, and every download link is short-lived and permission-checked.

0public file linksSHA-256fingerprint checked before a file goes live10 minbefore an upload link expires

Open Growth-OS See it working

16 of 22 in The foundation under it

Product example

See it working

This is the same visual component used by the authenticated app, rendered with deterministic sample data.

Scenario

viewport

surface theme

mode

Private object available

The metadata, its classification, the download link and the durable deletion controls.

Inert sample data · no network access

Upload a file

Editors can upload files up to 5 GiB. Files stay private, and each upload is checked before it becomes available.

Drag and drop a file here, or choose a fileMax size 5 GB · One file

Data classification

Choose how sensitive the file is. This label stays with the file.

Stored objects

1 object

Files stored in this workspace right now. Downloads use a short-lived signed link.

board-update.pdfAvailable

2.7 MiBConfidentialAdded 3 months ago

Retention and deletion

Check which files are waiting for deletion and when stored files expire.

Deletion is queued, not immediate

Deletion runs in the background. We retry until the storage provider confirms removal and keep a record of the result.

Deletions that ran out of retries

These files stay in the list so an editor can retry deleting them.

Files with an expiry date

An object with an expiry date is removed automatically once it passes.

Highlights

Why it matters

Private by default

Every object lives under its own organization key, and all access runs through short-lived, permission-checked links. There are no public URLs.

Verified before visible

After the upload the server asks the provider for the real size and fingerprint and compares them to what was declared. A mismatch is quarantined instead of published.

Deletion you can see

Deleting hides the object at once, then a retrying job removes the bytes. If the provider keeps refusing, the object is flagged as failed rather than left to linger unnoticed.

The problem this solves

Without a shared foundation, every team rebuilds these edge cases, differently.

Uploads that go through the app server

Streaming a large file through the application burns memory until requests time out. Letting the browser write straight to a bucket usually skips the permission check. Here the server approves first and the bytes still go direct.

The file that is not what it claimed

An upload is cut off halfway, or the bytes differ from what was declared. Without a settlement step the broken file becomes downloadable. A mismatch here means quarantine, never availability.

Files that are deleted only on paper

A delete that fails silently leaves bytes we are still paying for, and worse, bytes marked as gone that are not. A failed deletion here surfaces with its last error for a person to act on.

How it works

The mechanism end to end, as implemented in the repository.

1
Ask for an upload link
The server checks your role plus the declared name, type, size and fingerprint, then returns a signed link valid for ten minutes.
2
The browser uploads directly
The file goes from the browser to the storage provider with progress reporting. The application server never handles the bytes.
3
The server verifies
After the upload the server reads the object’s real size and fingerprint from the provider. A match makes it available, a mismatch quarantines it and fails the confirmation.
4
Deletion is a job, not a wish
Deleting removes the object from listings immediately, then a retrying job removes the bytes. Persistent failures are flagged for the control center.

Engineering guarantees

What this does and does not promise

Safety boundary

The certification evidence runs against a disposable local S3-compatible provider, not the hosted one. Finance receipt and invoice attachments are built on this capability but their resource is still draft, so that upload path stays off until it is certified.

Implementation evidence

The boundary above is code, not a claim. These files carry the contract:

src/features/storage/server.ts
src/features/storage/jobs.ts
src/features/storage/browser-upload.ts
.resource-certifications/storage.json

Questions

Frequently asked questions

Used alongside this

These capabilities share contracts and boundaries with this one.

Work that finishes

A transcript extraction survives a restart, and you watch it happen.

Control center

One owner-only screen for whatever needs a person.

Export and delete on request

Take your data out, or close your account, and it finishes.

What private files rests on

The docs describe the same contracts this page demonstrates.

Read the docs See the whole directory