Adding a disk
- Console
- slipway.yaml
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.
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 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. RaisingsizeGB 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. 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 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
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.
Only disks on slipway’s own cluster are billed. Disks on a cluster you
bring live on your storage.
Snapshots
Each disk keeps a numbered history, newest first. Manage it from the service’s Disks tab or the CLI:<service>-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.Seeding a copy
There is no separate base database to manage. The snapshot history is the durable lineage.- The first deploy brings the disk up empty.
- Load data by running your app or restoring a dump.
- Take a snapshot, from the Disks tab or
sw snapshot. - A cloned project gets its own isolated disk, seeded from the latest snapshot.
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.