Mount GCS Buckets as Volumes in Cloud Run (2026)

Cloud Run’s ability to mount Google Cloud Storage (GCS) buckets as volumes fundamentally changes how you manage persistent state in serverless containers.

Here’s how it looks in practice. Imagine a simple web application that needs to serve static assets or store user-uploaded files.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-gcs-app
spec:
  template:
    spec:
      containers:
      - image: gcr.io/my-project/my-app:latest
        ports:
        - containerPort: 8080
        volumeMounts:
        - name: my-gcs-volume
          mountPath: /app/data # This is where the GCS bucket content will appear inside the container
      volumes:
      - name: my-gcs-volume
        gcs:
          bucket: my-unique-gcs-bucket-name # The name of your GCS bucket

This configuration tells Cloud Run to make the contents of my-unique-gcs-bucket-name accessible within the container at the /app/data path. Your application code can then read from and write to this path as if it were a local filesystem.

The core problem this solves is the stateless nature of traditional serverless functions. Without persistent storage, each container instance is ephemeral. If it needs to access data that persists across requests or is shared between instances, it has to rely on external services like databases or object storage APIs. Mounting GCS buckets directly integrates this object storage into the container’s filesystem, simplifying access patterns and potentially improving performance for read-heavy workloads by leveraging the container’s local I/O.

Internally, Cloud Run uses a FUSE (Filesystem in Userspace) driver to expose the GCS bucket. When your application attempts to access a file within the mounted path, the FUSE driver intercepts the I/O request and translates it into GCS API calls. For reads, it fetches the object data from GCS. For writes, it uploads the data as a new object or overwrites an existing one in the bucket. This abstraction means your application code doesn’t need to know it’s talking to GCS; it just sees a file.

The primary lever you control is the mountPath within the container and the bucket name. You can mount multiple buckets to different paths within the same container, allowing you to organize your data logically. Permissions are handled by the service account your Cloud Run service runs as. This service account must have at least Storage Object Viewer (for read-only access) or Storage Object Admin (for read-write access) roles on the target GCS bucket.

It’s important to understand that while this feels like a local filesystem, the underlying operations are network-bound GCS API calls. This means latency can be higher than a true local disk, especially for small, frequent writes or reads. However, for larger objects and sequential reads, the performance can be quite good. Also, you’re not getting directory listings in the traditional sense; listing a directory involves iterating over objects in GCS that match a prefix. The FUSE driver handles this translation, but it’s a key difference from a local filesystem.

The next logical step is to explore how to manage concurrent writes to the same object when multiple container instances might be accessing the same bucket.