Cloud Run can mount NFS volumes, but it’s not the magical shared filesystem you might expect.
Let’s see it in action. Imagine you have an NFS share on a Compute Engine VM, accessible at 10.128.0.2:/mnt/nfs_share. You want your Cloud Run service to read a configuration file from there.
Here’s how you’d configure it in your service.yaml:
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: my-nfs-app
spec:
template:
spec:
containers:
- image: gcr.io/my-project/my-app:latest
ports:
- containerPort: 8080
volumeMounts:
- name: nfs-storage
mountPath: /app/config # Where the NFS share will appear inside the container
volumes:
- name: nfs-storage
nfs:
path: /mnt/nfs_share # The actual path on the NFS server
server: 10.128.0.2 # The IP address of the NFS server
When this service is deployed, Cloud Run provisions a Compute Engine instance for your container. This instance then mounts the specified NFS share at the given mountPath. Your application code can then access files within /app/config as if they were local.
The problem this solves is enabling multiple Cloud Run instances to access the same persistent data without needing to copy it into each container image. This is common for shared configuration files, static assets, or data that needs to be updated dynamically.
Internally, Cloud Run leverages the underlying Compute Engine infrastructure. When you define an NFS volume, Cloud Run configures the managed VM to establish an NFS mount. This is not a direct, in-memory sharing mechanism between Cloud Run containers; rather, it’s a network filesystem mount from the VM that hosts your container.
The exact levers you control are the server IP address, the path on the NFS server, and the mountPath inside your container. You can also configure NFS mount options, though these are less commonly adjusted and typically handled by the Cloud Run provisioning.
Crucially, this setup implies that your NFS server must be accessible from the network where Cloud Run instances are provisioned. For VPC-native Cloud Run, this means the NFS server must be reachable within the configured VPC network. If you’re using the older, non-VPC-native mode, accessibility can be more complex and might involve public IP addresses or VPNs, which is generally discouraged for security reasons.
The most surprising true thing about this setup is that Cloud Run doesn’t directly manage the NFS mount itself; it delegates this to the underlying Compute Engine infrastructure that it provisions and manages for your service. This means you’re subject to the NFS client capabilities and networking configurations of those Compute Engine VMs.
The next conceptual hurdle you’ll face is managing the lifecycle and security of that NFS server, as Cloud Run itself only consumes the mount.