Shared Storage

When multiple replicas of an app need to access the same files (uploads, media, shared data), you need shared storage. Skipper provides two approaches.

MinIO (recommended)

MinIO provides S3-compatible object storage. Applications use the S3 API to read and write files. This is the modern approach and the one used by AWS, GCP, and most cloud platforms.

kip service add minio --name media --project yourr-name --environment prod

  Host:     media.yourr-name-prod.svc.cluster.local
  Port:     9000
  Username: skipper
  Password: a1b2c3d4...
  Endpoint: http://media.yourr-name-prod.svc.cluster.local:9000

Why MinIO is recommended

• Scales with any number of replicas: no filesystem contention
• Works with any S3-compatible SDK: AWS SDK, MinIO SDK, boto3
• Survives pod restarts: data stored independently from pods
• Web console included: browse and manage files at port 9001
• Standard approach: most modern apps and frameworks support S3 natively

Connecting your app

Bind the MinIO service to your app to inject credentials automatically:

kip service bind media my-app --project yourr-name --environment prod

This injects S3_HOST, S3_PORT, S3_USERNAME, and S3_PASSWORD into the app. Your code uses these to construct the S3 endpoint (http://${S3_HOST}:${S3_PORT}).

Common integrations

• WordPress: WP Offload Media or Media Cloud plugin
• Laravel: FILESYSTEM_DISK=s3 with MinIO endpoint
• Node.js: @aws-sdk/client-s3 with MinIO endpoint
• Django: django-storages with S3 backend
• Spring Boot: spring-cloud-aws or MinIO Java SDK

Shared Volumes

For apps that need a traditional shared filesystem (e.g. legacy apps that read/write files to disk), Skipper provides shared volumes backed by Longhorn with ReadWriteMany (RWX) access.

Use MinIO when possible

Shared volumes work but have limitations: NFS overhead affects performance, and they create a dependency between pods and the volume. MinIO is faster, more resilient, and the industry standard for multi-pod file sharing.

Create a shared volume

kip volume create uploads --size 10Gi --project yourr-name --environment prod

  ✔  Shared volume "uploads" created (10Gi)
  Access mode: ReadWriteMany (multiple pods can mount this)

  Mount into an app:
    kip volume mount uploads <app-name> --path /data/uploads

Mount into an app

kip volume mount uploads frontend --path /app/public/uploads --project yourr-name --environment prod

This mounts the shared volume at /app/public/uploads inside every pod of the frontend deployment. All replicas read and write to the same filesystem.

You can mount the same volume into multiple different apps:

kip volume mount uploads frontend --path /app/public/uploads
kip volume mount uploads image-processor --path /data/input

List shared volumes

kip volume list --project yourr-name --environment prod

  NAME                      SIZE       STATUS     ACCESS
  uploads                   10Gi       Bound      ReadWriteMany

Delete a shared volume

kip volume delete uploads --delete-data --project yourr-name --environment prod

The --delete-data flag is required to prevent accidental data loss.

Web console

Shared volumes can also be managed entirely from the web console via the Volumes page (HardDrive icon in the sidebar):

• Project selector: choose which project and environment to view
• Create: click "Create" to set a name and size for a new shared volume
• Mount: click "Mount" to attach a volume to an app. Select the volume and app from dropdowns, then enter the mount path
• View mounts: each volume card shows which apps have it mounted and at which path
• Disconnect: click "Disconnect" next to any mount to remove it from the app (the pod restarts automatically)
• Delete: remove the volume entirely

The Volumes page gives you a clear overview of which volumes exist, their status (Bound = ready, Pending = provisioning), and exactly which apps are using them.

Which approach to use

Criteria	MinIO (S3)	Shared Volume
Multi-pod access	Yes (via API)	Yes (via filesystem)
Performance	High (direct API)	Moderate (NFS overhead)
Scalability	Excellent	Limited by NFS
App compatibility	Needs S3 SDK/plugin	Works with any app
Survives pod restart	Yes	Yes
Use case	Modern apps, uploads, media	Legacy apps, WordPress without S3 plugin
Recommendation	Preferred	Use when S3 is not an option