2026-10-30 –, GUIX Language: English
What happens when your terminal setup grows from a few aliases into the place where real work happens?
This talk is a field report on building a CLI-native workbench container: a reproducible environment for my everyday terminal work (development, GitOps, tmux, zsh, Neovim and other small tools that make command-line work productive).
The focus is not the finished container, but the journey: why the environment exists, which design principles emerged, where the sharp edges were, and what changed along the way. We will look at context scaffolding, persistent environment folders, build-time Neovim problems, helper and tool discovery, and the balance between personal dotfiles and a shared toolbox that you can bring from home to work.
This is for every command-line cowboy how is or want to become in love with containers. From homelabbers, hackers, to platform engineers, linux admins and everyone who has ever thought: "I just want my shell, editor, credentials, and cluster tools to be reproducible without turning my laptop into snowflake infrastructure."
This talk tells the story of building a self-made framework for CLI-native workbench containers.
The starting point was practical work: homelabs with proxmox, vm etc. vs. OpenShift clusters, Argo CD, GitLab, jumphosts, kubeconfigs, SSH keys at work. The first instinct is familiar: install tools, tune dotfiles, add aliases, copy snippets, and keep moving. That works until the environment becomes private glue that is hard to reproduce, hard to explain, and easy to break.
The project became an experiment in treating a terminal workbench like a small product like unit:
private dotfiles = workshop
shared container = curated toolbox
context directory = per-environment state
The talk will cover the design principles that came out of that process:
- useful without private dotfiles
- Careless Docker vs. Podman-first and rootless-friendly
- one context directory per environment, cluster, project or customer
- persistent state through explicit folder scaffolding, not whole-home snapshots
- reconnectable work through tmux
- discoverable shell helpers instead of hidden magic
- Neovim as a prebuilt editor layer, not a runtime surprise
- enterprise-compatible details such as custom CA import
- keeping the image understandable while still useful
It will also cover the hurdles and course corrections:
- realizing that reproducible workbench folders needed scaffolding, not just
podman run - separating image content from mounted user and credential state
- fixing Neovim build-time bootstrap issues around plugins, Tree-sitter, Mason, and language tooling
- deciding what should persist and what should be refreshed with the image
- dealing with image size and build-stage boundaries
- making corporate CA import explicit and safe
- balancing personal workflow preferences with a reusable shared environment
The result is a Podman-launched workbench with zsh, tmux, Neovim/LazyVim, kubectl/oc, helm, argocd, glab, schema validation, helper functions, and a context launcher that creates reproducible environment layouts.
There may be a short demo, but the main focus is the development journey and the takeaways: how to think about CLI workbench containers, what to avoid, and which patterns are reusable even if you build your own stack completely differently.
- installed linux (ubuntu) the first time 15 years ago
- switched to arch 4 weeks later
- studied computer science without AI
- hate to take orders from machines
- learned kubernetes the hard way
- platform/devops teamlead @ Raitec GmbH
- H-J-K-L is my love language