As you add an application to Kinsta, you can add persistent storage to the web process to create a stateful application.

Persistent storage adds a storage volume that retains data even if the application is restarted or redeployed. When you deploy an application at Kinsta with persistent storage, your application’s pod is connected to the persistent storage volume. If you redeploy the application, the application pod is rebuilt, but the storage volume remains untouched and is reconnected to the application pod once the deployment is complete.

With persistent storage, web processes are limited to one instance. You cannot add persistent storage to a background worker or cron job. There is no horizontal scaling for web processes, but you can vertically scale them by increasing the pod size for the process.

Add an Application With Persistent Storage

In the Resources step, when adding an application, you can add persistent storage to your web process. Under the Pod size field, click Disk to expand this section and complete the following to add persistent storage to your application’s process:

  • Mount path: Specify the location of the files to be added to persistent storage (e.g./var/lib/data). If you use Buildpacks or Nixpacks to set up your container image, you must prefix the location of the files with /app. For example, if your files are stored in wp-content/uploads, the mount path should be /app/wp-content/uploads. Note: This cannot be the root directory or the directory of any configuration files; a full list of invalid mount paths is shown below.
  • Size: Choose the disk size for your persistent storage volume. You can increase the disk size at any time (on the application’s Disks page), but you cannot downgrade the disk size once it has been created.

Continue with the remaining steps of adding an application. When you reach the payment step, you’ll see a separate line item for your persistent storage disk.

Invalid Mount Paths

The following mount paths are invalid because mounting data in these paths may cause issues in an application:

  • ‘/’,
  • ‘/app’
  • ‘/etc/’,
  • ‘/layers’
  • ‘/lib/’,
  • ‘/mnt/’,
  • ‘/root/’,
  • ‘/usr/local/’,
  • ‘/var/’,
  • ‘/workspace’

Note: You can start a mount path with the paths above; for example, /app/wp-content/uploads is a valid path.

View and Edit Persistent Storage Settings

To view disk usage and edit persistent storage settings, go to Applications > appname Disks. If your disk usage is below 1 MB, the usage will be shown as 0 usage.

To change the mount path or increase the disk size, under Actions, click the edit (pencil) icon for the disk you want to change.

Edit persistent disk space settings to change the mount path or increase the disk size.
Edit persistent disk space settings to change the mount path or increase the disk size.

You can increase the size of the disk, but you cannot downgrade the disk size. If you need less disk space for persistent storage, you’ll need to create a new application with the desired disk size.

Accessing Persistent Storage

To access and view files in persistent storage outside of your application, you can use the Application Web Terminal. If you use a Dockerfile to create your application, make sure Bash is installed in the container and is configured to access the Mount path.

You can also use the Application Web Terminal if you need to add files directly to the persistent storage disk outside of your application. For example, when moving from third-party storage or manually adding files that aren’t included in your application’s repo.

Currently, you cannot push data to the container. Instead, you’ll need to initiate a transfer from the container to pull the files to the disk with something like wget. First, make sure the method you want to use is available in the storage container. For example, to see a help message with options for wget:

wget -h

With wget, you can pull the files to the persistent storage disk with something like the following:

wget -O filename.tgz https://user:password@hostname/filename.tgz

Note: user:password@ is needed if the file is protected with basic HTTP authentication (htpasswd). Replace user and password with the actual user and password used for authentication.

This can also be run in a script, but the authentication details should be stored in environment variables rather than hard-coded in the script file.


We provide daily backups for persistent storage that are stored for 7 days and can be restored by request. When a backup is restored, all data in persistent storage will be rolled back to the time the backup was created.

To request a backup restoration, open a new chat with our Support team and ask for your persistent storage to be restored. Be sure to include your application’s name and persistent storage mount path in your request.

Only users with access to create an application can request a persistent storage backup to be restored. This means that you need to be the owner or company administrator in order to request a backup restoration.

Available Disk Sizes and Pricing

Persistent storage is available for an additional monthly fee, computed at $0.363/GB per month. You can choose from the following disk sizes:

10 GB$3/month
20 GB$6/month
50 GB$15/month
100 GB$30/month
150 GB$45/month
200 GB$60/month
300 GB$90/month
400 GB$120/month
500 GB$150/month
750 GB$225/month
1 TB$300/month

Was this article helpful?