Persistent storage, add-ons and volumes

Containers can be replaced during a deploy, rebuild or restart. Files written only to a container’s temporary writable layer can therefore be lost. Use a persistent volume for files the application must keep, or a managed add-on for database and object data. See the PaaS guide and cloud containers .

Choose a storage type

Persistent volumes: Store uploads, media and other files at a path mounted into the service. The mount path must match the path where the application writes.
Managed add-ons: Use a managed database or service such as PostgreSQL, Redis, MinIO, RabbitMQ, MariaDB or MongoDB when its data model fits the application. Add-ons have their own lifecycle and are connected to services through generated variables. See cloud databases .

Managed add-ons

An add-on runs separately from the application service. Binding it to a service supplies connection values such as DATABASE_URL or REDIS_URL as environment variables. Use separate add-ons for production and test environments when their data must remain separate.

Create the add-on in the right environment

Check the add-on’s name, type, version and project environment before connecting it.

Bind it to the service

Choose the add-on in the service settings and configure the application to read the variable names it provides.

Check the connection and run migrations

Confirm the application connects by checking its runtime logs. Run schema migrations deliberately; do not let several replicas run the same migration concurrently unless the migration tool handles that safely.

Review available backups and test a restore

For supported managed add-ons, open the add-on’s Backups view to review the available nightly snapshots and restore status. The dashboard supports restoring PostgreSQL, MariaDB and MongoDB add-ons; other add-on types may show backups without offering this restore control. Before restoring, review the selected snapshot time: restoration replaces current data. Test recovery with a suitable non-production copy where possible, and keep any separate backup you rely on outside the add-on.

Nightly snapshots are available for supported managed add-ons. They are not a substitute for checking that a backup exists and that your recovery process works. A restore overwrites current data; review its confirmation and status in the dashboard.

Persistent volumes

A volume mounts persistent storage into a service at a path such as /app/uploads or /var/www/html/wp-content/uploads. Ordinary container replacement during a deploy or restart is designed to leave volume data available to the service. Deleting a service or its volume can remove that data, so keep a separate copy of anything important.

Volume capacity is managed by the platform: a new volume starts small and can grow as it fills. You do not choose a custom size in the service settings. Growth is limited by both the service limit and the package’s total storage allowance across the zone. Hobby includes 10 GB in total per zone package; Pro includes 40 GB. These are shared limits, not an additional allowance for each service. Plan your volumes within the accepted package limits.

Browse and transfer volume files with the CLI

The CLI browses directories and transfers individual files. If the service has more than one volume, select one with its mount path or ID.


# List files at a mount path; omit the path to list from the volume root
deplomo service files my-app /app/uploads
 
# Download one file from a volume
deplomo service pull -o ./photo.jpg my-app /app/uploads/photo.jpg
 
# Upload one local file to a directory in a volume
deplomo service push --dir /app/uploads my-app ./photo.jpg
 
# Select a particular volume when the service has more than one
deplomo service files --volume /app/uploads my-app /app/uploads

pull and push transfer a single file each. For a large collection or a database, use an application-appropriate backup and restore method. The CLI file manager does not create a volume snapshot or a complete service backup.

Before moving or deleting files, stop the process that writes to them and keep a separate backup. A volume helps files persist across ordinary service deployments; it does not provide version history or guarantee recovery after deletion or corruption.

Match the storage to the data

Data	Suitable storage	Recovery check
Temporary files and caches	Container temporary storage	The application can recreate the data after a restart.
User uploads and application files	Persistent volume	Keep a separate copy and test restoring needed files.
Structured application records	Managed database add-on	Review available snapshots and test the restore process.
Object files	Object storage add-on, when available for the project	Check its own backup and recovery requirements.

Keep storage healthy

Check used volume space and the package limit in the dashboard. A service cannot grow its volume past the hard limit for its package.
Keep database files in a database add-on rather than copying or editing its data directory through the volume file manager.
For large file moves, stop writers first and verify the copied files before removing the originals.
Keep backups separate from the workload they protect, and periodically verify that you can restore them.