Boring Is Important

No demo. No screenshot. No AI. The two most valuable days we spent recently produced nothing you could put in a launch tweet - and that was exactly the point.

The dashboard looks identical before and after. Nobody is going to retweet a smaller Docker image or a batch of CVEs they'll never see. But that invisible, un-tweetable, no-new-features work is what this post is about - a small argument for why we keep choosing it, and a concrete look at what "it" actually was.

Because here's the thing about a monitoring tool: you're asking people to run it next to their most important database, holding their most sensitive data, at the exact moment things are going wrong. That's a lot of trust. And trust isn't earned by the flashy stuff. It's earned by the boring stuff, quietly, over and over, until someone audits you and finds nothing to complain about.

We ship the shiny things too

I want to be honest up front, because this isn't a lecture from someone who only does the vegetables. We like the fun work. In July alone we shipped fifteen new anomaly detectors, each one built from a real thread on the Valkey issue tracker. We ship semantic caching, agent-memory SDKs, an experimental local-LLM helper. AI is genuinely part of what we do.

So this isn't anti-AI, and it isn't anti-feature. It's anti-neglect. The failure mode I'm worried about is the one where the entire industry spends 100% of its attention on the demo-able 20% and lets the other 80% quietly rot - the dependencies, the base images, the build config, the permission edges. The stuff that never demos well but is the first thing a real operator checks.

Recently, we focused on the 80%.

Story one: the CVEs you'll never notice

Depending on how it's configured, our migration engine pulls in a compiled binary from RedisShake. We ship it inside our image. Simple enough - except the upstream release binary is compiled with a Go toolchain that went end-of-life two years ago, and an EOL Go standard library carries dozens of accumulated CVEs, including criticals.

And here's the catch: those CVEs are baked into a statically-linked binary. You cannot apk upgrade your way out of them. The usual "just patch the base image" reflex does nothing, because the vulnerable code isn't an OS package - it's welded into the binary we shipped. The only real fix is to rebuild the thing from source against a current Go toolchain. So that's what we did.

While we were in there, we pulled out two things we were shipping and never used: the npm CLI (we build with pnpm; npm was dead weight, along with its own vendored CVEs) and a full GNU tar package (busybox already provides one). We moved the base image forward a major version. We rebuilt from source with a modern toolchain and stamped the real version into the binary so our logs stop lying about what's running.

The scanner tells the story better than I can. The image went from 138 findings to 11, and from four criticals and fifty-two highs to zero and zero. The eleven that remain are low-severity items with no upstream fix yet - and I'd rather tell you they exist than pretend the number is a flat zero.

Nobody will ever notice this. That is precisely the point. The best outcome of security work is that nothing happens, forever, and no one thinks about you. It's the least gratifying kind of win there is, and it's non-negotiable.

Story two: the one line that was doubling our image

This one's a little embarrassing, because the mistake was so dumb and the cost was so big.

Our production image was about 1.34 GB. Fine, not great - a lot of that is node_modules, which is the tax you pay for a Node app. But when I actually pulled the image apart layer by layer, one layer stood out: a near-perfect duplicate of our entire node_modules, ~600 MB, sitting there for no reason I could see.

The culprit was a single line: chown -R /app. We were creating a non-root user (good, you should) and then recursively changing ownership of the whole app directory so that user could read it. Reasonable-looking. Except overlay filesystems - the thing Docker layers are built on - copy a file into a new layer the moment you change anything about it, including its ownership bit. chown -R touches every one of tens of thousands of files. So the whole tree gets copied, byte for byte, into a fresh layer. We were paying ~600 MB to change a number on some files.

The fix is almost insultingly small: you don't chown after the fact, you set ownership as the files are written, with COPY --chown. One layer instead of two. No duplicate.

• No-AI image: 1.34 GB → 744 MB uncompressed, 342.72 MB → 199.28 MB compressed (what you actually pull).
• AI image: 2.22 GB → 1.17 GB uncompressed, 607.1 MB → 331.2 MB compressed.

Roughly cut in half. Every user who pulls the image moves less data. Every deploy is faster. Every node caches more. And it cost us a day of unglamorous spelunking through docker history and a five-character diff. That ratio - a day of boring investigation for a permanent, everyone-benefits win - is exactly the trade I want to be making.

(There's a sequel, because there always is: removing that recursive chown quietly broke the app's ability to write to its own working directory, which our health check didn't catch. We fixed it, non-recursively. The optimization and the regression shipped in the same commit - they usually do.)

Story three: last week, more of the same

None of this started this week. If you scroll our merge history from the past two weeks, the pattern is right there between the feature work:

• Clearing out every open Dependabot alert GitHub had on us: criticals and highs in one pass, then back for the mediums. Two separate PRs, no headline.
• Fixing a permission edge where an explicit ACL denial was quietly defeating a workaround grant - the kind of bug that only bites the security-conscious teams who bothered to configure ACLs in the first place.
• Right-sizing a Kubernetes resource quota so a tenant's monitor actually fits the pod it's scheduled onto.

Not one of those is a feature. Not one of those has a screenshot. All of them are the difference between "worked in the demo" and "still working after months."

Why we keep choosing it

Boring work has a nasty asymmetry: it's invisible when you do it and catastrophic when you don't. Nobody praises the CVE that never got exploited or the OOM that never happened. But everybody remembers the tool that shipped a critical, or ate half their disk, or fell over during the incident it was supposed to help with. You don't get credit for the boring work - you get permission to keep existing.

So no, none of this week will make a good launch tweet. There's no new button. The dashboard is byte-for-byte the same. But your pull is faster, your scanner is quieter, your migration binary isn't dragging two years of Go CVEs into your cluster, and the whole thing is a little more honest than it was on Monday.

If you run BetterDB and you never once think about our Docker image, our CVE count, or our build pipeline - that's not an accident. That's the work. We'll keep doing it, right alongside the shiny stuff, because the shiny stuff isn't worth much sitting on top of a foundation nobody maintained.

If you want to see for yourself, the leaner image is already on Docker Hub - pull it, scan it, point it at a database, and tell us where it still falls short.