Persistent disks

An application's writable container filesystem is temporary. Use a persistent disk when files must survive normal container replacement, such as uploaded images, generated documents, or application-managed data files.

Managed PostgreSQL, MySQL, and Key Value services configure their own database storage. You do not need to add a general-purpose application disk to those services.

Supported servicesCopy Anchor Link

Persistent application disks are available on paid web services, private services, and background workers. Each service can configure one disk. Static sites, Free web instances, and cron jobs do not support this application-disk resource.

The application-disk configuration supports 5–1,000 GB. Disk capacity costs $0.25 per GB per month in addition to application compute. Review the complete quote before purchasing or changing billable capacity.

Add a diskCopy Anchor Link

Open the service's Disk page, add a disk name, choose its size, and enter an absolute mount path such as /var/data. Review any billing requirement and deploy to apply the mount.

Configure the application to write durable files inside that exact path. Files outside it remain temporary.

/var/data/
  uploads/
  generated-reports/

Do not mount over the entire application source directory or a system path. A volume mounted over a directory hides the image's files at that location, which can make application code or packaged assets appear missing.

Migrate existing filesCopy Anchor Link

Adding a disk does not automatically copy files from an old container, a cPanel account, or your computer. Export and preserve those files first, attach the disk at the intended path, and perform a controlled import.

For Laravel applications, account for the framework's storage paths and public storage link. See Laravel for application-specific guidance. Preserve existing application encryption keys when migrating encrypted data.

Deployment and scaling behaviourCopy Anchor Link

A disk belongs to a service; it is not shared storage that multiple independent services can mount. Services using persistent local storage cannot be treated as stateless, freely interchangeable replicas. Keep their replica configuration within Openstead's disk restrictions.

Changing a mount path can make existing files inaccessible to the application even though the data still exists at its original location. Plan path changes as a data migration and back up first.

Increasing a disk's allocation is different from moving or shrinking its data. Do not assume a plan downgrade shrinks a volume or deletes files. Review the current allocation and accepted quote.

Back up application files separatelyCopy Anchor Link

Openstead's managed database exports contain database data. They do not back up this upload directory. Arrange a separate export or copy process for important application files and test that it can restore them.

For applications that need shared uploads across many replicas, consider an external object-storage service and configure the application to use it. Do not rely on a single local disk as a shared multi-service object store.

TroubleshootingCopy Anchor Link

Files disappear after deployment: verify the application writes under the disk mount, rather than a similarly named directory inside the image.

Permission denied: check the application user and filesystem permissions. Avoid making sensitive files world-writable as a quick fix.

Application code is missing: check whether the mount covers a directory containing code from the image. Use a dedicated data path and migrate carefully.

A file upload exceeds capacity: inspect actual disk usage, remove data only after preserving what you need, and review a larger allocation.