> ## Content Index
> Fetch the complete content index at: https://skills.devopscube.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Kubernetes Client-side Vs Server-side Apply
- URL: https://skills.devopscube.com/kubernetes-client-side-vs-server-side-apply/
- Published: 2026-09-30T13:37:48.000Z
- Updated: 2026-10-13T05:18:11.000Z
- Author: Aswin Vijayan
- Tags: #tips, #tipcat-kubernetes, #template-no-img

Kubernetes offers two ways to apply changes to resources: Client-Side Apply (CSA) and Server-Side Apply (SSA).

Both can create or update resources from a manifest, but they handle the apply process differently.

![Kubernetes Client-Side Vs Server-Side Apply](https://storage.ghost.io/c/25/1a/251ae7d7-1d78-4128-b9cb-68a35ee6596c/content/images/2026/09/image-89.png)

Let's look at how these apply strategies work.

## Client-Side Apply

When you run kubectl apply, kubectl uses Client-Side Apply (CSA) by default.

Client-Side Apply means that **kubectl itself decides what needs to change** before sending the request to the Kubernetes API server.

To do this, kubectl compares three things:

- The manifest you are applying now
- The current resource running in the cluster
- Configuration that was applied previously.

Based on these three, kubectl determines what needs to be added, changed, or removed and sends the required patch to the Kubernetes API server.

Once applied, the **configuration will be stored inside the resource as an annotation**.

This is why it is called Client-Side Apply. Most of the **apply logic happens on the client side**, inside kubectl.

## Server-Side Apply

Server-Side Apply (SSA) works differently.

When you run kubectl apply with the **`--server-side`** flag, 

```bash
kubectl apply -f deployment.yaml --server-side
```

The **Kubernetes API server handles the apply process**. But the main advantage of Server-Side Apply is that it **tracks field ownership**.

💡

Field ownership means Kubernetes keeps track of which user, controller, or tool manages specific fields inside a resource.

For example, one controller may manage the container image, while another manages the replica count.

![](https://storage.ghost.io/c/25/1a/251ae7d7-1d78-4128-b9cb-68a35ee6596c/content/images/2026/10/image-93.png)

If two controllers try to apply different values to the same field, Server-Side Apply gives a conflict message instead of simply overwriting the other manager's value.

## Avoiding Configuration Conflicts with Server-Side Apply

SSA becomes useful when the same Kubernetes resource is managed by multiple systems.

For example, a Deployment may be updated by a GitOps tool, a Kubernetes controller, and an engineer using kubectl.

- With Client-Side Apply, kubectl primarily tracks what **you previously applied**.
- With Server-Side Apply, Kubernetes tracks **who manages each field**.

That makes it easier to detect conflicting changes and allows different tools or controllers to safely manage different parts of the same resource.

For simple workloads managed by one workflow, Client-Side Apply is usually straightforward.

When multiple controllers, automation tools, or teams manage the same resources, Server-Side Apply provides much better ownership and conflict handling.

⚠️

If you intentionally want to override a Server-Side Apply conflict, you can use the **`--force-conflicts`** flag. This overwrites the conflicting value and transfers ownership of that field to the manager performing the apply, so it should be used carefully.