Storage

Every environment starts on its machine's own disk. When that is not enough, you buy a volume — a separate disk the provider attaches to the machine — and move your files onto it.

#Two halves of one disk

Your environment's disk is in two parts, and which part filled up decides what you do about it.

Your files. Uploads, private files, and any directories your vallic.yaml asked for. This half can move onto a volume, and growing it is a purchase.

They are stored under names we choose rather than your framework's: public for whatever your application serves, private for what it keeps behind an access check, and mounts/ for anything your vallic.yaml declared. Your code still sees its own paths — a Drupal site still writes to web/sites/default/files — but on the disk, in a backup, and in the figures below, it is public.

The servers' own data. The database's files, a search index, a message broker's queues. This half stays on the main disk, and growing it means a bigger machine.

How much of it you may keep is set by your plan's memory, not by how much disk happens to be free. A database is fast when the rows it keeps asking for are already in memory; one much larger than the machine's memory is reading from disk for a growing share of its queries, and it gets slower the bigger it grows. So a 4 GB machine allows 20 GB of server data, an 8 GB machine 50 GB, and so on. The console shows where you are against it.

Buying storage does not raise that number. The database always stays on the machine, so a database that has outgrown its machine needs a bigger machine or one of its own.

#Dividing it between services

If your site runs more than one thing that keeps data — a database and a search index, say — you can give each a share of the allowance. The storage page then reports each against its own share instead of lumping them together, so when something grows you can see which one it was.

That matters because the answers differ. A database that has outgrown its share needs a bigger machine. A search index that has outgrown its share can often be reindexed, or given a disk of its own. A single total cannot tell you which situation you are in.

The shares have to add up to no more than the allowance — budgets that each look healthy while the disk fills would be worse than having none. You can leave some unallocated, and you can leave a service out entirely, in which case it is measured against the whole allowance as before.

These are budgets, not limits. Nothing stops a service growing past its share; what a share buys you is being told which one did.

The database always stays on the machine. Everything else that fills a disk can be moved onto one of its own.

#What can have its own disk

Each of these can be given a disk of its own, from the environment's Storage tab, one row at a time:

• Public files — what the site serves
• Private files, and with them your declared mounts
• A search index, if it has outgrown the machine and you accept that searches get slower
• A queue

The database always stays on the machine. Services that keep nothing worth keeping — a cache, a proxy — are not offered a disk either, since they rebuild themselves from nothing.

#The machine's own disk

On a Regular machine the root disk comes with the machine type. It is local storage, it is the fastest disk there is, and it only changes by moving to a different type — which is downtime. See Machines.

On a Cloud Native machine the root disk is a volume of its own. You pick the size when you configure the project — from 10 GB up, priced as its own line — and grow it later without moving the machine. It pauses briefly while the filesystem is extended; you are not changing machine type and not repricing anything else.

The size you pick is the size you get. The volume underneath is larger, because the machine keeps room for the OS, the images, the journal, the releases kept for rollback and the database dumps held before they go offsite — but that is the platform's arithmetic, not a subtraction from what you bought.

That is the whole difference between the two, and it is chosen beside the datacentre when the project is set up.

#Buying more room

A disk is priced by the 5 GB block, and the rate per block falls as the disk grows. Sizes run from 10 GB: fives to 50 GB, tens to 100 GB, then fifties to 1 TB. On the Storage tab, choose Own disk… on the bucket's row and pick a size. The first size offered is the smallest that holds what is budgeted for that bucket, because a disk has to be at least as large as what it is about to take over. The disk is made straight away and shows under Disks while the provider attaches it; from then on it is on your monthly bill by the block.

The disk arrives empty. Moving what is there onto it is a separate step — see below — because the site stops while the copy runs.

A disk that filled up is the one storage problem with an answer that does not touch your files. Choose Grow on the volume, pick a bigger size, and the disk grows underneath the running site — nothing unmounts, nothing restarts, and no files move.

It happens in two parts, a few minutes apart:

1. The disk itself grows at the provider, and your new size is what you are billed from then on.
2. The filesystem on it grows to match, on the machine's next reconcile. Until that happens df still reports the old figure.

This is the opposite of resizing the machine itself, which does require stopping it.

Disks only grow. A disk cannot be shrunk — the filesystem on it does not know it is about to lose the blocks its files are on — so a size you pick is a floor for the rest of that disk's life.

#Moving data between disks

Buying a disk does not move the data. The two are separate on purpose: remounting under a running site would make every file vanish from the site's point of view without moving a byte, and it looks exactly like the uploads were deleted.

Moving is its own action, per bucket: Move data… on the row once the disk is ready. It stops the stack, copies that bucket's directory, verifies the copy, and only then mounts the disk in its place. Nothing is deleted by the move — the old copy stays where it was, so a move that went somewhere unexpected is a mount away from being undone rather than a restore from backup. Freeing that space is a separate, confirmed step under Left behind.

#When an environment is deleted

Its disks go with it. A disk on a machine that goes too is removed with the machine; one on a machine that stays — one that also carries your other environments — is unmounted there and destroyed. Nothing is kept for a grace period and billing stops at deletion, so anything you need from the files belongs in a backup or a download before you delete.

#What disk usage counts

The figures shown for an environment cover everything that is actually on disk, and they are reported apart rather than as one total:

• public files — uploads, anything served to visitors
• private files — anything behind an access check
• the database
• releases — your code, once per release kept for rollback
• application logs — whatever your code writes to /var/log/app

The database surprises people. A database is a file on a disk like anything else, and an environment whose usage looked healthy while its database quietly filled the machine is the outage these numbers exist to prevent.

Application logs are the one figure with a limit rather than a budget, and they are not counted towards the storage you are assigned. The limit is a tenth of the storage the environment is assigned, between 100 MB and 20 GB; past it the oldest files are removed, and never the one being written. See Logs.

They are kept apart because a single total would not tell you what to do. Your files growing and your database growing have different answers — buy storage, or take a bigger machine — and only the separate figures say which one you are looking at.

#Shared storage

On the Dedicated shape, with two or more web machines, files cannot be local — an upload landing on one web machine does not exist on the other. So the shared directory is served from one machine to the others over the private network, never the public one, and the machines write as their own environment's user rather than as root.

This is set up for you. What it does not do is change your application: if the code writes to a local path instead of the shared directory, shared storage cannot help it. See Shapes.

#Next

Back to Start here, or Software stacks for what runs on top of all this.

Backups covers what is copied off the machine, and Logs what your containers write.