This page describes the split of responsibility between CoreWeave and you. CoreWeave operates the physical infrastructure, the managed control plane, the Node images and drivers, and the health and replacement of hardware. You operate your workloads, your data, and the components you install into your own cluster. Use this page to decide who owns a given problem before you spend time debugging it or open a support ticket.
For background on how CoreWeave runs each Node through its lifecycle, see Node lifecycle.
The short version
CoreWeave manages everything up to and including a healthy, validated Node with working GPUs, drivers, and high-performance networking. You manage everything you schedule on top of it. The boundary sits at the Node and the managed cluster components: below it is CoreWeave’s responsibility, above it is yours.
Responsibility by layer
The following table lists each layer of the stack and who owns it. “Shared” means both sides have a role, described in the notes.
Compute and the control plane
CoreWeave runs the CKS control plane as a managed service. CoreWeave owns the API server, etcd, the scheduler, and the controllers that keep the cluster healthy. You don’t patch, scale, or reconfigure the control plane, and you don’t modify the managed components CoreWeave installs into your cluster, because CoreWeave automation reconciles those resources back to their intended state.
You own your namespaces, your role bindings within the limits CoreWeave sets, your workloads, and any controllers or operators you install yourself.
Managed components compared to Helm-installed components
A frequent source of confusion is whether a given component is managed by CoreWeave or installed by you. The distinction decides who fixes it when it breaks.
- Managed components are installed and reconciled by CoreWeave. You shouldn’t modify them directly. If a managed component misbehaves, that’s a CoreWeave problem and a valid support ticket.
- Helm-installed components are installed by you, often from a CoreWeave Helm chart. You own their configuration and lifecycle. CoreWeave provides the chart and documents the safe configuration, but you run the release.
For example, Kueue on CKS is Helm-installed: you install it from the cks-kueue chart, and you own the queues and quotas you define. CoreWeave provides the chart and the guidance, but the running Kueue release is yours to operate. When a chart’s documentation tells you to use the CoreWeave-provided variant, follow it: the CoreWeave variant is configured to coexist with the managed control plane.
Nodes, images, and drivers
CoreWeave validates every Node before it reaches you and continuously monitors it afterward, from configuration at power-on through validation under test and into continuous production health checks. For the full phase-by-phase model, see Node lifecycle.
CoreWeave owns the Node operating system image and the GPU and network drivers. You choose when to roll out a published image and which driver version to pin per Node Pool, which lets you control change while CoreWeave keeps the underlying components supported. For driver pinning and image rollout, see GPU driver management and Apply Node updates.
GPU health and hardware replacement
CoreWeave detects GPU and hardware faults, cordons unhealthy Nodes so the scheduler stops placing new work on them, and replaces failed hardware automatically. You don’t file hardware RMAs yourself. For how cordoning works and what recovery looks like from your side, see Node cordoning and Node lifecycle.
Your responsibility is to make your workload resilient to a Node being cordoned or replaced: checkpoint regularly, tolerate Node loss, and avoid pinning a long-running job to a single Node.
Networking
CoreWeave owns the high-performance fabric: the InfiniBand and RoCE network, the switches, and the topology. CoreWeave exposes that topology to you through Node labels so you can place workloads, but you don’t operate the fabric. See InfiniBand and RoCE labels.
You own your in-cluster networking choices: your Services, your network policies, your DNS customizations, and any networking components you install. Tampering with the managed data plane, for example by rewriting host-level networking rules from a DaemonSet, is a common cause of self-inflicted connectivity failures.
Storage
CoreWeave provisions and operates the storage systems and provisions the volumes you request. You choose the storage product, request the capacity, and size it. The data inside your volumes and buckets is yours to manage: CoreWeave doesn’t organize, protect, or clean it up, and accesses customer data only as needed for critical operations. For the formal division of responsibility, see the Shared Responsibility Model and Security and compliance. For the products and how to choose between them, see Storage.
Common confusions
These are the most common sources of confusion:
- A managed component breaking is a CoreWeave problem, and a component you installed breaking is yours. Identify which it is before debugging.
- CoreWeave publishing a new driver or image doesn’t change your Node Pools automatically. You choose when to roll out. The exception is deprecated versions: when an operating system, kernel, or driver version reaches end of life, CoreWeave migrates Node Pools to a supported version for you. See GPU driver management.
- A cordoned Node is usually CoreWeave protecting your workload from unhealthy hardware, not a bug. The recovery path is automated.
- CoreWeave provisions storage capacity, but data hygiene, quotas, and cleanup are yours.
When to open a ticket
Open a support ticket when the problem is on a layer CoreWeave manages: the control plane, a managed component, Node or hardware health, the fabric, or storage provisioning. For problems on a layer you manage, start with the Support articles for your product. Either way, gather the evidence in the support ticket templates before you contact support. Last modified on July 15, 2026
