Storage Configuration

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.

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

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 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

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.

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.

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.

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

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

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

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.

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

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.

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

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.

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

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.

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

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