Data & storage
Storage, disks and auto-growth
How databases and apps get a disk of their own, how it grows by itself, what happens at the limit you set, and exactly how storage is billed.
Your data gets a disk of its own
Every service that keeps data can have its own disk, separate from the server it runs on. That disk grows automatically while you use it, never fills the disk of another service, and is backed up on its own.
Databases get one automatically. Apps get one when you switch on persistent storage. You set the largest size each disk may grow to, so the bill can never run away from you, and you are billed for the size of the disk, per GB per month.
- Grows online, with no restart and no downtime
- Stops at the maximum you choose (your spending cap)
- Isolated: a full disk only affects its own service
- Billed at $0.15 per GB of disk per month
- Alerts in the dashboard bell and by email as it fills
Databases
Every new database, on a shared plan or on your dedicated server, is created with its own 2 GB disk. There is nothing to switch on: its data directory lives on that disk from the first write.
Databases created before disks existed keep their data where it is, on their server's disk, and keep working exactly as before. They move to a disk of their own when the database is next migrated to another server.
To see the disk or change how large it may grow, open the database, go to Settings → Scale → Storage.
Apps: persistent storage
An app's container is rebuilt on every deploy, so files it writes in normal folders disappear with the old version. Persistent storage keeps one folder, such as uploads, a SQLite file or generated reports, on a disk of its own that survives every redeploy.
It is opt-in: most apps keep their data in a database and never need it, and an app without it is never charged for storage. Templates whose whole purpose is keeping data (n8n, Flowise, Open WebUI, Langflow, LiteLLM and OpenClaw) start with it switched on.
- Open the app, go to Settings → Storage and choose the folder (default /data). The app also receives that path in the APP_DATA_DIR variable.
- Select Enable and redeploy. The deploy creates the disk and copies the folder's current files onto it; the app pauses briefly while they copy.
- If that deploy fails, nothing is lost: the copy is discarded and the previous version restarts on its original files.
- Turning it off deletes the disk and every file on it, after a confirmation. The app then redeploys with an empty folder.
- Deploys from the dashboard, from GitHub pushes and from `dilnaka up` all use the app's disk the same way.
How a disk grows
Disks are checked every few minutes. When one is 75% full and still below its maximum, it is enlarged while the service keeps running, and you are told how large it is now.
Each step adds half of the current size, at least 2 GB, and never passes your maximum. The storage provider allows one resize per disk every 6 hours, which is why the steps are generous rather than small.
Disks grow but never shrink. Deleting data frees space inside the disk, not size on the bill.
2 GB disk, 75% full, maximum 50 GB -> grows to 4 GB
10 GB disk, 75% full, maximum 50 GB -> grows to 15 GB
40 GB disk, 75% full, maximum 50 GB -> grows to 50 GBLimits by plan
Each disk starts with the default maximum for its plan. You can raise or lower it up to the plan's ceiling in the service's settings, but never below the disk's current size.
| Plan | Starting size | Default maximum | Most you can set |
|---|---|---|---|
| Free trial | 1 GB | 1 GB | 1 GB |
| Hobby | 2 GB | 5 GB | 5 GB |
| Pro | 2 GB | 50 GB | 250 GB |
| Dedicated | 2 GB | 100 GB | 1000 GB |
What happens at the limit
A database turns read-only when its disk is 98% full and cannot grow (it is at your maximum, or it filled faster than the next resize is allowed). It keeps answering reads, your data is safe, and writes are refused with a clear error instead of the database crashing. You are notified immediately.
Writes are allowed again as soon as it has room: raise the maximum, or delete data until it is below 90% full. It switches back on its own within a few minutes.
Read-only protection covers PostgreSQL, MySQL and MariaDB. Redis and MongoDB get the same alerts and growth, but no read-only switch.
An app's disk simply fills: the app can no longer save new files and gets a "disk full" error when it tries. Because the disk is its own, nothing else on the server is affected.
Dedicated server disks
The main disk of a dedicated server grows automatically too, for everything that lives on it: the operating system, your app images and services that do not have a disk of their own.
It grows up to a limit you set on the instance page (Storage → Change limit). The default is 2x the size the server was sold with, for example 80 GB on a 40 GB server, and you can set up to 2,000 GB.
Before growing, a server that reaches 90% full first deletes unused images and build cache, so you do not pay for space that old builds were holding.
- The size your server was sold with is included in its monthly price
- Only the GB added beyond it are billed, at $0.15 per GB per month (e.g. 40 GB grown to 60 GB adds $3.00/month)
Pricing
Storage is billed at $0.15 per GB of disk per month, on the size of the disk, not on how full it is. That is the same way the underlying storage is charged, and it keeps the price simple: a disk's cost only changes when it grows.
Charges appear on the Usage page as they accrue and are collected with the month's other usage. Within a month a charge never goes down: a disk deleted mid-month was still yours until then.
- 2 GB database disk: $0.30 per month
- 10 GB app disk: $1.50 per month
- 50 GB database disk: $7.50 per month
Alerts
You are told in the dashboard's notification bell, and by email, when a disk reaches 70%, 85%, 95% of the maximum you set, when it grows, when a database becomes read-only, and when it accepts writes again. Each alert links straight to the setting you need.
Alerts are measured against your maximum, not the current disk: a disk that grows on its own is not a problem, one that is approaching your cap is.
Backups
A database backup includes its disk. Restoring one brings up an isolated copy of the server with that database's data already in place, so your live database is never overwritten.
App disks are not backed up yet: apps have no backup feature today. Keep anything irreplaceable in a database or an external store until they do.
Good to know
- Disks grow but never shrink.
- Moving an app to another server starts it with an empty folder; its disk does not move with it.
- Databases created before disks existed stay on their server's disk until they are migrated.
- Storage is managed in the dashboard. The CLI deploys apps that use persistent storage, but has no storage commands yet.