Disks

Give an app a disk whose files stay across deploys and restarts, backed up every night.

What persists

An app's own files are thrown away whenever it restarts, deploys, sleeps or rolls back. A disk is the exception: files under its path stay. Everything else in the app's file system is still reset on restart.

Each app can have one disk of 5 GB. It is mounted at a path you choose, /data unless you say otherwise. Write files there, such as uploads or a SQLite database, and they are still there after the next deploy.

If every disk on the platform is in use, adding a disk is refused with no_disk_space; we are alerted and add room. An app whose disk waits for space shows Waiting for disk space and starts by itself once a disk is free.

$ deplane disks create my-app
$ deplane disks create my-app --path /srv/files

The path must be absolute and use lowercase letters, digits and . _ / -. It cannot be /, contain .., or be in a system folder: /proc, /sys, /dev, /etc, /bin, /sbin, /lib, /usr, /var/run or /run. See invalid_disk_path.

In the dashboard, open the app's Settings tab and find Disk: type the path and click Add disk. The same card lists the backups, with Back up now, Restore and Destroy disk. See Dashboard.

One instance

An app with a disk runs one instance. Two instances cannot safely write the same files, so:

• Adding a disk to an app that runs more than one instance, or autoscales, is refused. Scale it to one first: deplane scale 1 --max 0 --app my-app.
• With a disk, scaling above one instance and autoscaling are refused with disk_needs_one_instance. Stopping the app (deplane scale 0), changing its size and sleep still work.
• Each deploy stops the running instance before it starts the new one, so the app is down for a few seconds per deploy.
• Workers, cron jobs and pull request previews do not get the disk.

The disk lives on one server. If that server is down or under maintenance, the app waits for it to come back.

Backups

Every disk is backed up every night, at its own time between 01:00 and 05:00 UTC, and the backups are also copied off-site. They are encrypted. Each backup is a whole copy of the disk, so disk backups are kept 3 days (or your plan's backup window, if it is shorter), off-site for 7 days.

You can also back up a disk now, at most once an hour: deplane disks backup my-app. List backups with deplane disks backups my-app.

The newest backup that worked is kept even when it is older than 3 days. A backup fails, and says why in the list, if the app has not started with the disk yet, or if a file could not be read whole: it is unreadable (for example mode 000), or it changed size while the backup ran. Fix its permissions, or write such files somewhere else; the next night's backup tries again. A backup is also skipped if our backup storage is full: we are alerted, and the next backup tries again. If no backup has finished for 36 hours, your team gets a Disk backups are behind alert, unless the app has never started with the disk (there is nothing to back up yet).

Backups copy the files while the app keeps running. A file that changes during the copy, such as a busy SQLite database, may be caught half-written. For a copy you can rely on, use SQLite's own backup command (for example sqlite3 app.db ".backup /data/backup.db") to write a consistent copy onto the disk before the backup, or use a managed database, which is backed up continuously.

Restore

A restore replaces all files on the disk with a backup. Files written since that backup are lost.

$ deplane disks restore my-app dbk_…

Any backup marked done in the list can be restored.

The app stops while the restore runs and starts again when it is done. The app's Disk card in the dashboard, and last_restore in GET /v1/apps/APP/disk (see the OpenAPI description), show the latest restore: pending, running, done, or failed with why. A restore that has not finished after an hour fails. Restored folders always keep write permission for their owner (your app's user), even if they were read-only when backed up. If a restore fails, the app still starts again, but the disk may be empty: restore again from another backup, or email support@deplane.cloud. Restoring needs a confirmation in your browser with your passkey, every time.

Destroy

deplane disks destroy my-app deletes the disk and the files on it. It needs your passkey, every time. It waits for a restore under way: destroying is refused until the restore ends. Its backups are kept for 3 days.

Destroying an app destroys its disk too.

Limits

AI tools connected over MCP can list disks and add one, but cannot destroy, restore or back up a disk.

See CLI reference for every command.

This page is also available as Markdown. AI agents can start at /llms.txt.