> ## Documentation Index > Fetch the complete documentation index at: https://docs.slipway.sh/llms.txt > Use this file to discover all available pages before exploring further. # Disks > Give a service storage that survives deploys, restarts and rescheduling. A disk is persistent storage attached to one service. Data written under the mount path survives deploys and restarts. Everything outside it does not. Disks require the Hobby plan or higher. See [Plans](/plans). ## Adding a disk **Console** Open the service's **Disks** tab and add one. For a managed database, the disk is created with the mount path already correct for the engine. **slipway.yaml** ```yaml slipway.yaml theme={"system"} version: 1 services: - name: uploads runtime: docker disk: mountPath: /var/lib/app/uploads sizeGB: 10 ``` | Field | Type | Required | Notes | | - | - | - | - | | `mountPath` | string | **Required.** | Absolute path inside the container. Cannot be `/`. | | `sizeGB` | int | **Required.** | Whole gigabytes, 1 to 1024. Your plan sets the ceiling. | `disk:` is not valid on `type: cron`, which has no resident workload to own it, or on `type: static`, which has no container. Both are rejected at parse time. ## One disk per service A service gets at most one disk, and no two services share one. A disk is a single block device, so a service with a disk also runs a single pod: `replicas` above 1 is rejected, and so is a `scaling` ceiling above 1. When two services need the same data, use a database or [object storage](/data/object-storage) that both talk to. ## Sizing A disk can grow but never shrink. To grow one, open the service's **Disks** tab, expand the disk and choose **Resize**. The new size applies to the running disk: the filesystem grows in place and nothing restarts. A replicated database grows every member's disk. The storage charge moves to the new size at the same moment. Raising `sizeGB` in the spec does not grow a disk that already exists; resize it from the Disks tab. A spec value below the disk's current size is ignored rather than shrinking it. Start with the smallest size that serves the workload plus some room, and grow it when it fills, or let auto-grow do it. ## Auto-grow Turn on **Grow automatically** on the disk's row in the Disks tab and slipway grows the disk in place when it passes 80% full, or earlier if its recent growth would fill it within a day. Each grow sizes the disk so it lands around 60% full, with room for three more days at the rate it has been filling. Nothing restarts, and you get a notification saying what it grew to. Set **Up to** to cap how large it may get. Left empty, the cap is 1024 GB. Auto-grow is off by default because it spends money without a click; it respects your spend limits like any other change. While auto-grow has room, a filling disk never raises a [usage alert](/observability/usage-alerts). Once it reaches its cap, or a grow fails, the alert fires as usual. ## When a disk fills Without auto-grow, slipway alerts at 80% full, escalates at 90%, and alerts earlier when a disk's recent growth would fill it within three days. A database whose disk fills stops accepting writes, so treat these as urgent. To see how full a disk is, the mounting service's [Metrics tab](/observability/metrics) charts disk usage against its size over time. It charts the *filesystem*, so a 20 GiB disk reports slightly under 20 GiB of capacity. The difference is filesystem overhead. ## What storage costs | What | Rate | | - | - | | CPU | \$8.76 per vCPU per month | | Memory | \$4.38 per GiB per month | | Disk | \$0.25 per GiB per month | | Volume backups | \$0.05 per GiB per month | | Object storage | \$0.05 per GiB per month | | Egress beyond the plan allowance | \$0.01 per GB | Compute is metered by the second against the allocation a service is configured with, so a service that sleeps costs nothing while it is asleep. Disk, backups and object storage are metered on what is provisioned or held, whether or not the service is running. Storage is billed on **provisioned** GiB, not on bytes written, because the space is reserved and replicated whether or not you have filled it. A 20 GiB disk costs 20 GiB from the moment it exists. A disk keeps costing while it exists, including when nothing is deployed against it, since a disk outlives the deployments that mounted it. Delete the ones you no longer need. Track it on **Settings → Usage** and see [Billing](/organization/billing). > [!NOTE] > > Only disks on slipway's own cluster are billed. Disks on a [cluster you > bring](/clusters/byok) live on your storage. ## Snapshots Each disk keeps a numbered history, newest first. Manage it from the service's **Disks** tab or the CLI: ```bash theme={"system"} sw snapshot --volume db-disk --note "seed data" # capture the live disk sw snapshots --volume db-disk # list history sw restore --volume db-disk --snapshot 3 # revert in place ``` A service's disk is addressed as `-disk`, so the disk on a service named `db` is `db-disk`. `sw restore` reverts a live disk to an earlier snapshot in place: the service scales down, the contents swap, and it comes back. Same name, same URL, different bytes. A safety snapshot of the current state is taken first, so the revert is itself undoable. ## Scheduled backups A disk can back itself up on a schedule. Turn backups on from its **Backups** panel, then choose the cadence (hourly, every 6 or 12 hours, daily, or weekly) and how many days of history to keep. Databases created from the **New** menu arrive with backups already on. Retention is measured in **days**, not in a number of backups, so it means the same thing whichever cadence you choose. Keep 7 days and you get seven days of history, whether that is 7 backups or 168. Your plan sets the longest window you can ask for, and lowering it prunes rather than errors. Backups past the window are removed, manual ones included, because they share one history. The backup marked as the seed default is never removed, whatever its age. Backups are billed on what they occupy in object storage, at a lower rate than live disk, so a long history of a mostly unchanged disk costs far less than the disk itself. Turning backups off stops the charge and the schedule, and the backups you already have stay restorable. > [!WARNING] > > slipway backs up whatever is on the disk. Sensitive data ends up in every copy seeded from > that backup. Sanitise it on the way in. ## Seeding a copy There is no separate base database to manage. The snapshot history is the durable lineage. 1. The first deploy brings the disk up empty. 2. Load data by running your app or restoring a dump. 3. Take a snapshot, from the Disks tab or `sw snapshot`. 4. A [cloned project](/projects/overview) gets its own isolated disk, seeded from the latest snapshot. The first snapshot is manual, because a new disk is empty. After that a schedule can take over. A destructive migration in one copy never touches another. Seeding is a block-level copy, so slipway does not need to understand the engine. Postgres, MySQL, a search index or a plain uploads folder all snapshot and restore identically. ## Limitations * **Snapshots need snapshot-capable storage.** On a cluster without it, disks still work and **Snapshot now** reports that it cannot run rather than failing silently. * **One replica.** A service with a disk runs a single pod. * **Per-repo lineage.** Snapshot history belongs to a `(repo, disk)` pair. Sharing snapshots across repos is not available. * **No anonymisation tooling.** Sanitise data on the way in. ## Appendix: glossary | Term | Meaning | | - | - | | Mount path | The absolute path inside the container where the disk appears. Only data written under it persists. | | Provisioned size | The capacity reserved for the disk, which is what you are billed for, as opposed to the bytes actually written. | | Snapshot | A point-in-time copy of a disk, restorable in place or usable to seed a clone. | | Seed default | The snapshot a cloned project's disk is created from. Never pruned by retention. | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.