Storage Configuration

Fuzzball V4 uses storage provisioners to manage storage. A provisioner combines a built-in storage driver with access policies in a single configuration — there is no need to install separate storage drivers or create storage classes as in V3.

Note

On fresh installations, Fuzzball may automatically create a default provisioner based on your deployment configuration. Check fuzzball volume provisioner list before creating one manually.

For detailed reference on provisioner configuration, see the Volume Configuration and Management section. This page covers the basic setup needed to get storage working on a new cluster.

select

On-Prem

AWS

GCP

CoreWeave

OCI

Select your deployment type to see storage configuration instructions.

For on-prem deployments, you will likely want to create an NFS provisioner that manages volumes as subdirectories on an NFS export. In addition, you may also want to create hostpath provisioners for shared storage systems mounted on compute nodes.

NFS Storage Configuration

Prerequisite: Create NFS Shares

First, create directories that will be served as NFS shares. On the server node (or the node serving your NFS shares):


# PRIVATE_SUBNET="" # populate this with the proper value for your environment (e.g. 10.0.0.0/20)


# mkdir -pv /srv/fuzzball/storage

# echo "/srv/fuzzball/storage ${PRIVATE_SUBNET}(rw,sync,no_subtree_check,no_root_squash)" \
  >>/etc/exports

# exportfs -a

# exportfs

Tip

It is not necessary to mount the NFS share on compute nodes. Fuzzball's built-in NFS driver handles mounting automatically when volumes are used in workflows.

Create the NFS Provisioner

Create a provisioner definition file:


$ NFS_SERVER_IP="" # fill in the value of your NFS server IP address (e.g. 10.0.0.4)


$ cat >nfs-provisioner.yaml<< EOF
default:
  description: "Default NFS storage"
  driver:
    type: nfs
    target: "${NFS_SERVER_IP}:/srv/fuzzball/storage"
    version: 4
  access: all
  create: all
  ephemeral: all
EOF

Apply the provisioner:


$ fuzzball volume provisioner add default -f nfs-provisioner.yaml

$ fuzzball volume provisioner list
ID                                   | NAME    | STATUS | CREATED TIME          | LAST UPDATED          | CLUSTER
80e204ec-ee2f-3485-9282-33f77a9a3318 | default | Ready  | 2026-05-28 09:32:24PM | 2026-05-28 09:32:24PM | local-dev

Warning

Many of the CIQ templates in the Workflow Catalog expect a provisioner named default. Keep this name unless you have a specific reason to change it.

AWS EFS Storage Configuration

For AWS deployments, Fuzzball's built-in EFS driver creates and manages volumes as EFS access points. On a fresh AWS deployment, Fuzzball typically bootstraps a default EFS provisioner automatically.

Check for Automatic Provisioner

After deployment, check if a default provisioner was created:


$ fuzzball volume provisioner list

If a default provisioner exists and is in Ready status, storage is configured and you can skip to Next Steps.

Manual EFS Provisioner Setup

If no default provisioner exists, create one manually. You can use either BYO mode (provide an existing EFS filesystem ID) or self-provisioned mode (provide subnet IDs and let Fuzzball create the filesystem):

BYO mode — use an existing EFS filesystem:


$ cat >efs-provisioner.yaml<< 'EOF'
default:
  description: "Default EFS storage"
  driver:
    type: efs
    filesystemId: fs-XXXXXXXX
    region: us-east-1
  access: all
  create: all
  ephemeral: all
EOF

Self-provisioned mode — Fuzzball creates the EFS filesystem:


$ cat >efs-provisioner.yaml<< 'EOF'
default:
  description: "Default EFS storage"
  driver:
    type: efs
    region: us-east-1
    subnetIds:
      - subnet-XXXXXXXX
      - subnet-YYYYYYYY
  access: all
  create: all
  ephemeral: all
EOF

Warning

Replace placeholder values (fs-XXXXXXXX, us-east-1, subnet IDs) with actual values from your AWS deployment. Provide filesystemId or subnetIds, not both.

Apply the provisioner:


$ fuzzball volume provisioner add default -f efs-provisioner.yaml

$ fuzzball volume provisioner list

GCP NFS Storage Configuration

For GCP deployments, Fuzzball uses the NFS driver to connect to a Filestore instance or other NFS-compatible storage.

Check for Automatic Provisioner

After deployment, check if a default provisioner was created:


$ fuzzball volume provisioner list

If a default provisioner exists and is in Ready status, storage is configured.

Manual NFS Provisioner Setup

If no default provisioner exists, create one pointing to your NFS or Filestore endpoint:


$ cat >nfs-provisioner.yaml<< 'EOF'
default:
  description: "Default NFS storage"
  driver:
    type: nfs
    target: "10.171.0.2:/workflowio"
    version: 3
  access: all
  create: all
  ephemeral: all
EOF

Apply the provisioner:


$ fuzzball volume provisioner add default -f nfs-provisioner.yaml

$ fuzzball volume provisioner list

Preview Status

Support for CoreWeave within Fuzzball is in preview status and is currently subject to more rapid change than other features. Contact CIQ as part of your deployment planning.

CoreWeave Storage Configuration

For Fuzzball on CoreWeave, use a hostpath provisioner backed by the shared-vast PVC mounted on substrate nodes at /mnt/shared-storage.


$ cat >cw-provisioner.yaml<< 'EOF'
default:
  description: "CoreWeave shared-vast storage"
  driver:
    type: hostpath
    path: /mnt/shared-storage/volumes
  access: all
  create: all
  ephemeral: all
EOF

Apply the provisioner:


$ fuzzball volume provisioner add default -f cw-provisioner.yaml

$ fuzzball volume provisioner list

Note

CoreWeave's shared-vast storage requires Native Protocol Limit view policy. Ensure this is configured before deployment. For additional CoreWeave storage options, see the CoreWeave Configuration Guide.

OCI File Storage Configuration

For OCI deployments, Fuzzball uses the OCI File Storage Service (FSS) driver.

Check for Automatic Provisioner

After deployment, check if a default provisioner was created:


$ fuzzball volume provisioner list

If a default provisioner exists and is in Ready status, storage is configured.

Manual FSS Provisioner Setup

If no default provisioner exists, create one. Use BYO mode to attach an existing FSS file system and mount target:


$ cat >fss-provisioner.yaml<< 'EOF'
default:
  description: "Default OCI File Storage"
  driver:
    type: oci_fss
    region: us-ashburn-1
    compartmentId: ocid1.compartment.oc1..aaaaaaaa
    availabilityDomain: "Uocm:US-ASHBURN-AD-1"
    filesystemId: ocid1.filesystem.oc1.iad.aaaaaaaa
    mountTargetId: ocid1.mounttarget.oc1.iad.aaaaaaaa
  access: all
  create: all
  ephemeral: all
EOF

Or use self-provisioned mode to have the driver create the file system and mount target from subnetIds. Apply the provisioner:


$ fuzzball volume provisioner add default -f fss-provisioner.yaml

$ fuzzball volume provisioner list

Note

For the full set of OCI FSS fields and the BYO-vs-self-provisioned distinction, see Driver Types.

Verify Storage

After creating a provisioner, verify it is working by scanning for any pre-existing volumes:


# fuzzball volume provisioner scan default --dry-run

Next Steps

At this point, you have successfully configured storage for your Fuzzball cluster. You can move on to configuring some initial entities.

Basic Provisioner Configuration Initial Entity Management