# kubectl config use-context: Command Reference for CI/CD

> Reference for kubectl config use-context: switch the active kubeconfig context in CI, verify with current-context, and guard against wrong-cluster deploys.

Source: https://latchkey.dev/learn/command-reference/kubectl-config-use-context-command-cli-reference  
Updated: 2026-06-26

Select which cluster and user kubectl talks to.

kubectl config use-context switches the active context so subsequent commands hit the right cluster. In CI it is the first deploy step, and the one you should log to prove you are on the intended cluster. This reference covers it and its verification commands.

## Common flags and usage

- config use-context <name>: set the active context
- config get-contexts: list available contexts
- config current-context: print the active context (log this in CI)
- --context <name> on any command: override per-invocation
- Set KUBECONFIG to point at the credentials CI wrote

## Example

```shell
export KUBECONFIG=${{ runner.temp }}/kubeconfig
kubectl config use-context prod-cluster
kubectl config current-context   # log it: prove the target
kubectl get nodes
```

## In CI

A runner often has no ~/.kube/config, so set KUBECONFIG to the path you wrote credentials to, or pass --context per command. "no context exists with the name" means the context is not in the loaded kubeconfig. Echo current-context early so a wrong-cluster deploy fails loudly instead of silently hitting the wrong default namespace.

## Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

```Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### kubectl config use-context: Command Reference for CI/CD?

kubectl config use-context switches the active context so subsequent commands hit the right cluster. In CI it is the first deploy step, and the one you should log to prove you are on the intended cluster. This reference covers it and its verification commands.

### In CI?

A runner often has no ~/.kube/config, so set KUBECONFIG to the path you wrote credentials to, or pass --context per command. "no context exists with the name" means the context is not in the loaded kubeconfig. Echo current-context early so a wrong-cluster deploy fails loudly instead of silently hitting the wrong default namespace.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt