<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: TANK JAY</title>
    <description>The latest articles on DEV Community by TANK JAY (@jaytank).</description>
    <link>https://dev.to/jaytank</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4052286%2F56811edd-09f3-4c20-b966-2b3d5e9b71ef.jpg</url>
      <title>DEV Community: TANK JAY</title>
      <link>https://dev.to/jaytank</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/jaytank"/>
    <language>en</language>
    <item>
      <title>I built Devkeg: a desktop control center for your dev tools</title>
      <dc:creator>TANK JAY</dc:creator>
      <pubDate>Wed, 29 Jul 2026 04:01:57 +0000</pubDate>
      <link>https://dev.to/jaytank/i-built-devkeg-a-desktop-control-center-for-your-dev-tools-mg2</link>
      <guid>https://dev.to/jaytank/i-built-devkeg-a-desktop-control-center-for-your-dev-tools-mg2</guid>
      <description>&lt;p&gt;Setting up a fresh developer machine is death by a thousand commands. You hunt down install&lt;br&gt;
instructions, juggle &lt;code&gt;apt&lt;/code&gt;, &lt;code&gt;dnf&lt;/code&gt;, &lt;code&gt;pacman&lt;/code&gt;, &lt;code&gt;brew&lt;/code&gt;, and &lt;code&gt;curl | bash&lt;/code&gt;, patch your &lt;code&gt;PATH&lt;/code&gt;, and then&lt;br&gt;
spend the next six months quietly fighting version drift. There's no single, friendly place that just&lt;br&gt;
tells you &lt;em&gt;what's installed, what's outdated, and how to fix it.&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;So I built one. It's called &lt;strong&gt;Devkeg&lt;/strong&gt; — a desktop app that detects, installs, updates, and&lt;br&gt;
uninstalls your developer and DevOps tools from one clean UI.&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; — Devkeg is a Linux desktop app (Tauri + Rust + SvelteKit) that puts a GUI on top of&lt;br&gt;
proven package managers (&lt;code&gt;mise&lt;/code&gt; + your distro's) instead of reinventing installers. Open source:&lt;br&gt;
&lt;strong&gt;&lt;a href="https://github.com/jay-tank/devkeg" rel="noopener noreferrer"&gt;https://github.com/jay-tank/devkeg&lt;/a&gt;&lt;/strong&gt;.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;h2&gt;
  
  
  The problem: your toolchain has no dashboard
&lt;/h2&gt;

&lt;p&gt;Every other part of your stack has a dashboard — your cloud bill, your CI, your observability. But&lt;br&gt;
the tools &lt;em&gt;on your own machine&lt;/em&gt; live in a fog. Which are installed? Which are behind? The CLI tools&lt;br&gt;
that manage this (&lt;code&gt;mise&lt;/code&gt;, &lt;code&gt;asdf&lt;/code&gt;, distro managers) are powerful but CLI-only and fragmented. There's&lt;br&gt;
no visual control center. That's the gap Devkeg fills.&lt;/p&gt;
&lt;h2&gt;
  
  
  The one decision that shaped everything: orchestrate, don't reinvent
&lt;/h2&gt;

&lt;p&gt;The tempting mistake is to write your own installers for 20+ tools — a bottomless pit of edge cases,&lt;br&gt;
and every line a way to break someone's machine. Devkeg does the opposite. It's an &lt;strong&gt;orchestration&lt;br&gt;
layer over proven backends&lt;/strong&gt;: &lt;a href="https://mise.jdx.dev" rel="noopener noreferrer"&gt;mise&lt;/a&gt; for languages/runtimes/tools in user&lt;br&gt;
space, and your distro's package manager for system packages. Devkeg's job is the &lt;em&gt;experience&lt;/em&gt; — not&lt;br&gt;
reimplementing what mise and apt already do well. Every install path we &lt;strong&gt;don't&lt;/strong&gt; write is a bug our&lt;br&gt;
users can't hit.&lt;/p&gt;
&lt;h2&gt;
  
  
  Architecture
&lt;/h2&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F0pjwn7juj0q60x7ez4e4.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F0pjwn7juj0q60x7ez4e4.png" alt=" " width="800" height="383"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Adding a new tool doesn't touch the core — it's just a small TOML file (data, not code):&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight toml"&gt;&lt;code&gt;&lt;span class="c"&gt;# registry/kubectl.toml&lt;/span&gt;
&lt;span class="py"&gt;name&lt;/span&gt;        &lt;span class="p"&gt;=&lt;/span&gt; &lt;span class="s"&gt;"kubectl"&lt;/span&gt;
&lt;span class="py"&gt;category&lt;/span&gt;    &lt;span class="p"&gt;=&lt;/span&gt; &lt;span class="s"&gt;"container"&lt;/span&gt;
&lt;span class="py"&gt;detect_cmd&lt;/span&gt;  &lt;span class="p"&gt;=&lt;/span&gt; &lt;span class="s"&gt;"kubectl"&lt;/span&gt;
&lt;span class="py"&gt;detect_args&lt;/span&gt; &lt;span class="p"&gt;=&lt;/span&gt; &lt;span class="p"&gt;[&lt;/span&gt;&lt;span class="s"&gt;"version"&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="s"&gt;"--client"&lt;/span&gt;&lt;span class="p"&gt;]&lt;/span&gt;
&lt;span class="py"&gt;backend&lt;/span&gt;     &lt;span class="p"&gt;=&lt;/span&gt; &lt;span class="s"&gt;"distro"&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;h2&gt;
  
  
  Why Tauri instead of Electron
&lt;/h2&gt;

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

&lt;ul&gt;
&lt;li&gt;
&lt;strong&gt;User-space first.&lt;/strong&gt; Prefer mise (installs to &lt;code&gt;~/.local&lt;/code&gt;) so most actions need no root. When
elevation is genuinely required, prompt explicitly via &lt;code&gt;pkexec&lt;/code&gt; — never silently &lt;code&gt;sudo&lt;/code&gt;.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Verify everything.&lt;/strong&gt; After each install/update, Devkeg re-detects the tool and confirms it runs,
returning a structured result. No silent half-installs.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Correct root detection.&lt;/strong&gt; The elevation decision uses the real effective UID (&lt;code&gt;geteuid()&lt;/code&gt;), not
brittle environment guesses.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2&gt;
  
  
  A lesson that cost me a rebuild: the glibc trap
&lt;/h2&gt;

&lt;p&gt;I built the &lt;code&gt;.deb&lt;/code&gt; on Ubuntu 24.04, it worked in my container, then refused to launch on Ubuntu 22.04:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;devkeg: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.39' not found
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;glibc is &lt;strong&gt;forward&lt;/strong&gt;-compatible, not backward — a binary built against 24.04's glibc (2.39) can't run&lt;br&gt;
on 22.04's (2.35). The rule:&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;Build release binaries on the oldest distro you intend to support.&lt;/strong&gt;&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;I moved the release build to Ubuntu 22.04 and pinned it in CI (&lt;code&gt;runs-on: ubuntu-22.04&lt;/code&gt;) so the mistake&lt;br&gt;
can't return.&lt;/p&gt;

&lt;h2&gt;
  
  
  Packaging and CI
&lt;/h2&gt;

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

&lt;h2&gt;
  
  
  What's next
&lt;/h2&gt;

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

&lt;h2&gt;
  
  
  Try it
&lt;/h2&gt;

&lt;p&gt;Devkeg is open source (MIT). Grab the &lt;code&gt;.deb&lt;/code&gt; or AppImage from the releases page, or read the code:&lt;br&gt;
&lt;strong&gt;&lt;a href="https://github.com/jay-tank/devkeg" rel="noopener noreferrer"&gt;https://github.com/jay-tank/devkeg&lt;/a&gt;&lt;/strong&gt;. If you build developer tools, I'd love feedback on the&lt;br&gt;
"orchestrate, don't reinvent" bet the whole project rests on.&lt;/p&gt;

</description>
      <category>devops</category>
      <category>rust</category>
      <category>tauri</category>
      <category>linux</category>
    </item>
  </channel>
</rss>
