Skip to main content
Volumes provide persistent storage for your deployments. Unlike container filesystem storage, data in volumes survives container restarts and can be shared between pods.

​
Why Use Volumes?

By default, data written inside a container is ephemeral—it’s lost when the container restarts. Volumes solve this by providing:
  • Persistence: Data survives container restarts and redeployments
  • Shared storage: Multiple containers can access the same data
  • Data integrity: Critical data like databases is protected

​
Volume Types

Orchard supports three types of volumes:

​
PersistentVolumeClaim (PVC)

The most common volume type. PVCs request storage from the cluster’s storage provider. Use cases:
  • Database storage (PostgreSQL, MySQL, MongoDB)
  • File uploads and media storage
  • Application state that must persist
Configuration:
FieldDescription
NameUnique volume name
PVC NameName of the PersistentVolumeClaim
Mount PathPath inside the container
Read OnlyWhether the volume is read-only

​
HostPath

Mounts a directory from the host node’s filesystem. Use cases:
  • Accessing host-specific files
  • Development and debugging
  • Node-level logs or metrics
HostPath volumes are not portable across nodes. If your pod moves to a different node, it won’t have access to the same data.

​
EmptyDir

Temporary storage that’s created when a pod starts and deleted when the pod ends. Use cases:
  • Scratch space for computations
  • Sharing data between containers in the same pod
  • Caching temporary files
EmptyDir data is lost when the pod terminates. Don’t use it for data that needs to persist.

​
Adding Volumes to a Deployment

​
During Deployment Creation

1

Create a new deployment

Start creating a deployment from image or GitHub.
2

Scroll to Volumes

Find the Volumes section.
3

Click 'Add Volume'

Configure your volume:
FieldDescriptionExample
NameUnique volume namedata-volume
TypeVolume typepvc
Mount PathContainer path/var/lib/data
PVC Name(for PVC type)my-pvc
4

Create

The volume will be attached when the deployment starts.

​
Adding to Existing Deployments

1

Open your deployment

Navigate to the deployment.
2

Go to Volumes tab

Click on the Volumes tab.
3

Add volume

Click Add Volume and configure the settings.
4

Save

The deployment will restart with the new volume attached.

​
Common Configurations

​
PostgreSQL Database

Volume:
  Name: postgres-data
  Type: pvc
  PVC Name: postgres-pvc
  Mount Path: /var/lib/postgresql/data
  Read Only: false

​
Redis Persistence

Volume:
  Name: redis-data
  Type: pvc
  PVC Name: redis-pvc
  Mount Path: /data
  Read Only: false

​
File Uploads

Volume:
  Name: uploads
  Type: pvc
  PVC Name: uploads-pvc
  Mount Path: /app/uploads
  Read Only: false

​
Shared Cache (EmptyDir)

Volume:
  Name: cache
  Type: emptyDir
  Mount Path: /tmp/cache

​
Volume Permissions

Some applications require specific user permissions on volume directories. Common issues:
  • PostgreSQL requires ownership by user postgres (UID 999)
  • Redis may need write permissions
  • Some apps need specific directory structures
If your application fails to write to a volume, you may need to:
  1. Run an init container to set permissions
  2. Configure security context in your deployment
  3. Use a Dockerfile that sets up the correct permissions
Contact your administrator if you need help with volume permissions.

​
Updating Volumes

To modify volume configuration:
1

Open Volumes tab

Go to your deployment’s Volumes tab.
2

Edit the volume

Click on the volume to modify.
3

Make changes

Update the mount path or read-only setting.
4

Save

The deployment will restart with the updated configuration.
Changing the PVC name will point to a different volume. Your existing data will not be accessible unless you change back to the original PVC.

​
Removing Volumes

To remove a volume from a deployment:
1

Open Volumes tab

Go to your deployment’s Volumes tab.
2

Find the volume

Locate the volume you want to remove.
3

Delete

Click the delete button and confirm.
Removing a volume from a deployment doesn’t delete the underlying PVC or data. The data remains and can be reattached later.

​
Best Practices

Always use PersistentVolumeClaims for any data that needs to survive restarts. EmptyDir is only for temporary data.
Use clear names like postgres-data or uploads-storage so it’s obvious what each volume contains.
Mount volumes at the paths your application expects. Check documentation for database-specific paths.
If your application only reads from a volume (like configuration), mount it as read-only for security.
Volumes provide persistence, not backup. Implement regular backups for critical data.

​
Storage Classes

PVCs can use different storage classes that provide different performance characteristics:
ClassCharacteristicsUse Case
StandardGeneral purposeMost applications
SSDHigh IOPSDatabases
ReplicatedMulti-zone redundancyCritical data
Available storage classes depend on your cluster configuration. Contact your administrator for available options.

​
Troubleshooting

If your volume doesn’t mount:
  1. Check that the PVC exists and is bound
  2. Verify the PVC name is spelled correctly
  3. Check pod events for mounting errors
  4. Ensure the storage class supports the requested access mode
If your application can’t write to the volume:
  1. Check that read-only is not enabled
  2. Verify your application user has write permissions
  3. Check security context settings
  4. Try running an init container to set permissions
If data disappears after restart:
  1. Verify you’re using a PVC, not emptyDir
  2. Check that the mount path matches where your app writes
  3. Ensure the PVC is not being deleted
  4. Check for multiple volume mounts at the same path
If the pod won’t start due to volume issues:
  1. Check if the PVC is bound
  2. Verify available storage in the cluster
  3. Check for scheduling conflicts (node affinity vs. volume location)

​
Next Steps

Environment Variables

Configure your application

Services

Expose your deployment to the network