# The files your app keeps.

> See where an app's files live and what happens when the disk fills. Learn what survives a deploy, a resize, a restore and an exit.

Source: https://customhosted.com/files/

№ 01 Files

A file you shipped, a file your app wrote, and a file nobody serves all get called "files". This page names all 3, then follows the one your app writes: where it goes, what holds it, and what happens when the disk it's on fills up.

№ 02 Three kinds of file

## Three different things get called "files"

This page is about the second one. The other two are already owned elsewhere.

- 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](https://customhosted.com/recovery) and [Logs](https://customhosted.com/logs).

№ 03 Hop by hop

## Where a file goes, hop by hop

From the moment a visitor sends it to the moment it's served back.

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

№ 04 By hosting shape

## What holds a file, by hosting shape

One of these three shapes has nowhere to put an upload at all. The table says which.

| Shape | Plan | Disk | Detail |
| --- | --- | --- | --- |
| Static | Static Starter | None | A static site has no writable disk. There is nowhere to put an upload. That is the load-bearing fact on this page. |
| Dedicated | Dedicated S | 40 GB SSD | The instance's own disk, sized into the tier's flat rate. Not a metered add-on. |
| Dedicated | Dedicated M | 60 GB SSD | The instance's own disk, sized into the tier's flat rate. Not a metered add-on. |
| Dedicated | Dedicated L | 80 GB SSD | The instance's own disk, sized into the tier's flat rate. Not a metered add-on. |
| Custom | Custom | Sized to the workload | Durable storage sized and priced for what you actually keep, the same as any other Custom shape. |

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.

№ 05 When it fills

## When the disk fills

Watched well ahead of the point it would cause a problem, using the same signal and the same move as [Scaling](https://customhosted.com/scaling), reused here in full.

| Layer | Signal | What fires it | First response | Auto or human |
| --- | --- | --- | --- | --- |
| Capacity | Disk and memory headroom | Usage crossing a threshold set well ahead of the point it would actually cause an outage | Flagged to a human early, while it's still a maintenance task and not an emergency | Human |

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

20 minutes, typical

1. You — Ask for the move — Say which tier, or describe the new workload, through the quote channel. — ~5 min
2. CustomHosted — A window is agreed — A short, scheduled window you pick — never a surprise change that lands while you're not watching. — Nothing
3. CustomHosted — A snapshot is taken first — A fresh backup, immediately before anything changes, so the move has a rollback ready if needed. — Nothing
4. CustomHosted — The move happens — A static tier change is a configuration change with nothing to restart. A dedicated or database resize needs one short restart while the new capacity takes over. — ~10 min
5. You — Confirm it looks right — A quick check on your side, once it is back up. — ~5 min
6. CustomHosted — The new rate is confirmed — The next invoice carries the new line — see "What it does to the invoice" below. — Nothing

Those steps come from [Scaling](https://customhosted.com/scaling), reused word for word. The last one points at what a bigger tier does to the invoice, which [Billing](https://customhosted.com/billing) owns in full.

| Move | What visitors see | Restart |
| --- | --- | --- |
| Static tier change | Nothing. The site keeps serving from the edge network the whole time. | None — it is a configuration change, not a resize. |
| Dedicated resize | One short restart, inside the window you picked. | One restart while the new compute takes over. |
| Database tier change | A brief reconnect while the database switches to the new tier. | One short reconnect, timed with the same window. |
| Add-on added | Nothing. An add-on turns on without touching the running service. | None. |

№ 06 What survives

## What survives what

A deploy, a restart, a resize, a restore, and an exit. Said plainly, row by row.

| Event | Survives? | Detail |
| --- | --- | --- |
| A deploy | Yes | A deploy replaces the code that runs, not the disk underneath it. A file already written is still there once the new build starts. |
| A restart | Yes | The process comes back up; the disk it was writing to never went anywhere. |
| A resize | Yes | The disk moves with the instance during a scheduled move. See Scaling for the procedure, minute by minute. |
| A restore | Depends on the tier | Backed up alongside the database, same nightly schedule. See Recovery for the retention ladder, and the Extended backup retention (30-day) add-on for a longer window. |
| An exit | Yes | Ordinary files, not a proprietary export. Every file your app ever wrote, not just what shipped in the build. |

№ 07 What it costs

## What it costs

See [Billing](https://customhosted.com/billing) for the invoice, and [Pricing](https://customhosted.com/pricing) for the full rate card.

- 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.

№ 08 Worked example

## This site's own files

Every row below is backed by a real, generated file in this repository.

- 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.

№ 09 Said plainly

## The honest limits

Not buried in a footnote — the same discipline as every other honesty band on this site.

- 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.

№ 10 Where it's a pull request

## Where a full disk becomes a briefed change

Say uploads are filling the disk. The brief: move uploads to durable storage, and resize on the way in — see [Background jobs](https://customhosted.com/background-jobs) for the worker that actually does the resize. It ships the same way every other fix on this site does — Agentic iteration — CodeHerder ($25/mo):

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.

№ 11 Answers

## File questions

The questions that come up once "just add file uploads" stops being a one-line decision.

1. 01 What 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. 02 Does a file survive a resize? Yes. The disk moves with the instance during a scheduled move, the same procedure Scaling describes in full.
3. 03 Can 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. 04 What 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. 05 Do 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. 06 Is 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. 07 What 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.

№ 12 Keep reading

## What files connect to

- [Your data What sits on this page's disk — the personal data an upload can hold, and what deleting it actually does.](https://customhosted.com/your-data)
- [Logins A session held on this page's disk is one place a login can live — and what a rebuild does to it.](https://customhosted.com/logins)
- [Images The picture as bytes — its weight and format — as distinct from the file this page owns.](https://customhosted.com/images)
- [Scaling The move procedure and the downtime matrix this page's "when the disk fills" section reuses in full.](https://customhosted.com/scaling)
- [Recovery What a restore actually involves, and the retention ladder behind the backup row this page names.](https://customhosted.com/recovery)
- [Portability The full handover pack, including the files row this page's "what survives an exit" reuses.](https://customhosted.com/portability)
- [Dedicated The instance whose disk a written file actually lands on.](https://customhosted.com/dedicated)
- [Custom Durable storage sized to what you keep, once one instance is not the right shape.](https://customhosted.com/custom)
- [Background jobs The worker that actually resizes an uploaded image, once one is briefed.](https://customhosted.com/background-jobs)
- [Delivery The cache rules a file meets once it is served back out.](https://customhosted.com/delivery)
- [Content A picture checked into the repository, not a file your app writes at run time — the boundary this page and that one draw between them.](https://customhosted.com/content)

## Uploads filling the disk, or planning for them?

Brief it through the same quote channel as any other request — an agent opens the pull request, a human merges it, and the same pipeline ships it.

[Get a quote →](https://customhosted.com/contact)