Persistent Disks

By default, every service on Muerte Cloud runs on an ephemeral filesystem: anything written to disk at runtime is discarded the next time the service redeploys or restarts. A persistent disk gives one specific mount path durable storage that survives the container lifecycle.

Persistent disks are a good fit for:

• Self-hosted infrastructure (search indexes, message brokers, queues)
• Blogging platforms, CMS installations and wikis
• Collaboration apps with local uploads and attachments
• Custom datastores when the managed database offering doesn't fit

Disks use NVMe SSDs from the same hardware pool as our managed databases. All volumes are encrypted at rest, and so are their automatic daily snapshots.

Setup#

Before attaching a disk, review the limitations and considerations below — most notably that a disk pins the service to a single instance.

You can add a disk when creating a service (expand Advanced at the bottom of the form) or at any time later from the service's Disks tab in the dashboard.

1. 1
   Set a mount path

   The absolute path inside the container where the disk is mounted. Only writes under this path are preserved — the rest of the filesystem stays ephemeral. See Mount path.
2. 2
   Choose a size

   Start with the smallest size that fits your working set. You can grow a disk later at any time, but you cannot shrink it.
3. 3
   Save

   Muerte Cloud triggers a new deploy. The disk becomes available to your service as soon as the deploy is live.

Mount path#

The mount path is an absolute directory inside your container. Data written under it is durable; data written anywhere else is discarded on the next deploy or restart.

Pick a mount path based on how your app writes data:

• If your framework writes to a relative path (for example Rails ./storage for uploads), mount the disk at the absolute form of that path — or an ancestor of it.
• Otherwise, mount a standalone directory such as /var/data and point your app at it via an environment variable.

Typical mount paths per runtime:

Disallowed mount paths

These exact paths cannot be used as a mount root:

• / (filesystem root)
• /opt, /opt/muerte, /opt/muerte/project, /opt/muerte/project/src
• /home, /home/muerte
• /etc, /etc/secrets

Subdirectories of the above are allowed — for example, mounting at /opt/muerte/project/src/uploads works fine.

Monitoring usage#

Every service's Disks tab shows current used and free space, and a rolling chart of usage over time. Alerts fire automatically when a disk crosses 80% and 95% full so you can resize before running out.

Snapshots#

Muerte Cloud takes an encrypted snapshot of every persistent disk once every 24 hours. Snapshots are retained for at least seven days and can restore the disk to that point in time.

Trigger a restore from the service's Disks tab. The service is redeployed automatically once the volume is rehydrated from the snapshot.

Restoring a self-hosted database

If the disk backs a self-hosted database (MySQL, MongoDB, Postgres running in your own container), do not rely on disk snapshots for recovery. A raw block-level snapshot of an active database's data directory may restore to an inconsistent state.

Instead, run application-level backups on a schedule — for example mysqldump, mongodump or pg_dump — and write the archives to object storage or a separate disk.

Getting files on and off a disk#

Muerte Cloud does not provide SSH or an in-browser shell into your containers, so there is no interactive way to copy files onto a running instance. Plan file transfer through your application instead:

• Write an upload/download route in your own app that reads or writes under the disk's mount path.
• Seed initial data at build time by copying it into the image — remember the disk is only attached at runtime, not during the build.
• For recurring backups, restores or ad-hoc snapshots, use disk snapshots rather than trying to copy files by hand.

Limitations and considerations#