Managing a Physical Display via Kubernetes

Why is my Raspberry Pi screen just another Kubernetes workload? And why I never want to manage kiosks any other way.

Building a Chromium Kiosk for Raspberry Pi (and Beyond)

For a long time, one thing in my infrastructure felt out of place.

I run Kubernetes clusters. I manage services declaratively. I deploy dashboards, monitoring, and internal tools using Helm.

But the physical screen connected to a Raspberry Pi?

That was still managed “the old way”.

Shell scripts. Manual SSH sessions. One-off configurations.

Another snowflake.

This article is about how I turned that screen into a Kubernetes workload.

Why I Wanted to Manage a Screen via Kubernetes

I have a Raspberry Pi 4 with 2GB of RAM connected to a physical display. Nothing fancy. No touch input. Just a screen sitting in my rack.

The purpose of that screen is purely informational.

It loads a homepage deployed inside my Kubernetes cluster (using gethomepage.dev) and shows things I care about.

The Raspberry Pi itself doesn’t hold any logic. It simply renders a web page.

At some point, I realized something obvious — and slightly annoying:

Everything behind that screen is managed via Kubernetes. The screen itself is not.

And I didn’t want yet another device in my infrastructure managed in a completely different way.

The Problem with Traditional Kiosk Setups

Most kiosk setups follow the same pattern:

• a full desktop environment
• systemd services
• ad-hoc shell scripts
• manual tweaks via SSH
• “don’t touch it, it works”

This approach works — until you want to:

• update behavior remotely
• redeploy from scratch
• move the device
• reproduce the setup elsewhere

In short, kiosks are usually treated as pets. I wanted mine to behave like cattle.

The Idea: Treat a Screen as a Kubernetes Workload

The key mental shift was simple:

The screen is dumb. Kubernetes is the brain.

The Raspberry Pi doesn’t need to “know” anything.

It just needs to run a browser in kiosk mode and point it at a URL.

So instead of managing the device directly, I asked myself:

• What if the browser was just another container?
• What if updates were just helm upgrade?
• What if the lifecycle was controlled by Kubernetes?

That idea became kubernetes-kiosk-chromium project.

Architecture Overview

The project consists of two main parts:

• a multi-architecture Docker image running Chromium in kiosk mode
• a Helm chart to deploy and manage it in Kubernetes

There is no desktop environment. No systemd. No background services pretending to be needed.

Chromium is treated as an application runtime — not as part of a Linux desktop.

All configuration is passed via container arguments and environment variables, making the behavior predictable and reproducible.

From Kubernetes’ point of view, it’s just another pod.

Chromium as a Runtime, Not a Desktop

This distinction is important.

I’m not trying to containerize a full GUI environment. I just want a browser that:

• starts automatically
• runs in kiosk mode
• opens a specific URL
• restarts when needed

By keeping the runtime minimal and controlled via an entrypoint script, the container behaves well inside Kubernetes.

No special cases. No hidden state.

Helm as the Control Plane for a Physical Display

This is where everything starts to feel natural again.

The kiosk is deployed as a standard Kubernetes Deployment. Its behavior is defined via values.yaml.

That gives you:

• declarative configuration
• reproducible installs
• simple upgrades
• clean rollbacks

Changing what the screen displays is no longer a manual operation. It’s just another Helm release.

Raspberry Pi, Edge Constraints, and Physical Integration

This setup currently runs on a Raspberry Pi 4 with 2GB of RAM.

That constraint influenced several design decisions:

• no full desktop environment
• minimal base image
• no unnecessary background services

However, Raspberry Pi was never meant to be a hard requirement.

The real goal of this project is to stay hardware-agnostic.

Anything capable of running Kubernetes and Chromium — whether it’s another SBC, a mini PC, or an old x86 box in a home lab — should be able to run the kiosk in exactly the same way.

How I Actually Use It Today

Right now, the kiosk loads a homepage hosted inside my Kubernetes cluster.

That page aggregates:

• storage status
• environmental metrics
• cluster health

Because it’s Chromium, the system is flexible by design.

If tomorrow I want to display Grafana, an internal tool, or a status page, I don’t need to rebuild anything. I just change the URL.

What Works Well Already

Even in its current develop state, several things are already solid:

• multi-architecture Docker images (amd64 and arm64)
• reproducible builds
• Kubernetes-native lifecycle
• Helm-based configuration
• edge-friendly resource footprint

The system is usable today.

Community Testing and Home Labs

This started as a personal engineering project, and that’s intentional.

That said, home labs are wonderfully diverse:

• different single-board computers
• old laptops and mini PCs
• various GPUs and display setups
• different Kubernetes distributions

Testing the kiosk in real-world home lab environments helps make it more flexible and less Raspberry-Pi-centric.

If you run Kubernetes at home and have a spare screen lying around, this project might be an interesting thing to experiment with.

Final Thoughts

Panel is under maintenance. New nice 3D print is on its way

This project didn’t start as a product.

It started as an irritation.

One physical device in my infrastructure didn’t follow the same rules as everything else.

By treating a display as a Kubernetes workload, that inconsistency disappeared.

And as a bonus, an old Raspberry Pi got a second life — without turning into yet another snowflake.

Source Code

The project is open-source and available on GitHub:

👉 https://github.com/yurymkomarov/kubernetes-kiosk-chromium

Feedback, issues, and testing results from different devices and home lab setups are very welcome.

P.S.

As part of my home lab setup, I also design 10-inch server rack 3D models for Raspberry Pi devices, which helps integrate small edge nodes cleanly into existing racks.

They’re not required for running this project, but they fit naturally into the same philosophy: treating small, physical devices as first-class citizens in a Kubernetes-driven environment.

If you’re interested, you can find the rack models here:

• 👉 **MakerWorld**
• 👉 **Printables**