News
What happened
1. Before you start: know what is changing Kubernetes Dashboard and Headlamp both show what is running in a cluster, but they work differently. When Headlamp runs on the desktop, it uses your existing kubeconfig to connect to one or more clusters and can be extended with plugins. When Headlamp runs inside a cluster, it uses a Kubernetes ServiceAccount to access the API and follow RBAC rules. Kubernetes Dashboard, in contrast, only runs in-cluster and always relies on service account tokens. Understanding these models early helps you choose the right setup and permissions. 1.1 How Kubernetes Dashboard works Dashboard is a web app that runs inside your cluster. You install it in the cluster, often with Helm. You usually run one Dashboard per cluster. You often reach it with kubectl port-forward or an ingress. You log in with a Bearer token. That token is often from a service account. It includes forms that help you create resources. It leans on tables and lists for navigation. It feels like this: a UI that lives with the cluster. 1.2 How Headlamp works Headlamp acts more like a Kubernetes client with a UI. It can run on your desktop or in a cluster. It reads your kubeconfig, like kubectl does. It can show more than one cluster in one place. It favors YAML when you create or change resources. It includes list views and a visual map. You can add features with plugins. Headlamp is a UI that follows your identity, not your cluster. 1.3 What stays the same Many workflows will feel familiar: Browse workloads and resources Filter by namespace Inspect YAML, events, and status View logs Take actions your RBAC allows 1.4 What changes A few things will feel different: Login shifts from pasted tokens to kubeconfig (and sometimes SSO). Creation shifts from forms to "apply YAML." Multi-cluster becomes normal, not a special case. The map view helps you see how resources connect. 2. Pre-migration checklist This checklist helps you avoid surprises during the switch. It makes sure Head
1. Before you start: know what is changing Kubernetes Dashboard and Headlamp both show what is running in a cluster, but they work differently. When Headlamp runs on the desktop, it uses your existing kubeconfig to connect to one or more clusters and can be extended with plugins. When Headlamp runs inside a cluster, it uses a Kubernetes ServiceAccount to access the API and follow RBAC rules. Kubernetes Dashboard, in contrast, only runs in-cluster and always relies on service account tokens. Understanding these models early helps you choose the right setup and permissions. 1.1 How Kubernetes Dashboard works Dashboard is a web app that runs inside your cluster. You install it in the cluster, often with Helm. You usually run one Dashboard per cluster. You often reach it with kubectl port-forward or an ingress. You log in with a Bearer token. That token is often from a service account. It includes forms that help you create resources. It leans on tables and lists for navigation. It feels like this: a UI that lives with the cluster. 1.2 How Headlamp works Headlamp acts more like a Kubernetes client with a UI. It can run on your desktop or in a cluster. It reads your kubeconfig, like kubectl does. It can show more than one cluster in one place. It favors YAML when you create or change resources. It includes list views and a visual map. You can add features with plugins. Headlamp is a UI that follows your identity, not your cluster. 1.3 What stays the same Many workflows will feel familiar: Browse workloads and resources Filter by namespace Inspect YAML, events, and status View logs Take actions your RBAC allows 1.4 What changes A few things will feel different: Login shifts from pasted tokens to kubeconfig (and sometimes SSO). Creation shifts from forms to "apply YAML." Multi-cluster becomes normal, not a special case. The map view helps you see how resources connect. 2. Pre-migration checklist This checklist helps you avoid surprises during the switch. It makes sure Headlamp can use the same identity and permissions you already trust in Kubernetes. It also gives you a quick way to prove the migration worked before you turn off Dashboard. 2.1 Write down what you use today List the basics: Which clusters you use (dev, staging, prod) Which namespaces you touch most What you do most often (view, edit, scale, delete, debug) How you access Dashboard today (port-forward or ingress) How you log in (service account token, and which RBAC bindings) This is your baseline. 2.2 Check that kubeconfig works Headlamp uses kubeconfig, especially on desktop. Make sure yours works before you install anything. Run: kubectl config current-context Then try: kubectl get nodes If you cannot list nodes, test in a namespace you can access: kubectl get pods -n If these work, Headlamp can use the same identity and RBAC. 2.3 Pick a rollout plan There is no need to rush. Most teams choose one of these: Parallel rollout (recommended) Install Headlamp Let people try it Keep Dashboard for a short time Remove Dashboard after the team is ready Cutover Install Headlamp Switch docs and links Remove Dashboard soon after Parallel rollout is safer for shared clusters. 2.4 Decide where Headlamp will run You can use either option. Many teams use both. Desktop Uses your kubeconfig Uses no cluster resources No port-forward needed Multi-cluster works out of the box In-cluster Works well for shared, browser access Can be managed like other cluster apps Often paired with ingress and SSO 2.5 Note optional dependencies These are common. You can handle them later. metrics-server (for CPU and memory graphs) ingress (for an in-cluster URL) OIDC / SSO (for browser sign-in) cleanup of old Dashboard service accounts and RBAC 3. Choose where Headlamp will run (desktop or in-cluster) Headlamp can run on your desktop or inside a cluster. Both work well, but they fit different needs. Desktop is the fastest way to start because it uses your kubeconfig and does not run in the cluster. In-cluster is best when you need a shared URL and want the platform team to manage upgrades and access. Option A: Desktop (user-managed) Desktop Headlamp runs on each user's machine. It reads the same kubeconfig you use with kubectl. This keeps access tied to each user's identity and RBAC. Why teams pick it No in-cluster service to deploy or expose. It uses no cluster CPU or memory. It uses your kubeconfig and RBAC. It works with many clusters in one app. You do not need port-forward for day-to-day use. Option B: In-cluster (best for shared access) In-cluster Headlamp is installed as a Kubernetes workload (often via Helm). This lets cluster admins manage it like other in-cluster apps. Cluster admins manage install, upgrades, and configuration through the Helm chart and standard Kubernetes tooling. Admins control ingress and can set up OIDC login for shared access. It supports shared use in team environments. 4. Install Headlamp (desktop and in-cluster) This section gets Headlamp running. Follow the path you chose in Section 3. 4.1 Desktop install (fastest way to start) Install Headlamp on your machine. Then open it like any other app. Headlamp reads your kubeconfig and uses the same identity and RBAC rules as kubectl. Windows Install with WinGet: winget install headlamp Or with Chocolatey: choco install headlamp macOS Install with Homebrew: brew install --cask headlamp Linux Install with Flatpak (Flathub): flatpak install flathub io.kinvolk.Headlamp Quick check Launch Headlamp. Confirm you can see a cluster context. Open a namespace you can access and confirm you can list workloads. Headlamp will only show actions your RBAC allows. 4.2 In-cluster install (shared access) Use this path when you want a shared UI that the platform team can manage. Headlamp supports in-cluster deployment with Helm or a YAML manifest. Install with Helm Add the repo and update: helm repo add headlamp https://kubernetes-sigs.github.io/headlamp/ helm repo update Create a namespace (example): kubect
Release at a glance
Key facts from the announcement.
Version
1.1
Source
Kubernetes Blog
PRIVACY STACK
Extend Privacy Beyond DNS
Controlling your DNS queries is one layer of network privacy. Your email metadata — who you talk to, when, how often — is equally exposed with standard providers. Proton Mail applies end-to-end encryption to the layer most people ignore.
Try Proton Mail →This is an affiliate link. If you purchase, I earn a commission at no extra cost to you.
Changes at a glance
What's new
1. Before you start: know what is changing Kubernetes Dashboard and Headlamp both show what is running in a cluster, but they work differently. When Headlamp runs on the desktop, it uses your existing kubeconfig to connect to one or more clusters and can be extended with plugins. When Headlamp runs inside a cluster, it uses a Kubernetes ServiceAccount to access the API and follow RBAC rules. Kubernetes Dashboard, in contrast, only runs in-cluster and always relies on service account tokens. Understanding these models early helps you choose the right setup and permissions. 1.1 How Kubernetes Dashboard works Dashboard is a web app that runs inside your cluster. You install it in the cluster, often with Helm. You usually run one Dashboard per cluster. You often reach it with kubectl port-forward or an ingress. You log in with a Bearer token. That token is often from a service account. It includes forms that help you create resources. It leans on tables and lists for navigation. It feels like this: a UI that lives with the cluster. 1.2 How Headlamp works Headlamp acts more like a Kubernetes client with a UI. It can run on your desktop or in a cluster. It reads your kubeconfig, like kubectl does. It can show more than one cluster in one place. It favors YAML when you create or change resources. It includes list views and a visual map. You can add features with plugins. Headlamp is a UI that follows your identity, not your cluster. 1.3 What stays the same Many workflows will feel familiar: Browse workloads and resources Filter by namespace Inspect YAML, events, and status View logs Take actions your RBAC allows 1.4 What changes A few things will feel different: Login shifts from pasted tokens to kubeconfig (and sometimes SSO). Creation shifts from forms to "apply YAML." Multi-cluster becomes normal, not a special case. The map view helps you see how resources connect. 2. Pre-migration checklist This checklist helps you avoid surprises during the switch. It makes sure Headlamp can use the same identity and permissions you already trust in Kubernetes. It also gives you a quick way to prove the migration worked before you turn off Dashboard. 2.1 Write down what you use today List the basics: Which clusters you use (dev, staging, prod) Which namespaces you touch most What you do most often (view, edit, scale, delete, debug) How you access Dashboard today (port-forward or ingress) How you log in (service account token, and which RBAC bindings) This is your baseline. 2.2 Check that kubeconfig works Headlamp uses kubeconfig, especially on desktop. Make sure yours works before you install anything. Run: kubectl config current-context Then try: kubectl get nodes If you cannot list nodes, test in a namespace you can access: kubectl get pods -n If these work, Headlamp can use the same identity and RBAC. 2.3 Pick a rollout plan There is no need to rush. Most teams choose one of these: Parallel rollout (recommended) Install Headlamp Let people try it Keep Dashboard for a short time Remove Dashboard after the team is ready Cutover Install Headlamp Switch docs and links Remove Dashboard soon after Parallel rollout is safer for shared clusters. 2.4 Decide where Headlamp will run You can use either option. Many teams use both. Desktop Uses your kubeconfig Uses no cluster resources No port-forward needed Multi-cluster works out of the box In-cluster Works well for shared, browser access Can be managed like other cluster apps Often paired with ingress and SSO 2.5 Note optional dependencies These are common. You can handle them later. metrics-server (for CPU and memory graphs) ingress (for an in-cluster URL) OIDC / SSO (for browser sign-in) cleanup of old Dashboard service accounts and RBAC 3. Choose where Headlamp will run (desktop or in-cluster) Headlamp can run on your desktop or inside a cluster. Both work well, but they fit different needs. Desktop is the fastest way to start because it uses your kubeconfig and does not run in the cluster. In-cluster is best when you need a shared URL and want the platform team to manage upgrades and access. Option A: Desktop (user-managed) Desktop Headlamp runs on each user's machine. It reads the same kubeconfig you use with kubectl. This keeps access tied to each user's identity and RBAC. Why teams pick it No in-cluster service to deploy or expose. It uses no cluster CPU or memory. It uses your kubeconfig and RBAC. It works with many clusters in one app. You do not need port-forward for day-to-day use. Option B: In-cluster (best for shared access) In-cluster Headlamp is installed as a Kubernetes workload (often via Helm). This lets cluster admins manage it like other in-cluster apps. Cluster admins manage install, upgrades, and configuration through the Helm chart and standard Kubernetes tooling. Admins control ingress and can set up OIDC login for shared access. It supports shared use in team environments. 4. Install Headlamp (desktop and in-cluster) This section gets Headlamp running. Follow the path you chose in Section 3. 4.1 Desktop install (fastest way to start) Install Headlamp on your machine. Then open it like any other app. Headlamp reads your kubeconfig and uses the same identity and RBAC rules as kubectl. Windows Install with WinGet: winget install headlamp Or with Chocolatey: choco install headlamp macOS Install with Homebrew: brew install --cask headlamp Linux Install with Flatpak (Flathub): flatpak install flathub io.kinvolk.Headlamp Quick check Launch Headlamp. Confirm you can see a cluster context. Open a namespace you can access and confirm you can list workloads. Headlamp will only show actions your RBAC allows. 4.2 In-cluster install (shared access) Use this path when you want a shared UI that the platform team can manage. Headlamp supports in-cluster deployment with Helm or a YAML manifest. Install with Helm Add the repo and update: helm repo add headlamp https://kubernetes-sigs.github.io/headlamp/ helm repo update Create a namespace (example): kubect
Breaking changes
No breaking changes were reported in the source material.
Analysis
In detail
1. Before you start: know what is changing Kubernetes Dashboard and Headlamp both show what is running in a cluster, but they work differently. When Headlamp runs on the desktop, it uses your existing kubeconfig to connect to one or more clusters and can be extended with plugins. When Headlamp runs inside a cluster, it uses a Kubernetes ServiceAccount to access the API and follow RBAC rules. Kubernetes Dashboard, in contrast, only runs in-cluster and always relies on service account tokens. Understanding these models early helps you choose the right setup and permissions. 1.1 How Kubernetes Dashboard works Dashboard is a web app that runs inside your cluster. You install it in the cluster, often with Helm. You usually run one Dashboard per cluster. You often reach it with kubectl port-forward or an ingress. You log in with a Bearer token. That token is often from a service account. It includes forms that help you create resources. It leans on tables and lists for navigation. It feels like this: a UI that lives with the cluster. 1.2 How Headlamp works Headlamp acts more like a Kubernetes client with a UI. It can run on your desktop or in a cluster. It reads your kubeconfig, like kubectl does. It can show more than one cluster in one place. It favors YAML when you create or change resources. It includes list views and a visual map. You can add features with plugins. Headlamp is a UI that follows your identity, not your cluster. 1.3 What stays the same Many workflows will feel familiar: Browse workloads and resources Filter by namespace Inspect YAML, events, and status View logs Take actions your RBAC allows 1.4 What changes A few things will feel different: Login shifts from pasted tokens to kubeconfig (and sometimes SSO). Creation shifts from forms to "apply YAML." Multi-cluster becomes normal, not a special case. The map view helps you see how resources connect. 2. Pre-migration checklist This checklist helps you avoid surprises during the switch. It makes sure Headlamp can use the same identity and permissions you already trust in Kubernetes. It also gives you a quick way to prove the migration worked before you turn off Dashboard. 2.1 Write down what you use today List the basics: Which clusters you use (dev, staging, prod) Which namespaces you touch most What you do most often (view, edit, scale, delete, debug) How you access Dashboard today (port-forward or ingress) How you log in (service account token, and which RBAC bindings) This is your baseline. 2.2 Check that kubeconfig works Headlamp uses kubeconfig, especially on desktop. Make sure yours works before you install anything. Run: kubectl config current-context Then try: kubectl get nodes If you cannot list nodes, test in a namespace you can access: kubectl get pods -n If these work, Headlamp can use the same identity and RBAC. 2.3 Pick a rollout plan There is no need to rush. Most teams choose one of these: Parallel rollout (recommended) Install Headlamp Let people try it Keep Dashboard for a short time Remove Dashboard after the team is ready Cutover Install Headlamp Switch docs and links Remove Dashboard soon after Parallel rollout is safer for shared clusters. 2.4 Decide where Headlamp will run You can use either option. Many teams use both. Desktop Uses your kubeconfig Uses no cluster resources No port-forward needed Multi-cluster works out of the box In-cluster Works well for shared, browser access Can be managed like other cluster apps Often paired with ingress and SSO 2.5 Note optional dependencies These are common. You can handle them later. metrics-server (for CPU and memory graphs) ingress (for an in-cluster URL) OIDC / SSO (for browser sign-in) cleanup of old Dashboard service accounts and RBAC 3. Choose where Headlamp will run (desktop or in-cluster) Headlamp can run on your desktop or inside a cluster. Both work well, but they fit different needs. Desktop is the fastest way to start because it uses your kubeconfig and does not run in the cluster. In-cluster is best when you need a shared URL and want the platform team to manage upgrades and access. Option A: Desktop (user-managed) Desktop Headlamp runs on each user's machine. It reads the same kubeconfig you use with kubectl. This keeps access tied to each user's identity and RBAC. Why teams pick it No in-cluster service to deploy or expose. It uses no cluster CPU or memory. It uses your kubeconfig and RBAC. It works with many clusters in one app. You do not need port-forward for day-to-day use. Option B: In-cluster (best for shared access) In-cluster Headlamp is installed as a Kubernetes workload (often via Helm). This lets cluster admins manage it like other in-cluster apps. Cluster admins manage install, upgrades, and configuration through the Helm chart and standard Kubernetes tooling. Admins control ingress and can set up OIDC login for shared access. It supports shared use in team environments. 4. Install Headlamp (desktop and in-cluster) This section gets Headlamp running. Follow the path you chose in Section 3. 4.1 Desktop install (fastest way to start) Install Headlamp on your machine. Then open it like any other app. Headlamp reads your kubeconfig and uses the same identity and RBAC rules as kubectl. Windows Install with WinGet: winget install headlamp Or with Chocolatey: choco install headlamp macOS Install with Homebrew: brew install --cask headlamp Linux Install with Flatpak (Flathub): flatpak install flathub io.kinvolk.Headlamp Quick check Launch Headlamp. Confirm you can see a cluster context. Open a namespace you can access and confirm you can list workloads. Headlamp will only show actions your RBAC allows. 4.2 In-cluster install (shared access) Use this path when you want a shared UI that the platform team can manage. Headlamp supports in-cluster deployment with Helm or a YAML manifest. Install with Helm Add the repo and update: helm repo add headlamp https://kubernetes-sigs.github.io/headlamp/ helm repo update Create a namespace (example): kubect
Why it matters
If you run self-hosted infrastructure, homelab services, or automation stacks, this update is worth tracking before you change production.
Homelab impact
If you run related services in your homelab, review whether this update affects your current deployment. Check compatibility with your Docker Compose files, reverse proxy config, or network setup before you upgrade production stacks.
What to do next
Practical steps for operators running self-hosted stacks.
This brief covers what you need from Kubernetes Blog's reporting. Visit the original post for release notes, changelogs, and full technical documentation.