Persistent disks: storage that survives a deploy
Add a persistent disk to a web service or worker on Voroa: pick a mount path and size, what survives a deploy, the one-copy rule, growth, backups and restore.
What this covers
A deployed service runs from a fresh copy of your code each time it is built, so anything the previous version wrote to its own filesystem is gone the moment the new version takes over. That surprises people who write uploaded files, a local database file, or a search index to disk and find them missing after a routine deploy. A persistent disk is storage attached to the service that survives deploys and restarts, so the same files are still there afterwards.
This page explains how to add one, what changes about the service once it has one, and how the disk is backed up.
Where the disk mounts
You choose a mount path - the folder inside your service where the disk appears, for example /data
or /app/uploads. Only files written under that path are kept. Everything else on the service’s
filesystem stays temporary and is replaced on every deploy, exactly as before.
A few paths are refused because the operating system or Voroa uses them: the root /, /etc,
/etc/secrets, /home, /usr, /var and similar system folders. A sub-folder of your own code
directory is fine. The path is fixed once the disk exists - to move your files, change your code to read
from the new location.
Adding a disk
Open the service, go to Disk, and under Persistent disk enter the mount path and choose Add disk. The plan page then asks for the size - 1 GB or any multiple of 5 GB - and shows the payment summary before anything is charged. The disk is priced per GB per month at the rate shown there.
Once the payment is confirmed the service is restarted with the disk attached. That restart is the first short gap described below.
A persistent disk is available on paid web services and background workers. Static sites have no process that writes files, and cron jobs run their tasks elsewhere, so neither can have one.
What changes once a service has a disk
Three things are part of the product, not side effects:
- A short gap on each deploy. Two copies of your service cannot write to one disk at the same time without corrupting it, so the running copy is stopped before the new one starts. The gap is the time your new version takes to boot. If the new version fails to start, the previous one is started again with the data untouched.
- One copy. A service with a disk cannot be scaled to more than one instance, for the same reason.
- Stays on its machine. The disk lives on the machine that runs the service, so the service is not moved between machines automatically.
Your build and pre-deploy command run on separate compute and cannot see the disk. Write files from the running service, not from the build.
Growing the disk
The size can be increased at any time from the plan page; it cannot be decreased. Growing happens live - the service keeps running and the new space is available within seconds. You are charged the prorated difference for the rest of the billing cycle.
Backups and restore
The disk’s contents are backed up once a day and kept for seven days. To restore, open a support ticket and tell us the service and the day to go back to. A restore replaces the whole disk with that day’s copy - any changes made after it are lost - so say so if you would rather have the files copied to a different path. Self-serve restore from the dashboard is not available yet.
Moving files in and out
If you have SSH access set up for the service, scp works against the mount path, because the shell
lands inside the running container where the disk is mounted. See SSH access.
When a managed database is the better choice
If what you are storing is relational data, a managed Postgres or MySQL database gives you backups, point-in-time recovery and connection pooling without a disk. If it is a cache or queue, a managed Key Value store does the same. A disk is for files: uploads, generated assets, a SQLite database your framework insists on, a search index.