Files people upload on a form — admin

Who opens it: nobody, directly. This is what happens to a photo, a document or a signature after somebody attaches it to a registration form, and what an organizer sees when there are too many of them.

What they came to do: collect a waiver, a passport photo or a signature, without thinking about storage.

True when they leave: the file is private, reachable only through a signed link, and counted against the plan.

Decisions already made

• Private, under the tenant, never a public path. tenants/{tenant}/events/{event}/uploads/{ulid}.{ext} on a private disk, served by an hour-long signed link on the tenant's own host. Images get a thumbnail beside them.

• Images and PDF only, 10 MB each (owner, week 12), because there is no virus scanner before GA. A field may narrow that, never widen it.

• Everything kept counts toward storage_mb (PRICING §7, §8): the file and its thumbnail, in whole megabytes rounded up, so a signature counts as 1 MB and a photo as 2 MB with its thumbnail. One place decides (StorageMeter), and week 17's asset pipeline will use the same one.

• Owners are warned at 80 % and 100 %, once each. Nothing stops at 100 %.

• Forms stop accepting files at 120 %. The person filling in the form is told on the field — "This form cannot accept more files at the moment. Please ask the organizer, or send the file to them directly." — and their other answers still submit. They did nothing wrong and cannot fix the plan, so the message never mentions billing.

• Files nobody will claim are swept. A form keeps a file the moment it is uploaded, before the registration exists, which is what makes drafts and multi-page forms work. An upload older than the 72-hour draft window that no registration's answers point at is deleted nightly and taken off the meter. A referenced file is never touched.

• The nightly rollup recounts from the disk, so a flushed cache or a missed increment corrects itself, and the number on Settings → Usage can never contradict what the form enforces.

• Deleting a registration gives its storage back. The files on it and on its people are deleted with their thumbnails and come off the meter, rather than waiting for the nightly sweep to notice them. A registration whose people have been checked in cannot be deleted at all, and nothing is released for a delete the database refuses.

• Files the organization cannot control count toward nothing — tickets, exports, badge runs, rosters and import files. An organizer does not choose how many ticket images a registration generates, and billing them for it would be billing them for using the product as designed (owner, 2026-09-16).

Open questions

• Nothing deletes a registration today: no admin action, no API route, no retention job. The release is there for whatever adds one — data_retention_months is the likely first.