The files your app keeps.

• Files you ship

  Built output, a compiled image, anything checked into git.

  Replaced on every deploy. Losing the running copy costs nothing. The source is still in the repo.

• Files your app writes

  An upload, a generated export, a cache.

  Not in git. It exists only because a visitor made it, and a deploy does not touch it either way.

• Files nobody serves

  A backup archive, a log archive.

  Kept for a restore or a record, not for a visitor to load. Retention for each is owned elsewhere: Recovery and Logs.

1. 1

   A visitor sends it

   A form submit, a file picker, a direct request. The bytes travel with it.

   A visitor

2. 2

   Your app decides what to keep

   Validated, renamed, resized. Whatever your own code does with it, before it is written anywhere.

   You

3. 3

   It is written

   Onto the instance's own disk, or straight to durable storage if your app is built that way.

   CustomHosted

4. 4

   It is backed up that night

   Alongside the database, on the same nightly schedule. See Recovery for the manifest in full.

   CustomHosted

5. 5

   It is served back

   Read back by your app, or served straight from the edge. See Delivery for the cache rules in front of it.

   CustomHosted

A database's own storage is billed and sized as part of its own tier: 10 to 100 GB, depending which one. That is a different disk from the one on this page.

1. 1

   Auto-handled

   Restart, retry, or redeploy the last known-good version, done automatically

   No one, unless it recurs — it goes in the log, not a message to you

2. 2

   You hear from us

   A human looks at it and decides what to do — revert, restore, or a fix in code

   You, in writing, on the same quote channel as everything else — business hours for anything that isn’t urgent

3. 3

   Outage handling

   Worked ahead of the routine queue

   You, as soon as there is something to say, with priority handling; out-of-hours response is best effort, not a staffed round-the-clock desk

Those steps come from Scaling, reused word for word. The last one points at what a bigger tier does to the invoice, which Billing owns in full.

• Disk is part of the plan, not a meter

  Storage is sized into every tier's flat rate. Keeping a file there does not add a second charge.

• Serving a file back out is transfer

  The same fair-use allowance as any other traffic — Static Starter: ~100 GB transfer/mo; Static Pro: ~500 GB transfer/mo. See Billing for the rest of the invoice.

• Every social-share card this site publishes is a generated file

  Rendered by the build, not drawn by hand. One image per page that opts in, replaced whenever the copy or the page it represents changes.

• A published budget caps how much a page is allowed to serve

  Page weight, script weight, and request count are all measured against a real build and checked on every deploy. See Performance for the numbers.

• The honest half: this site stores nothing a visitor writes

  There is no upload of any kind on customhosted.com. Every file this site keeps, it wrote itself, at build time.

• No image resizing or transform service

  A file is stored and served as sent. Resizing or transcoding one is application code, not a platform feature.

• No file-level version history

  Beyond the nightly backup, there is no per-file undo. Overwriting a file replaces it; the previous copy only survives if last night's backup still has it.

• No autoscaling

  A flat rate means fixed, known capacity. Nothing on this platform grows itself in the background and bills you for it afterwards.

• A static site cannot accept an upload

  There is no writable disk to put it on. See the hosting-shape table above for the reason.

• Upload size is your call, not ours

  Decided by your app and whatever proxy sits in front of it, not by a platform-wide cap.

1. 1

   A routine scan flags a dependency

   The same kind of check that watches the infrastructure layers above, run against your application’s own dependency list.

2. 2

   It's triaged as application-level, not infrastructure

   A library your own code imports isn't ours to patch silently — it can change how the app behaves.

3. 3

   Briefed as a change

   Written up the same way any other change request is — this is what the Agentic iteration — CodeHerder add-on covers.

4. 4

   An agent opens the pull request

   The upgrade lands as a real pull request against the repository, with the test suite run against it.

5. 5

   A human reviews and merges

   Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind.

6. 6

   It ships through the same pipeline

   The same pipeline that deploys everything else on your stack ships this too — no separate process to babysit.

7. 7

   You're told it's done

   A note confirming what changed and that it merged, in the same shape as every other note on this site.

1. 01What happens when the disk fills up?

   Headroom is watched continuously, and flagged to a human well ahead of the point it would cause a problem. See "When the disk fills" above for the exact signal and the move that follows.

2. 02Does a file survive a resize?

   Yes. The disk moves with the instance during a scheduled move, the same procedure Scaling describes in full.

3. 03Can a static site accept an upload?

   No. A static site has no writable disk at all, so there is nowhere for an uploaded file to go. That needs a dedicated instance or a Custom shape instead.

4. 04What does storing a file cost?

   Nothing extra, up to the plan's own disk. It is sized into the flat rate, not a per-gigabyte meter. See "What it costs" above.

5. 05Do uploaded files get backed up?

   Yes, alongside the database, on the same nightly schedule. See Recovery for the full manifest and the Extended backup retention (30-day) add-on for a longer retention window.

6. 06Is there image resizing or a CDN transform on upload?

   No. A file is stored and served as sent. Resizing or transcoding one is application code, not a feature of this platform.

7. 07What if uploads keep filling the disk every month?

   That stops being a maintenance task and starts being a code fix: moving uploads to durable storage, or resizing on the way in. See "Where it becomes a briefed change" above for how that ships.