When Your Disk Fills Up, Every App in Your Account Stops

Most resource limits degrade you. This one stops you. If the total disk across your account goes over the limit, every application in that account is stopped — and none of them will start again until the number comes back down. The pricing page states it plainly: "If your total Disk usage exceeds the account limit (for example, when an application doesn't track or rotate stored data), all applications in the account will be stopped and cannot be started again until the total volume size drops below the limit" (pricing). What makes it worth understanding in advance is that disk is the one resource you don't choose — you don't pick a volume size, the platform measures what you actually wrote — and that the obvious way to clean up isn't available once your apps are stopped.

Disk is measured, not allocated#

This is the part that differs from everything else and catches people out.

CPU and RAM are allocations. You pick a preset, you get that ceiling, and you're billed on what you allocated rather than what you used. Your app running flat out and your app sitting idle cost the same.

Disk doesn't work that way. A volume has no size you set. It starts at zero and the platform periodically measures how much it actually holds, and that measurement is what your quota and your bill are computed from. Write a gigabyte of logs and your disk usage is a gigabyte larger — there was no size to pick and nothing to pick it at.

Two consequences worth internalising:

• You can't over-provision your way to safety. There's no "give it 20 GB and forget about it". The number only moves when your data moves.
• The figure lags. It's updated by a background measurement, not on every write, so a fast-growing volume can be over the line before the panel shows it. Don't run close to the ceiling and expect the display to warn you in time.

What counts, and what doesn't#

Your disk usage is the total size of your volumes. That's it.

Your image doesn't count. A 1.2 GB image consumes no disk quota. It costs you slower deploys rather than storage, which is a real cost but a different one.

Writes outside a volume don't count either — and they don't survive. Anything your app writes to the container filesystem is discarded when the container is recreated, which happens on every deploy and every configuration change. That's the flip side of needing a volume for anything you want to keep.

Container logs don't count. What you print to stdout goes to the platform's log capture, which is capped and rotated for you. A log file your app writes into a volume is a different thing entirely, and it's the most common cause of this whole problem.

The catch-22 once you're stopped#

Here's the part to plan around, because it's genuinely awkward.

The natural response to a full disk is to open a shell and delete something. You can't — the shell and the file browser both operate inside a running container, and they're disabled while an app is stopped. Your apps are stopped precisely because the disk is full.

So the recovery path isn't self-service. The pricing page notes that administrators can temporarily raise the limit through a support ticket, and that's what unblocks you: get the ceiling lifted, start an app, delete the data, get back under the original limit.

That works, and it takes as long as a support round-trip takes. Which is the argument for the whole next section.

What actually fills a volume#

In rough order of how often it's the culprit:

A log file your app writes. Frameworks that log to a file by default will grow forever unless you configure rotation. This is the single most common cause, and it's the one the pricing page's own example calls out — data that isn't tracked or rotated. Prefer logging to stdout, where the platform handles the capping.

A database that grows and never shrinks. SQLite doesn't return space to the filesystem when you delete rows unless you VACUUM. A journal or WAL file can also grow substantially under write load. Deleting a million rows can leave the file exactly as large as it was.

Caches and temp files nobody cleans. Downloaded files, generated thumbnails, scratch directories inside the volume. Each one is small and none of them are ever removed.

User uploads. These grow in proportion to your success, which means the problem arrives exactly when you least want it. If you accept uploads, know your ceiling from the start.

Backups written into the same volume. The trap in an otherwise good instinct. A nightly dump into the volume it's backing up doubles your growth rate and eventually trips the account limit — which then stops every app you own. Write backups somewhere else, as backing up your volumes sets out.

Staying ahead of it#

None of this is difficult, it just has to be decided once:

• Rotate anything you write. Size-capped and count-capped, so it has a maximum rather than a trajectory.
• Prune on a schedule. A weekly job in your existing background loop that deletes cache entries and old rows costs a few lines.
• VACUUM your SQLite occasionally if you delete a lot, or the file never gives the space back.
• Cap what you accept. A maximum upload size and a maximum retained count turn unbounded growth into a known number.
• Look at the Limits page now and then. It shows disk against your quota, and the useful moment to notice a trend is well before the ceiling.

The one number worth knowing is your growth rate. An app adding 50 MB a week is fine for a year; an app adding 50 MB a day has about ten weeks on a 5 GB limit. Same app, entirely different plan.

If you need more room#

Raising the account limit is a support request, and the disk rate is published at $0.25 per GB-month — the cheapest of the three resources by a distance. Buying headroom is not the expensive part of this platform.

But since disk is measured rather than allocated, a higher limit doesn't cost you anything until you actually use it. That makes headroom a reasonable thing to ask for early, and it makes ignoring a growing volume unreasonable — you're not paying for the space you haven't filled, so there's nothing to gain from running close to the edge.

FAQ#

What happens if I exceed the disk limit?#

Every application in the account is stopped and cannot be started until the total volume size drops back under the limit.

Does my Docker image size count toward disk?#

No. Disk usage is the total size of your volumes. A large image costs deploy time, not quota.

Can I choose how big a volume is?#

No. Volumes have no size you set — the platform measures what they actually contain, and that measurement is your usage.

How do I clear space if my apps are stopped?#

You can't from the panel — the shell and file browser need a running container. Ask support to raise the limit temporarily, then delete data and come back under.

What usually fills the disk?#

An unrotated log file, a database that never gives space back after deletes, uncleaned caches, uploads, or backups written into the volume they back up.

Do container logs use my disk quota?#

No. Anything printed to stdout goes to the platform's capped log capture. A log file written into a volume does count.

Wrapping up#

Disk is the quietest limit here and the least forgiving, because it's the only one where the consequence is account-wide rather than app-specific — a forgotten log file in one project can stop a bot that has nothing to do with it. It's also the easiest to never encounter: everything above comes down to making sure that every file your app writes has a maximum size, and that something deletes what you no longer need. Decide that once, on a calm afternoon, and this is a page you never need again.