Storage and backup destinations

Container files can disappear when a container is replaced. Put data that must survive deployments in persistent storage, and back up data you cannot recreate.

Choose a mount

Applications and scheduled jobs expose mounts in their Storage section. Databases manage their data storage through their own database settings.

For example, mount a logical volume named uploads at /app/uploads. Your application writes to /app/uploads; it does not need to know Docker's host storage path.

Volume names in the ordinary application/job editor are scoped to that service. Naming two different services' volumes uploads does not make them shared. Compose import also requires each named volume to belong to one service; shared volumes between Compose services are unsupported. See Compose for its storage rules.

Volume options

Logical volume name identifies the service's volume. Container path is where the app sees it. Read-only allows reads but prevents writes through that mount. Removing the mount from configuration does not copy its data into the container or onto a replacement node.

Docker's local volumes belong to a node. For a service with persistent local data, choose a specific node in Placement. A similarly named volume on another node is different storage. Scaling replicas does not replicate the files; shared writable storage also requires an application and filesystem that support concurrent writers.

Host bind options

Host path must already exist on each node eligible to run the service. Container path is the destination inside the container. Use Read-only when the application should not modify the host files.

Bind mounts give a container direct access to the chosen host files. Upvale does not create, migrate, or delete those host paths for you. Use them when that access is intentional.

File options

File name identifies the mounted configuration. Container file path must include its filename, such as /app/config.yaml. File content supplies a read-only file, up to 500 KB in the editor. Save and deploy changes to replace it in the running workload.

Use Secrets for passwords and private keys rather than putting them in inline file content.

Inspect storage on a node

Open Fleet → cluster → node.

• Volumes lists volume names, drivers, scope, labels, and host mountpoints. Search by any of those values. This is an inventory, not a shared-storage provisioning screen.
• Images shows the node's image inventory and disk usage information.
• Files opens the server filesystem, subject to your permissions. Browse directories, show hidden files, upload/download, create folders, copy files, rename/move, or edit supported text files. Paths refer to the host, not a container's filesystem.
• Cleanup previews removable Docker objects before deletion. Select stopped containers, dangling images, build cache, unused networks, unattached anonymous volumes, or orphaned managed volumes. Unused images can be limited to 24 hours, 7 days, or 30 days; off excludes that category.

Changing cleanup options invalidates the old preview. Select Preview, inspect the categories and estimated bytes, then Reclaim. Active resources and unmanaged named volumes are protected. If the system cannot safely establish that a volume is unused, it may skip volume cleanup and show the reason.

Deleting files, folders, or a volume's data is not reversible through the file manager. Use the database backup workflow for live database data; copying its files while it runs is not an equivalent backup.

Add an S3 destination

An S3 destination stores the connection to an existing S3-compatible bucket. It does not create the bucket. You need Manage infrastructure to configure destinations.

1. Create a bucket and credentials with your storage provider.
2. Open S3 Destinations → New destination.
3. Fill in the fields below and select Add destination.
4. Select Test on the saved destination. Review Last test for the result.
5. Open a database's Backups tab and select this destination in its backup policy.

The destination's Test checks storage access; a successful full backup and a restore exercise the complete workflow. The cluster performing a backup or restore must also be able to reach the destination.

Credential rotation and retained backups

Use Edit to update the destination's credentials. If you change Access key ID, also enter its Secret access key. Backups refer to the destination; restore and cleanup use its current credentials, including for older backups. Give replacement credentials access to the old backup objects as well as new ones.

Connection/credential changes are blocked while an active backup or restore is using the destination. The endpoint and bucket cannot be changed while retained copies depend on them; create a new destination to move to a different bucket. Changing a prefix does not relocate existing objects.

Select Backups on a destination to see retained copies, including those left by deleted databases. The list identifies the database, creation time, and backup. Delete copy permanently removes that copy from S3. Follow the deletion operation and retry if it fails. Deleting the final copy means that backup can no longer be restored.

A destination cannot be deleted while active policies, work, or retained copies still depend on it. Update those policies and explicitly remove unneeded copies before removing the destination.

Backup and restore workflows

See Databases for policy schedules, retention, encryption, manual runs, restore targets, and engine-specific limits. HA replication keeps a service available when a member fails; it does not replace backups for accidental deletion or unwanted data changes.