Your containerized app just hit production scale, but someone asks, “Where’s the persistent volume?” If you are using Cloud Run, that’s a fair question. Stateless workloads thrive there. Stateful data? Not so much. This is where pairing Cloud Run with OpenEBS starts to look clever, not crazy.
Cloud Run handles the compute side like a pro. It runs containers directly on Google’s managed infrastructure, auto-scales them, and cuts idle costs. OpenEBS, on the other hand, brings dynamic persistent storage to Kubernetes clusters with container-attached volumes. Combine them, and you get a hybrid model where application logic runs on Cloud Run while storage management stays on a Kubernetes base powered by OpenEBS. You keep fast deployments without losing data durability.
Connecting Cloud Run and OpenEBS is less about wiring YAMLs and more about designing clean boundaries. You run Cloud Run services for front-end or API layers that call into back-end pods running on GKE or another Kubernetes cluster using OpenEBS. The shared secret, token, or identity gets validated through Google IAM or OIDC, and the data persists in OpenEBS volumes. Your Cloud Run app stays stateless, but the overall system behaves as if it’s stateful.
When done right, the integration feels like puzzle pieces snapping into place. Use role-based access control (RBAC) to restrict which services touch the storage layer. Rotate your service account keys through a Secret Manager rather than embedding them in the container image. If you see I/O delays, check the storage class and ensure the OpenEBS engine is set for the right performance mode—Jiva for lightweight replicas, Mayastor for high-speed NVMe.
This setup delivers real benefits:
- Persistent data for Cloud Run services without vendor lock-in.
- Stronger isolation between compute and stateful workloads.
- Automated recovery and portability using OpenEBS snapshots.
- Lower operational noise compared to maintaining a full VM stack.
- Predictable storage performance and compliance with SOC 2 or internal audit rules.
Developers love it because it fits the “deploy and forget” mindset. CI/CD stays simple, no manual volume provisioning, no mystery containers. Everything remains programmable, auditable, and fast to spin up. That means fewer Slack threads about “missing volumes” and more time shipping features.
AI copilots and automation agents also benefit here. When they query assets or logs, OpenEBS manages the data lifecycle cleanly, and Cloud Run ensures the responses stay ephemeral. It keeps training sets, prompts, or intermediate outputs away from risky persistence paths.
Platforms like hoop.dev take this one step further. They turn access policies and environment controls into guardrails that enforce who and what can reach those storage endpoints. Instead of managing dozens of credentials, you design one trust policy that follows your containers wherever they run.
How do I connect Cloud Run and OpenEBS?
You create a network or API link between a Cloud Run service and a Kubernetes cluster where OpenEBS runs. Authentication happens through Google IAM or your identity provider, and then requests route securely to the storage-backed microservice.
Can I store production data using this model?
Yes, if you treat the OpenEBS cluster as the persistent tier and keep Cloud Run for stateless workloads. It’s a stable architecture once you manage RBAC and storage replicas correctly.
With Cloud Run and OpenEBS, your stateless cloud functions and stateful data volumes finally learn to share a coffee table instead of fighting for it.
See an Environment Agnostic Identity-Aware Proxy in action with hoop.dev. Deploy it, connect your identity provider, and watch it protect your endpoints everywhere—live in minutes.