USER STORY

Holger Kuehn and ZimaOS: A Story of Building, Sharing, and Growing Together

A community developer building practical layers around ZimaOS — from desktop access and scheduling to virtualization, networking, security and AI-powered system management.

A Note from Zima

Thank you, Holger, for building in public and for continuing to explore what ZimaOS can become from a community developer's point of view. Your repositories do more than add isolated features: together, they show how one person can keep finding new ways to make the same ecosystem more useful, more reachable, and more capable.

                                                                                                                                 — Zima

Meet Holger

Holger is a computer scientist with 40 years in IT. From Assembler and Fortran to C, C++, Go, and Java, he has worn many hats over the years: application developer, systems engineer, consultant, and Senior Solution Architect. He has worked with clients including DHL, Deutsche Post, Lufthansa, Volkswagen, and Deutsche Bundesbank, with credentials including VMware vExpert, MCP, and Oracle DBA.

He also ran his own business for many years, specializing in server and application virtualization with contracts through VMware. Since 2024, he has been officially retired — while still keeping two long-time clients happy with IT support.

His homelab is a multi-site setup built around UniFi networking, Proxmox virtualization, and ZimaOS running on ZimaCubes and ZimaBoards for NAS and Docker workloads. Everything is exposed securely through Pangolin, Gerbil, and Traefik on a Hetzner VPS, hardened with CrowdSec and interconnected through a WireGuard mesh.

Outside of that, Holger spends his time on AI development and flying single-engine aircraft. He is also an active ZimaOS contributor — known as Lintuxer on Discord and chicohaager on GitHub — building apps, tools, and MCP integrations for the IceWhale ecosystem.

Extending ZimaOS Virtual Machines

With ZVM-Extra, Holger adds another layer around ZimaOS virtualization: VM autostart, snapshots, USB and PCIe passthrough, backup and export, live metrics, network changes, remote storage, VNC security controls, and TPM support.

The interesting part is not the length of the feature list. It is that the project follows real operational edges: what happens when a VM needs to survive a reboot, when hardware needs to stay attached, or when a virtual machine needs tighter control over startup and host resources.

VM Extras autostart dashboard showing Linux Mint, Arch Linux and Fedora virtual machines on ZimaOS
VM Extras adds practical lifecycle control around ZimaOS virtual machines, including ordered autostart, delays, watchdog behavior, and direct power controls.
VM Extras PCIe passthrough interface listing host PCI devices available to attach to ZimaOS virtual machines
PCIe passthrough takes the project deeper into hardware-aware virtualization, exposing host devices that can be attached persistently to a VM.

Adding a Host Firewall to ZimaOS

Security becomes even more explicit in ZFW, Holger's host firewall for ZimaOS. The project adds a web interface, exposure information, rule management, Docker-port filtering, audit findings, and safeguards intended to make host firewall changes easier to understand and operate remotely.

ZFW Firewall rules page showing ZimaOS host, SSH, Samba, mDNS and Docker application rules
ZFW turns host and Docker exposure into a visible rule set, making it possible to review which services are allowed before changing the firewall state.

Experimenting with AI-Powered ZimaOS Management

Holger's ZimaOS MCP Server pushes the ecosystem in another direction. It explores Model Context Protocol as a way for compatible AI clients to interact with system operations such as shell commands, files, Docker, networking, ZimaOS apps, backups, and scheduled jobs.

This project reinforces the same pattern visible elsewhere in Holger's work: the interface can change, but the goal remains practical access to the system. Sometimes that interface is a desktop app, sometimes a web dashboard, sometimes a native system extension, and sometimes a protocol that lets another tool become the interface.

Making ZimaOS Feel Closer to the Desktop

Another major part of Holger's work focuses on bringing ZimaOS closer to the desktop. His ZimaOS Client desktop project brings ZimaOS into a Linux and macOS desktop workflow, with local discovery, remote connectivity, SMB/CIFS share access, Docker app access, scheduled backups, recent connections, diagnostics, and theme settings.

The project is a good example of Holger's approach: it does not replace ZimaOS. It sits beside it and makes the parts people already use easier to reach from another context.

ZimaOS Client remote connection screen with local network scan and Remote ID connection options
The ZimaOS Client connection screen centers the experience around reaching a ZimaOS system locally or remotely from the desktop.
ZimaOS Client Docker apps screen showing apps including Jellyfin, n8n, Immich and Files
Beyond connectivity, the client also becomes an entry point to Docker apps running on ZimaOS, showing how the project grew from access into everyday use.
Explore ZimaOS Client on GitHub

Going Deeper into Storage and Networking

Holger's work also operates much closer to the operating system itself. These projects work with native extensions, networking, storage, and persistent host configuration rather than only adding applications on top of ZimaOS.

Building Storage Around mergerfs and SnapRAID

Holger explored storage at the system-extension layer with the ZimaOS mergerfs + SnapRAID system extension. Its architecture separates the read-only extension binaries from persistent systemd units and configuration, while keeping the storage pool and parity roles explicit.

Architecture diagram for Holger Kuehn's ZimaOS mergerfs and SnapRAID system extension
The architecture diagram shows the separation between the read-only sysext, persistent systemd configuration, ZimaOS AppData, and the data and parity disks used by mergerfs and SnapRAID.

Native Tailscale with systemd-sysext

The ZimaOS Tailscale system extension packages Tailscale as a native systemd-sysext instead of treating remote networking as another Docker workload. It is a different kind of contribution: one that works closer to the host while still trying to make the system easier to operate.

Turning Routine Administration into Something You Can See

Another part of Holger's work focuses on jobs that usually disappear into terminals and config files. His Cron scheduler for ZimaOS reworks task scheduling around a web interface, persistent jobs, templates, execution logs, dependencies, priorities, and notifications.

That matters because recurring work is part of running a home server: backups, cleanup, health checks, Docker maintenance, certificate checks, and other small routines. The project turns that invisible layer into something a user can inspect and manage.

Cron scheduler dashboard for ZimaOS showing scheduled task management
The Cron dashboard makes scheduled ZimaOS tasks visible, giving recurring jobs a place where status, execution and maintenance can be reviewed.

The same "give the user a direct interface" idea appears in his dual-pane FTP, FTPS and SFTP client for ZimaOS. It is a smaller project, but it fits the same pattern: taking a familiar system task and making it easier to use from inside the ecosystem.

The Smaller Repositories Still Matter

Not every Zima-related repository on Holger's profile is a large standalone application. His public work also includes a fork of IceWhaleTech's Mod-Store, which sits closer to the extension and module ecosystem.

There is also CasaDrop, along with xpkg. These smaller repositories are useful as part of the record because they show experimentation at different layers, even when a project is not presented as a finished standalone tool.

Taken together with ZVM-Extra, ZFW, the MCP Server, the desktop client, storage and networking extensions, Cron, and file-transfer tooling, they help explain the bigger picture: Holger keeps working at different layers of the same ecosystem rather than repeating the same kind of project.

The Story Is Still Being Written

Holger Kuehn and Zima's story is still being written. As his projects change, mature, or lead to new experiments, this page can continue to grow with them. If you want to see what Holger builds next, follow Holger Kuehn's ongoing ZimaOS work on GitHub.