---
title: "Persistent disks"
description: "Preserve a service's filesystem across deploys and restarts."
---

You can attach a disk to a web or worker service. Data written under the mount path
survives deploys, restarts and rescheduling. Everything outside it does not.

## Adding a disk
...

Good:  You can attach a disk to a web or worker service. Data written under the mount
       path survives deploys and restarts. Everything outside it does not.

Bad:   Persistent disks are how slipway gives your service storage that outlives a
       deploy. In this page we'll cover how to add one, how to size it, and what the
       limitations are.

Bad:   A database without a disk loses its data on restart, which is a bug shaped like
       a default.
Bad:   Only one service can mount a disk. That's deliberate: two writers on one device
       is how data gets corrupted.
Bad:   A service that needs more should have to say so rather than quietly running up
       your bill.

Good:  A database service requires diskSizeGB.
Good:  A disk can be mounted by exactly one service.
Good:  If you omit cpu, slipway uses 500m.

Bad:   A static site is a build artifact, not a process.
Bad:   Sleep is a scale-to-zero, not a teardown.
Bad:   The archive is a record, not a backup.

Good:  A static site has no container and no compute allocation.
Good:  Sleep scales a service to zero replicas. The project, its disks and its config
       are untouched.
Good:  The archive keeps the service's config and deployment history. It does not keep
       its disk contents.

Bad:   Two things worth knowing before you change them.
       - ...
       - ...

Good:  - ...
       - ...

Bad:   The template is a starting point, not a wrapper you're stuck inside.
Bad:   The lock is not the boundary. The API refuses independently.
Bad:   They aren't features you can unlock, they're features that don't apply.

Bad:   ## ports
       Ports the container listens on:

Good:  ## ports
       **Optional.** Ports the container listens on. Only `type: web` may declare them.

Bad:   Local sandboxes lie: a different kernel, a different libc, half your stack, none
       of your data.
Bad:   Postgres, MySQL, Mongo, SQLite-on-disk, a Lucene index, or a plain uploads folder.

Good:  Anything that writes to the filesystem and expects to read it back.

Bad:   A static site has no container, so there's nothing to pay for by the minute — you're
       only metered on bandwidth.
Good:  A static site has no container, so there is nothing to pay for by the minute. You
       are metered on bandwidth only.

Bad:   Slipway resolves the spec at deploy time.
Bad:   slipway resolves the spec at deploy time.   (sentence-initial)
Good:  The spec is resolved at deploy time.
Good:  At deploy time, slipway resolves the spec.

Good:  If you omit `cpu`, slipway uses `500m`.
Good:  **Optional.** If you omit this, the service name is used.
Bad:   | cpu | string | 500m |

## diskSizeGB

**Required, except on `redis`.** The disk size in GiB, from 1 to 1024. A database
without a disk does not retain data across restarts.

import Rates from '/snippets/rates.mdx';

<Rates />

<Warning>Do not commit secret values to `slipway.yaml`. Reference them with `${secret.NAME}`.</Warning>

<Tabs>
  <Tab title="Console">
    ...
  </Tab>
  <Tab title="slipway.yaml">
    ...
  </Tab>
</Tabs>

Bad:   This generally takes a few seconds.
Good:  This takes a few seconds. A service with a large image can take longer on its
       first pull.

flowchart LR
  a["Build"] e1@--> b["Deploy"]
  b e2@--> c["Healthy"]
  e1@{animation: slow}
  e2@{animation: slow}

classDef choice fill:#0D857714,stroke:#0D8577,stroke-width:1.5px
classDef result fill:#2DD4BF22,stroke:#0D8577,stroke-width:2px
class nodeA,nodeB choice
class nodeC,nodeD result

classDef bad fill:#dc262614,stroke:#dc2626,stroke-width:1.5px

### `403 Forbidden` on a working deploy

Your framework rejected the request's `Host` header. slipway records this as a
`public_host_rejected` event on the deployment.

Add the service's hostname to your framework's allowed-hosts setting:
...

## FAQ

**Does renaming a service keep its disk?**

**No.** A disk is bound to the service name. Renaming the service creates a new one and
archives the old.