Where to Keep User Uploads When the Disk Is Small

Disk is the quietest way a working server becomes a broken one. Memory pressure is loud, processor load is visible, and a disk fills gradually until the database cannot write, the logs stop, and the application returns errors nobody can explain. On a virtual machine with a 60 GB disk and users who upload photographs, that day arrives sooner than the growth chart suggests.

This is the arithmetic for planning it, the four places uploads can live, and the honest boundary where a virtual machine is no longer the right container for your files.

Start with the real number, not the plan number

A plan disk is not storage capacity for user data. Subtract, in order:

• The operating system and packages, which is a few gigabytes.
• The application, its dependencies and any container images, which is often more than the application authors expect.
• The database, and enough free space to dump it and to rewrite its largest table. Plan for two to three times the live size at some point.
• Logs, until rotation kicks in, plus whatever a debugging session produces.
• Headroom, because a disk above about 85 percent behaves worse than a smaller disk with room.

What is left is your upload budget. On a Core with 60 GB, that is realistically 25 to 30 GB of user files before it gets uncomfortable.

What our plans and add ons give you

Plan	Plan disk	With 150 GB add on	Realistic upload budget
Ion	20 GB	170 GB	A few gigabytes on the plan alone
Pulse	40 GB	190 GB	15 GB on the plan alone
Core	60 GB	210 GB	25 to 30 GB on the plan alone
Forge	80 GB	230 GB	40 GB on the plan alone
Apex	100 GB	250 GB	55 GB on the plan alone
Titan	120 GB	270 GB	70 GB on the plan alone

Extra disk comes in 50 GB units at €4 per unit per month, up to three units on one machine. So 270 GB on a Titan is the hard ceiling for a single virtual machine here, and €12 a month of storage is usually far cheaper than jumping two plans for the disk alone. Plan prices per city are in the price by location breakdown.

The four places uploads can live

1. On the application disk

Simplest and correct for a long time. One machine, one backup, no moving parts. Sensible while total uploads stay well under the budget in the table, and while you are prepared to grow the disk with an add on rather than a migration. Serve the files through the web server rather than through your application process, so a large download does not occupy a request worker.

2. A second virtual machine as a file box

A small plan whose only job is holding files, with the application reaching it over an encrypted tunnel. Cheap, and it separates the growth curve of your files from the machine that runs your code, which means you can resize one without touching the other. The cost is that you now own two machines, two backups and a network path. Worth it when uploads are large but access is infrequent, for example invoices, exports or archives.

3. External object storage

We do not sell object storage, and for hundreds of gigabytes of user media with public read access that is the honest recommendation anyway. It scales past any single disk, it serves files without your server in the path, and it prices per gigabyte rather than per machine. The trade is a dependency outside your own infrastructure and, if residency matters to you, a provider choice that has to satisfy the same rules as your server. That question is covered in EU data residency without Germany.

4. Bare metal with real disks

When the files are the product, and the working set is measured in terabytes rather than gigabytes, the answer is a machine with its own drives. Our dedicated range takes far more storage than any virtual machine, in configurations quoted per chassis, and it takes it as physical disks you control the layout of. The comparison in VPS against dedicated servers covers the rest of that decision.

Six things that quietly eat the disk

1. Image derivatives. Three sizes per upload is four times the storage, not one and a bit. Generate on demand and cache with an expiry if space is tight.
2. Old database dumps. A nightly dump kept forever is a slow disk leak. Keep a rotation and push copies off the machine, which is the point of automating backups.
3. Container images and build caches. Layers accumulate silently. A weekly prune is less painful than a full disk.
4. Logs without rotation. Especially application logs that nobody configured, as opposed to the system ones that rotate by default.
5. Soft deleted records. Files whose database row is gone but whose bytes are not. A reconciliation job pays for itself.
6. Temporary upload directories. Interrupted uploads leave fragments that nothing ever cleans.

Alert on disk usage and on the growth rate, not just the level, so you find out in the week before it matters rather than the hour after. Where to run that alerting is the subject of monitoring from another city.

Two things that are not backups

A second copy on the same disk is not a backup. A replica or a synced copy is not a backup either, because a deletion replicates perfectly. Uploads need their own backup with a retention window, and it needs restoring occasionally to prove it works. Restoring onto a machine rented by the hour is the cheap way to test that: a Forge is €0.0389 an hour in Frankfurt or Vienna, so a two hour restore drill is under nine cents, and deleting the machine afterwards stops the charge.

Where to start

Work out today's upload total and its monthly growth. If twelve months of growth fits in the plan disk plus one or two storage units, keep the files where they are and set a disk alert. If it does not, decide now between object storage and bare metal rather than migrating twice. Plans and the storage add on are on the VPS page, and if you want a second opinion on which of the four options fits, reply with your current total and your monthly growth and we will give you a straight answer.