I built Devkeg: a desktop control center for your dev tools

Setting up a fresh developer machine is death by a thousand commands. You hunt down install
instructions, juggle apt, dnf, pacman, brew, and curl | bash, patch your PATH, and then
spend the next six months quietly fighting version drift. There's no single, friendly place that just
tells you what's installed, what's outdated, and how to fix it.

So I built one. It's called Devkeg — a desktop app that detects, installs, updates, and
uninstalls your developer and DevOps tools from one clean UI.

TL;DR — Devkeg is a Linux desktop app (Tauri + Rust + SvelteKit) that puts a GUI on top of
proven package managers (mise + your distro's) instead of reinventing installers. Open source:
https://github.com/jay-tank/devkeg.

The problem: your toolchain has no dashboard

Every other part of your stack has a dashboard — your cloud bill, your CI, your observability. But
the tools on your own machine live in a fog. Which are installed? Which are behind? The CLI tools
that manage this (mise, asdf, distro managers) are powerful but CLI-only and fragmented. There's
no visual control center. That's the gap Devkeg fills.

The one decision that shaped everything: orchestrate, don't reinvent

The tempting mistake is to write your own installers for 20+ tools — a bottomless pit of edge cases,
and every line a way to break someone's machine. Devkeg does the opposite. It's an orchestration
layer over proven backends: mise for languages/runtimes/tools in user
space, and your distro's package manager for system packages. Devkeg's job is the experience — not
reimplementing what mise and apt already do well. Every install path we don't write is a bug our
users can't hit.

Architecture

Adding a new tool doesn't touch the core — it's just a small TOML file (data, not code):

# registry/kubectl.toml
name        = "kubectl"
category    = "container"
detect_cmd  = "kubectl"
detect_args = ["version", "--client"]
backend     = "distro"

Why Tauri instead of Electron

The UI is web tech, so Electron was the obvious default. I didn't use it. For a developer tool,
footprint is a feature: a comparable Electron app ships ~120 MB and idles at 200 MB+ RAM; the
equivalent Tauri build is a ~4 MB binary on the system WebView. Shipping a bloated app to
manage other apps would be a bad look — and Tauri's Rust core gives safe subprocess handling for free.

Reliability: the boring guarantees that matter

• User-space first. Prefer mise (installs to ~/.local) so most actions need no root. When elevation is genuinely required, prompt explicitly via pkexec — never silently sudo.
• Verify everything. After each install/update, Devkeg re-detects the tool and confirms it runs, returning a structured result. No silent half-installs.
• Correct root detection. The elevation decision uses the real effective UID (geteuid()), not brittle environment guesses.

A lesson that cost me a rebuild: the glibc trap

I built the .deb on Ubuntu 24.04, it worked in my container, then refused to launch on Ubuntu 22.04:

devkeg: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.39' not found

glibc is forward-compatible, not backward — a binary built against 24.04's glibc (2.39) can't run
on 22.04's (2.35). The rule:

Build release binaries on the oldest distro you intend to support.

I moved the release build to Ubuntu 22.04 and pinned it in CI (runs-on: ubuntu-22.04) so the mistake
can't return.

Packaging and CI

Devkeg ships as a .deb and an AppImage, built by GitHub Actions. A v* tag triggers a
workflow that builds both on Ubuntu 22.04 and attaches them to the GitHub Release. Third-party actions
are pinned to commit SHAs.

What's next

v0.1 is the "control center": detect + install/update/uninstall across ~17 tools. Next up: environment
profiles with export/import, health checks and recommendations, a community plugin registry, then
macOS (the backends are already OS-isolated).

Try it

Devkeg is open source (MIT). Grab the .deb or AppImage from the releases page, or read the code:
https://github.com/jay-tank/devkeg. If you build developer tools, I'd love feedback on the
"orchestrate, don't reinvent" bet the whole project rests on.