Dustin VanKrimpen — Undefined Behavior

I Approved the Lockfile That Broke Every Deploy

2026-08-02T00:00:00Z

A colleague opened a small PR to harden dependency pinning on a Lambda. It was a real fix for a real bug. I read it, thought "good, this is more rigorous than what we had," and approved it.

It broke every infrastructure apply in the workspace for two days.

Nobody noticed, because the one thing that would have exercised the change was the one thing our pipeline never ran.

The bug it was fixing was real

The Lambda gets packaged and deployed by Terraform. Its rebuild trigger was a hash of the requirements file:

triggers_replace = {
  requirements = filemd5("${path.module}/src/requirements.txt")
}

That looks reasonable until you notice what the requirements file actually pinned. One direct dependency, pinned exactly. Everything underneath it floated.

So the transitive tree could move without the file changing a single byte. A new release of a downstream crypto library would land, the packaged artifact would happily pick it up on the next rebuild, and the trigger would see the same hash it saw last week. No rebuild, no change to source_code_hash, no signal that anything had moved. The trigger was watching a file that could not see the thing it was supposed to be watching.

That is a legitimate problem and worth fixing.

The fix that arrived

The PR did the textbook thing.

It introduced a human-edited source of truth with one line in it, the direct dependency. It compiled that into a fully hash-locked requirements file with uv:

uv pip compile requirements.in \
  --generate-hashes \
  --python-version 3.12 \
  --python-platform x86_64-manylinux2014

Out came a dozen pinned transitive dependencies, each with its hashes. Then it added --require-hashes to the install step in the build, so nothing could sneak in unpinned.

The PR body made the case cleanly: the trigger now fingerprints the entire dependency tree, so any transitive bump becomes a visible, reviewed diff that forces a rebuild.

Every part of that is correct reasoning. It is also the exact reasoning I would have written myself.

The failure

The build installs with pip, not uv:

pip3 install \
  --platform manylinux2014_x86_64 \
  --only-binary=:all: \
  --python-version 3.12 \
  --require-hashes \
  -r requirements.txt \
  -t ./build

Here is what it does now, every time:

ERROR: In --require-hashes mode, all requirements must have their
versions pinned with ==. These do not:
    typing-extensions>=4.13.2 (from cryptography==49.0.0)

The lockfile pins cryptography. cryptography requires typing-extensions. typing-extensions is not in the lockfile. It never was. It does not appear anywhere in the file, and git blame confirms the pin that requires it was there in the original lockfile commit, so this was not a later dependency bump knocking things loose. The lockfile was incomplete from birth.

--require-hashes refuses to fetch anything that was not pre-pinned and pre-hashed. So the install dies, the zip never gets built, source_code_hash never moves, and the apply exits non-zero. Not just for that Lambda. The whole workspace apply fails.

Read that against the goal one more time. The PR set out to stop transitive drift from silently skipping rebuilds. What it shipped was a build that loudly fails and still never rebuilds. Same stale artifact, worse blast radius.

Root cause: one lockfile, two resolvers

The lockfile was generated by uv and installed by pip.

For the same target, Python 3.12 on manylinux2014, uv's computed transitive closure excluded typing-extensions. pip's install-time resolution for that same target includes it. Two tools, same inputs, different answers about what the dependency tree contains. Why they diverge at that level, I didn't reproduce, and it doesn't change what broke next.

Under normal conditions that disagreement is invisible and harmless. pip would notice typing-extensions was missing, download a compatible version, and move on. Slightly unpinned, completely working, nobody ever finds out.

--require-hashes is what turned that into a wall.

This is the part I keep chewing on. The strictness was the whole point. It is what guarantees you get the bytes you reviewed and nothing else. And it is precisely what converted a benign resolver disagreement into a total, unrecoverable build failure. The hardening did not fail to protect us. The hardening is the mechanism by which we got hurt.

A lockfile is only complete relative to the tool that produced it. "Fingerprints the entire dependency tree" quietly assumed uv's tree and pip's install-time tree were the same tree. They were not, and --require-hashes made that assumption load-bearing.

Why it survived review

Three misses, and I own the middle one.

CI never ran it. The pipeline builds the application, tests it, and deploys it. It does not run terraform apply, and it does not run the Lambda's packaging step either. Infrastructure is applied by hand. So a lockfile that cannot install is completely invisible to CI. The one artifact that would have caught this in thirty seconds is not in the pipeline at all. If the only thing that exercises a build step is a manual command someone runs locally, that build step has no test. It has a habit.

I approved it. The honest version is not that I skimmed it. I read it. The problem is that the diff looked more rigorous than what it replaced. Hashes. Exact pins. A dedicated source-of-truth file. An added strictness flag. Every visible property of that change signaled care, and I graded the change on the properties I could see instead of the one that mattered: does the resulting file install?

That is the trap. Hardening changes come pre-loaded with the appearance of correctness. A diff that adds --require-hashes reads as unambiguously safer than one that removes it, and the reviewer's instinct is to nod. I never asked whether the artifact had been run.

The AI reviewer caught the cosmetics. Copilot did several passes on this PR. It flagged a comment mentioning the wrong library and got it corrected. It suggested adding the source file to the trigger list, which we declined for reasonable cause. It noticed that uv spells the platform x86_64-manylinux2014 while pip spells it manylinux2014_x86_64, called that easy to mix up, and its autofix committed a note about the spelling.

On the lockfile itself: reviewed three of three files, generated no new comments.

So it observed, in writing, that uv and pip are two different tools with two different spellings for the same target. Then it fixed the spelling and shipped. It flagged the surface symptom of the exact bug class that was sitting three lines below in the same diff. I do not think that is a dunk on the tool so much as a good illustration of what it is currently good at: it reads diffs, not artifacts. Neither did I.

What actually fixes it

Immediate. Regenerate the lockfile and then prove it installs before merging. The gap here was never "forgot to regenerate." It was "never verified the generated file installs." Those are different failures and only one of them is caught by regenerating more carefully.

Structural. Do not generate with one resolver and install with another under --require-hashes. Either install with uv as well, or compile with pip-tools so that generation and installation share pip's resolver. One resolver, end to end. The moment you have two, the lockfile is a claim about a tree that the installer may not agree exists.

CI. Run the packaging step in the pipeline. Not the apply, just the install into a throwaway directory:

pip install --require-hashes -r requirements.txt -t /tmp/verify

Ten seconds. It converts "a colleague's apply fails two days from now" into "this PR is red." More broadly, if apply is manual, the parts of the infrastructure that build things should still be exercised automatically.

The thing I took away

A lockfile that does not install is worse than a floating dependency. A floating dependency is a known, bounded risk that you can reason about. A broken lockfile is a landmine dressed as rigor, and it gets waved through review precisely because it is wearing the costume.

--require-hashes is only as safe as the lockfile is complete. And "it compiled" is not "it installs."

I still think the PR was the right idea. I would approve the same intent again. What I would do differently is ask one question I did not ask, the same question that turns out to matter for most build tooling: has anyone actually run this, or does it just look correct?

zram Ignored My Config, and systemd Said It Worked

2026-07-26T00:00:00Z

I configured an 8 GiB zstd zram device on a 16 GB box. Wrote the config, reloaded the daemon, started the service. No errors. Exit code 0.

Then I checked what was actually running:

$ zramctl
NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle         4G   4K   64B   12K       6 [SWAP]

Four gigabytes. lzo-rle. Neither of those is in my config file.

What zram is, briefly

zram is a compressed block device that lives in RAM. Point swap at it and the kernel compresses pages instead of writing them to disk, which gets you meaningfully more usable memory for a small CPU cost. On a machine where adding physical RAM means paying 2026 DDR4 prices, it is cheap insurance.

My box runs a local model on the GPU, and the weights live in VRAM. System RAM is not the biggest concern here, but the OS plus whatever orchestration I stack on top can spike. The server is meant to run unattended, so I wanted headroom.

The setup

On Ubuntu 26.04 the right tool is systemd-zram-generator. Not zram-tools, not zram-config. Those are older packages with different config paths, and having more than one of them installed is a good way to spend an hour editing a file that nothing reads.

sudo apt install -y systemd-zram-generator

sudo tee /etc/systemd/zram-generator.conf >/dev/null <<'EOF'
[zram0]
zram-size = min(ram, 8192)
compression-algorithm = zstd
EOF

sudo tee /etc/sysctl.d/99-zram.conf >/dev/null <<'EOF'
vm.swappiness = 180
EOF
sudo sysctl --system >/dev/null

zram-size is evaluated in MiB, so min(ram, 8192) gives an 8 GiB device on a 16 GB machine. zramctl prints that as 8G.

vm.swappiness = 180 looks wrong if you remember 100 being the ceiling. Kernels since 5.8 cap it at 200. Since zram swap is RAM speed, biasing the kernel toward evicting pages into compressed RAM instead of reclaiming page cache is a good trade. 150 works about as well. The difference is noise.

The gotcha

The package ships a vendor default that activates a 4 GB lzo-rle device at install time. That happens the moment apt finishes, which is before your config file exists.

So by the time you write /etc/systemd/zram-generator.conf, there is already a live zram0. And systemctl start on an already-active unit does nothing at all. It does not re-read your config, it does not rebuild the device, and it does not complain. It returns success, because from systemd's point of view the unit is running and that is exactly what you asked for.

The fix is one word:

sudo systemctl daemon-reload
sudo systemctl restart systemd-zram-setup@zram0.service

restart tears the device down and rebuilds it from /etc. Then verify:

zramctl                        # want: /dev/zram0  zstd  8G  [SWAP]
swapon --show                  # zram0 at priority 100, disk swapfile as low-priority tail
cat /proc/sys/vm/swappiness    # 180

If your install did not come with an on-disk swapfile, swapon --show will list zram0 alone. That works, but see the caveat below before you leave it that way.

One caveat

zram is not an OOM guarantee. A single runaway process can blow through RAM plus zram and still meet the OOM killer. Keep an on-disk swapfile at priority -1 as the tail that catches overflow, and add one if your install did not create it. zram sits at priority 100 and fills first, disk only takes what spills past it. For a box running unattended workloads, that layering is worth the five minutes.

Also worth knowing: compressed pages still occupy real RAM. An 8 GiB zram device on a 16 GB machine is not 24 GB of memory. It is 16 GB where the swapped-out portion holds 2 to 3 times what it would uncompressed, depending on how compressible your pages are. Treat the ratio as a bonus, not a budget.

The part that generalizes

The reason this cost me time is not that restart is obscure. It is that start reported success.

Every signal I had said the configuration was applied. The unit was active. The exit code was zero. Nothing in the logs suggested a conflict. The only way to find out the truth was to ask the device what it actually was, rather than asking systemd whether the command had worked.

This keeps happening to me in different costumes. A model that loads into VRAM but quietly runs inference on the CPU. A build that installs cleanly but produces the wrong artifact. In each case there's a green checkmark sitting on top of a wrong answer. The fix is the same every time: go look at the running state.

systemctl start answers a question about systemd. zramctl answers a question about your machine. Ask the second one.

Using My Local Coding Model From Anywhere

2026-07-25T00:00:00Z

In the last post I got a coding model (qwen2.5-coder:14b) running on a repurposed GPU (Radeon RX 6750 XT 12GB) that AMD's compute stack officially won't support. Which is great, except for one thing: the box it runs on sits in a corner in my basement. A local model you can only use while physically sitting at the machine it runs on is just inconvenient.

The whole point of a local tier is that it is there when I am. At my laptop on the couch, on my phone waiting in line somewhere, from a coffee shop. This post is the connective tissue, detailing how I reach that headless box from anywhere without punching a single hole in my router.

Why the obvious answer is the wrong one

Two things I wanted, and they pull against each other:

Reach the machine, and its model endpoint, from any of my devices, wherever I am.
Expose nothing to the public internet.

The naive way to do (1) is port forwarding: tell your router to send traffic on some port straight to the box. It works, and it flatly violates (2). And it is especially reckless here, because the model endpoint has no authentication. Ollama does not ask for a password. Anyone who can reach it can use it. Forwarding that to the open internet means giving your GPU to the first scanner that wanders by.

So port forwarding is out. What I wanted was a way for my own devices to reach each other as if they were on the same local network, no matter what physical network each one is actually on, without anything being visible to anyone else. Keeping everything private, with nothing exposed, is the whole point.

Tailscale: a private network that follows your devices around

The tool I settled on is Tailscale. It is a mesh VPN built on WireGuard. It's not the kind of VPN that hides your traffic from your ISP. Instead, it's the kind that connects your own devices to each other. You install it on each machine, they all join one private network (your "tailnet"), and every device gets a stable address in the 100.x range that is reachable from any other device on the tailnet, wherever they physically are.

The clever part is how the connection gets made. A coordination server helps your devices find each other and then gets out of the way. The actual traffic is a direct, end-to-end encrypted, peer-to-peer link. There is no port forwarding, and nothing is exposed to the public internet. The same mechanism carries everything: SSH on port 22, the model endpoint on :11434, and whatever else I run, all over the tailnet. Nothing public.

A few practical notes:

The free Personal tier is plenty. Unlimited devices of your own, up to 6 users. A handful of personal machines is nowhere near any limit, and it costs nothing.
Install it on everything, one account. The GPU box, the laptop, the phone, all on the same tailnet.
MagicDNS gives your devices names instead of making you memorize 100.x addresses... in theory. See the gotchas.

Note: For those who would rather not trust Tailscale's coordination server at all, there is an open-source, self-hostable replacement for it called Headscale. I plan on trying it out at some point and documenting my verdict here in the future, so stay tuned!

Two gotchas

This is the part worth documenting, because these are the things that will make someone bounce off Tailscale thinking it's broken when it isn't.

The Mac app can get stuck, and the fix is the CLI build. The standalone Tailscale Mac app leans on a macOS system extension, and that extension can wedge itself: no login prompt, the VPN toggle throws errors, and reinstalling does nothing. It is a known issue, more likely if you ever had an old App Store install or you're on a newer macOS. This happened to me, unfortunately. The fix that worked was installing the Homebrew CLI build instead (brew install tailscale), which uses the utun interface and sidesteps the system extension entirely. The tradeoff is you lose the menu-bar GUI and drive it from the terminal. Really no problem at all for me. It connects reliably, which is the part that matters.

MagicDNS short names are flaky on that CLI build. Once you are on the Homebrew CLI client, MagicDNS does not wire into the Mac's resolver as cleanly as the GUI app does. The name you set up may just not resolve. The fix is to use the full MagicDNS name or the raw 100.x IP. Slightly annoying, entirely livable once you know it. It's worth noting the MagicDNS names resolved fine on the Android client.

SSH, and making it survive real life

With the tailnet up, SSH into the box is just ssh you@100.x.x.x from any of your devices. A few things make it pleasant instead of fiddly:

Key auth, no passwords. Standard ssh-copy-id. If you import your keys from GitHub during the Ubuntu install, this is basically already done.
An SSH config alias so you can type ssh yourMachine and never think about IPs again. In ~/.ssh/config, point Host yourMachine at the raw 100.x address. This has a nice side effect: because you hardcoded the IP, the alias works even when MagicDNS is being flaky. It routes around the gotcha above entirely.
tmux for anything long-running. An SSH session dies when your laptop sleeps or your WiFi drops, and anything running directly in that session dies with it. tmux runs the session on the box, decoupled from your connection, so you start something, detach, close the lid, and reattach later from a different device exactly where you left off. This is load-bearing once you are kicking off unattended work.
mosh for the phone. Plain SSH drops when your phone roams between WiFi and cellular. mosh survives that, so a mobile session does not die every time you walk out of the building. mosh plus tmux is the mobile combo.

Exposing the model endpoint (only to the tailnet)

Here is the piece specific to the model. By default Ollama binds to 127.0.0.1, meaning it only listens to the box itself. To let other devices reach it, you tell it to listen on all interfaces with a systemd drop-in that sets OLLAMA_HOST=0.0.0.0.

That sounds alarming, and it would be, except for what actually holds the boundary. The bind is broad, but the firewall is the fence. ufw is set to default-deny incoming, with a single allow rule scoped to the tailnet interface (ufw allow in on tailscale0). So the endpoint listens broadly, but it's only reachable over the tailnet. Nothing on the physical LAN or the public internet can touch it. This matters enormously precisely because the endpoint is unauthenticated: the firewall scoping is the only thing standing between "my private model" and "a GPU for anyone on the internet." It is not optional.

The one command that proves the whole chain

There are three moving parts stacked here: the broad bind, the ufw rule, and Tailscale itself. When something doesn't connect, it is tempting to guess which layer is at fault. Don't guess. Prove it from a real client with one request:

curl http://100.x.x.x:11434/api/tags

Run that from the laptop, not from the box. If it returns JSON listing your models, the entire chain is proven end to end. The bind is listening, the firewall is allowing tailnet traffic, and Tailscale is carrying it. If it hangs or refuses, you've narrowed it to the network path rather than the model. This is the fastest "is it actually working" check, and I run it before wiring up anything else.

Actually using it from the laptop

Now the payoff. Anything that speaks to Ollama can be pointed at the box over the tailnet. The ollama CLI and most Ollama-aware tools respect an OLLAMA_HOST environment variable, so on the laptop:

export OLLAMA_HOST=http://100.x.x.x:11434

and the CLI is now a remote control for the GPU box. Nothing runs locally on the laptop; it is purely a client. For tools that only speak the OpenAI API shape, Ollama also exposes an OpenAI-compatible endpoint at the /v1 path, which you point the tool at with any dummy API key.

The reason this works so cleanly is a small architectural point worth internalizing: the model is stateless per request, and "workspace context" is just files you put into the request. So you can gather context on the machine that has your files (the laptop) and send only the model call to the remote GPU. The code and the compute do not have to live in the same place.

In a future post, I will dive deeper into the tooling that you can connect to your local LLM for development. Currently, I've been experimenting with using JetBrains Gateway and Cline.

The honest tradeoff: plan a way back in

As configured, SSH into this box rides only the tailnet firewall rule. So if Tailscale fails to come up on boot, the machine is unreachable over the tailnet, and right now that is the main door.

The fix is cheap and does not compromise the posture: add a second ufw rule that allows SSH from your local network, scoped to your subnet (ufw allow from 192.168.x.0/24 to any port 22). That is still not public. Your LAN is not the internet, and you are not touching the router or forwarding any ports. You are just widening the way in from "tailnet only" to "tailnet, or the same physical network." When Tailscale is down and you are home, you can still walk over to your own network and get in.

The LAN rule only saves you when you are physically on the LAN. If the tunnel dies while you are out, you are still waiting until you get home to console in or reboot. But for a headless box sitting in my house, "I can always reach it from my own network" covers nearly every lockout worth worrying about, and it is a rule that only needs to be set once. The thing to actually avoid is having neither path, tailnet-only with no LAN fallback, on a box you have made a dependency.

Where this leaves the project

So now the model from post 1 is not stuck in a corner. I can reach it from my laptop or my phone, from anywhere, and point tools at it as if it were local, with nothing exposed to the internet and one curl to prove the whole path. That is the local tier.

The next question is the one that decides whether any of this was worth it: is the model actually good enough to trust with real software engineering work? A quantized 14B on a consumer card is capable, but capable enough to hand real tasks to and route around a frontier model? That is a benchmarking post, and it has a twist, because the first numbers I got were badly wrong for reasons that had nothing to do with the model. I will dive deeper into this with my next post.

The bigger goal underneath all of it is the same: a coding agent that does the cheap work locally, for free and off any rate limit, and only spends frontier-model credits when the problem actually earns one. A free tier LLM reachable from anywhere is most of the setup for that. Now I need to know how much of my real work it can actually carry.

That is all for today. Go make the machine in your closet reachable from anywhere.

I Gave My Coding Agent A Free Tier

2026-07-11T00:00:00Z

Jump to the TL;DR if you just want the summary of setting it all up minus the story.

Why host a model?

I like using the latest frontier class models for the hard stuff. I do not love spending their rate limits on "rename this variable" and "write the obvious boilerplate." So I decided to host a large language model (LLM) on my own hardware, free and off of rate limits: soak up the easy work locally, save the frontier credits for the work that needs them, and keep my data off some AI corporation's servers while I'm at it. This post is step #1: setting up the hardware.

Sourcing hardware during the RAMpocalypse

2026 is a brutal market for PC components. There's a massive AI-driven shortage of DRAM and GDDR which has made prices skyrocket. As of this post, a 32 GB DDR4 kit that used to cost about $50-$70 is sitting at roughly $200. Rather than get fleeced in a seller's market, I decided to just use hardware that I had lying around.

Enter my gaming PC. I built it back in 2020 during the pandemic restrictions. Back then I had all the free time in the world for gaming. It's mostly been collecting dust since my first son was born in 2022. The perfect candidate for my AI server.

The Specs

Originally the gaming PC had a GTX 1080 carried over from an even earlier build. Around 3 years ago I impulse bought a RX 6750 XT 12GB on a good sale and swapped it in. The RX 6750 XT is a fine mid-level card for 1080p and some 1440p gaming today. However, it is generally not a card that you'll see recommended for running LLMs locally.

That said, it's not a bad card for it either (with some caveats I will get to later). For inference, the most important factor is VRAM, because that's what determines what size of model you can hold. The 12 GB in my RX 6750 XT is enough to hold a real coding model, with extra room for context. I didn't set out to choose AMD over NVIDIA here. It's just what I had.

The rest of the box is nothing special. The CPU is a genuinely dated Ryzen 5 2600, but that's ok because it doesn't need to do much during GPU inference. It has 16 GB of DDR4 RAM. A bit tight since I also want to run orchestration processes on this machine, but it's fine given the sheer redonkulousness of RAM prices in 2026.

I did a fresh install of Ubuntu 26.04 since it's free, lean, fits the tooling, and I plan on mostly using it headless via SSH anyway.

Full spec table for the curious:

Part	What I Have	Notes
CPU	Ryzen 5 2600 (Zen+, 6c/12t, 2018)	Adequate for now
GPU	Radeon RX 6750 XT 12GB (RDNA2, gfx1031)	Fine for now, but I'm keeping an eye out for deals on something like an RX 7900 XTX or RTX 3090 to upgrade
RAM	16 GB DDR4	Will upgrade when RAM prices come down

The unsupported card problem

Here is where the caveat of my GPU comes into play. AMD's compute stack is called ROCm. This is their answer to NVIDIA's CUDA. There is a hardcoded list of supported GPU targets for ROCm, and your card has to be on it. My RX 6750 XT reports its chip target as gfx1031, which is not supported. The very similar chip in the 6800 and 6900 series cards is gfx1030, and that one is supported. gfx1031, the 6700 series, is not. Same architecture, one digit off, left off the list.

Note: ROCm's official supported-GPU list changes between releases, and gfx1031 support has been a moving target. Best to check for yourself since things may have changed since the time of this posting.

The usual workaround

There is a very simple workaround that a lot of people have reported success with on Linux. It basically tricks ROCm into thinking your card is supported. You install the GPU drivers and ROCm runtime as usual, add your user account to the video and render groups, and then spoof the GFX version to 10.3.0 like so:

export HSA_OVERRIDE_GFX_VERSION=10.3.0

Vulkan: the alternative

Vulkan is a graphics and compute API that these cards support natively with no ROCm needed. I am using Ollama to serve models, which runs inference on the Vulkan backend no problem. The main downside is it's inference-only, meaning you can't fine-tune or train models. Since I'm only trying to serve an existing model for now, it's a non-issue for me.

Note: It's not that Vulkan is inherently incapable of training/tuning models. It's just that the typical training stack targets CUDA/ROCm.

Comparison: ROCm workaround vs. Vulkan (RX 6750 XT / gfx1031)

Factor	ROCm (via `HSA_OVERRIDE_GFX_VERSION=10.3.0`)	Vulkan
Setup	Needs the override env var to spoof the GPU target	Natively supported, no workaround
Reliability	Fragile: can fail to init; updates can silently break it	Stable; part of Mesa, survives kernel updates
Fine-tuning / training	Supported; the ML-native path (PyTorch-ROCm, vLLM)	Unsupported; inference only
Tooling	Richer (`rocm-smi` for monitoring)	Lighter (`radeontop`)

Verdict

For my use case (a mostly-headless inference box), Vulkan wins, and I'm not giving up much for it. The old assumption that ROCm is meaningfully faster has largely eroded: recent benchmarks put ROCm anywhere from ~10–20% ahead (mostly on prompt processing) to level with or behind Vulkan. On RDNA2 in particular, the generation the Vulkan backend was first tuned on, the two are close enough that speed isn't the deciding factor.

The goal of this project is to make AI-assisted workflows easier for me. I want to spend my time building cool things, not debugging why the latest update broke my hacky workaround. Vulkan just works, and keeps working across driver updates, which is what I want for an always-on server.

Setup

I started with a clean slate. A fresh install of Ubuntu 26.04 LTS Desktop. I went with desktop because I do have a monitor attached (set up at a desk in my basement), and will occasionally work from it directly using IDEs and such. But most of the time it will be connected to and used headless via my MacBook Air.

Step 1: The Vulkan graphics stack

Update the system and install the Vulkan userspace drivers and a couple of diagnostic tools:

sudo apt update && sudo apt full-upgrade -y
sudo apt install -y mesa-vulkan-drivers vulkan-tools radeontop

Confirm the card is visible to Vulkan:

vulkaninfo | grep -i deviceName
# should print "AMD Radeon RX 6750 XT" (mine shows RADV NAVI22)

radeontop is the tool we'll use later to prove the GPU is actually doing the math, so it's worth installing now.

Step 2: Install Ollama and pull a model

Ollama is the easiest way to serve a local model. Install it with one line:

curl -fsSL https://ollama.com/install.sh | sh

On this hardware Ollama installs as a systemd service. During the first run, it resolves the Vulkan backend, drops the unsupported ROCm device, and loads onto the discrete RX 6750 XT with ~11.6 GiB of usable VRAM.

Note: When Ollama starts, it will show a warning that it dropped the ROCm device. This is expected on a gfx1031 card. It realized that the GPU doesn't support ROCm and fell back to Vulkan. That's what you want.

Picking a model for 12GB of VRAM

Now that Ollama is set up, it's time to choose a model for it to serve. This is where the VRAM budgeting gets real.

My VRAM limitation rules out the current flagships: qwen3-coder:30b (~19GB), Codestral 22B (~13GB), and anything 24B+ dense. What's left is still a solid field of 7–16B coders.

Model	Params	~Q4 size	Context	Trade-off
qwen2.5-coder:14b (chosen)	14.8B dense	~9GB	32K	Best dense code quality in the tier; native tool-calling + fill-in-the-middle. Non-reasoning, so it's fast.
qwen2.5-coder:7b	7B dense	~4.7GB	32K	Same family, more headroom/speed, lower ceiling.
qwen3:14b	14.8B dense	~9GB	32K+	Strong generalist that codes well, but not code-specialized.
deepseek-coder-v2:16b	16B MoE (2.4B active)	~8.9GB	160K	Fastest option (MoE) and by far the largest context. Weaker at multi-step tool use.
deepseek-r1-distill-qwen:14b	14B dense (reasoning)	~9GB	32K	Thinks step-by-step. Great for hard debugging, slower for everyday generation.

I picked it because this box is intended to be the worker tier of a two-tier setup: easy tasks run locally, hard ones escalate to externally hosted models. I wanted the fastest, most reliable, tool-capable code specialist that fits. If I need a higher-reasoning model, I reach for an externally hosted 'frontier-class' one.

Pulling

With the model chosen, pulling it is one line:

ollama pull qwen2.5-coder:14b-instruct-q4_K_M

Quick smoke test:

ollama run qwen2.5-coder:14b-instruct-q4_K_M "write a python function that reverses a string"

If it answers, the model runs. However, that does not prove it's using the GPU. That part is next.

Step 3: Prove it's actually on the GPU (not silently on the CPU)

It's possible for Ollama to discover your GPU, load the weights into VRAM, and still run the compute on CPU. The logs will look normal, VRAM will show occupied, and the tokens will trickle while your CPU melts.

To verify the GPU compute, I used radeontop. Open it in one terminal like so:

radeontop

Then, in a second terminal, fire off a prompt long enough to sustain load for several seconds:

ollama run qwen2.5-coder:14b-instruct-q4_K_M \
  "write a detailed, heavily commented python implementation of a red-black tree with insert, delete, and search"

A tmux tip: split the terminal (Ctrl-b %), run radeontop on the left and your ollama run on the right, and you can literally watch the GPU spike as it "thinks." It's oddly satisfying.

Now watch radeontop while tokens are streaming. What you're looking for:

Metric	Idle (between generations)	Active (mid-generation)
Graphics pipe	~1–2%	jumps high (~93% on mine)
Shader Clock	~0.4%	climbs toward max (~90%)
VRAM	~10.3 / 12.2 GB	same (model stays resident)

The signal is the transition: idle → active → idle, synced to token output.

Note: Watch Graphics pipe and Shader Clock, not VRAM. The weights can be in VRAM while the math runs on the CPU. You have to watch during streaming. The compute drops to zero as soon as generation ends.

On the VRAM numbers: Ollama reports usable VRAM in GiB (it logged ~11.6 GiB available), while radeontop reads out in GB using its own accounting. The two don't line up exactly.

On my box, Graphics pipe hit ~93% and Shader Clock ~90% during generation, then fell to 0% and ~0.11% after. That confirms GPU inference over Vulkan. If your compute stays flat while tokens are streaming, that indicates CPU fallback, so you'll need to do some debugging.

GPU compute verified.

Step 4: The context-window decision (8K, on purpose)

Ollama picks a default context length for you, but I wanted to set it explicitly because context costs VRAM. A bigger context window means a bigger KV cache sitting in memory alongside the weights. On a 12 GB card, that budget is tight, so I capped the default served context at 8K, which gives ~10.3 GB resident with headroom to spare (even though Qwen2.5-Coder's native context is 32K).

I set it with a systemd drop-in, so I'm not editing Ollama's packaged unit file:

sudo mkdir -p /etc/systemd/system/ollama.service.d
sudo tee /etc/systemd/system/ollama.service.d/override.conf >/dev/null <<'EOF'
[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
EOF

sudo systemctl daemon-reload
sudo systemctl restart ollama

Verify it took:

systemctl show ollama -p Environment --no-pager   # echoes OLLAMA_CONTEXT_LENGTH=8192

8K is a fine default for most coding prompts. If a specific task needs more, you don't have to change the service. You can override context per request:

curl http://localhost:11434/api/generate -d '{
  "model": "qwen2.5-coder:14b-instruct-q4_K_M",
  "prompt": "...",
  "stream": false,
  "options": { "num_ctx": 16384, "temperature": 0.2 }
}'

Raise num_ctx for the one long-context call that needs it. Don't leave it high globally or you'll pay the VRAM tax on every request.

A couple of other handy per-request knobs:

temperature 0.1–0.3 for deterministic code, higher for brainstorming
keep_alive pass -1 to pin the model resident when you're about to hammer it (by default it unloads after 5 idle minutes and the next request eats a few-second reload).

Ollama also exposes an OpenAI-compatible API at http://localhost:11434/v1. Any tool compatible with "OpenAI API, custom base URL" can point at it locally with a dummy key. The server is stateless. It takes the full message history on every call, so your client holds the conversation.

I also set up zram as a compressed-RAM cushion for the orchestration I plan to stack on top, since 16 GB is tight.

TL;DR

The cliffnotes on setting up your own self-hosted LLM server:

Install an LTS Linux (Ubuntu 24.04/26.04) with a recent kernel for your GPU.
Check your GPU's compute support. AMD: is your gfx target on ROCm's list? If not (e.g. RX 6700-series gfx1031), plan on Vulkan: sudo apt install mesa-vulkan-drivers vulkan-tools radeontop.
Install Ollama: curl -fsSL https://ollama.com/install.sh | sh.
Pull a model that fits your VRAM. 12 GB → a 14B at Q4_K_M (~10 GB). Don't try to cram a 30B into 12 GB.
Verify GPU compute with radeontop during generation. Watch Graphics pipe / Shader Clock, not VRAM. Discovery ≠ compute.
Set the context ceiling with a systemd drop-in (OLLAMA_CONTEXT_LENGTH=8192) to keep the KV cache inside your VRAM budget; override per request with num_ctx when needed.

Next steps

This box is the worker tier of a two-tier setup: the easy work runs here, the hard work escalates to a frontier model. Reaching it from anywhere without exposing anything to the internet is the next post. Whether a quantized 14B is actually good enough to trust is the one after.

Final notes

For now, I am happy to have my own free model running on a mid-level card that I didn't have to pay 2026 prices for. You don't need the latest, most expensive hardware to run a real and useful model at home. All you need is something with enough VRAM. It doesn't even have to be on AMD's supported list.

Go and check out what your idle GPU could be doing instead.

Keeping a Record of Why

2026-06-23T00:00:00Z

Updated 2026-06-25: the plugin was renamed to wherefore and gained the resolve and supersede skills since this was first published.

Three people hashed out the API structure in a meeting back in March. The conclusion is in their heads. Nowhere else.

This happens constantly in software teams. Some decisions make it into a Jira ticket, a PR description, or an ADR that someone spent an hour writing and that nobody will read again. Most don't. A few months later, someone asks why the thing is built the way it is, and the honest answer is that you weren't in the room.

The meetings aren't the problem. The reasoning disappearing afterward is.

I built a Claude Code skill to capture this: a minimal decision log that lives in the project repository, gets populated during working sessions with Claude, and can be queried later when someone needs to know why. Open and self-hosted at github.com/DustinVK/wherefore.

Four skills and a command

The plugin ships four skills and a setup command.

capture logs a decision from a discussion. ask retrieves prior context: invoke it when you're about to touch a system and want to know what was decided there before. resolve closes an open question left hanging in an earlier entry, recording the answer and rationale. supersede retires a past decision after the fact, marking it obsolete or forwarding to a replacement, without needing a full new session.

Capture and ask have different triggers: you invoke capture at the end of a session where something got decided, ask when you're about to touch a system and want prior context. Neither tries to do the other's job.

If you use a /grill-me style workflow to stress-test a decision before committing to it, capture is a natural next step. The grilling surfaces what was considered and rejected; the log preserves that output in a form you can actually find later.

What an entry looks like

The goal is not a transcript. A transcript of a technical discussion is 4,000 words of context-switching and tangents that resolves, somewhere near the end, into a paragraph of actual decisions. The entry should be that paragraph.

Each log file captures four things:

What was decided and the outcome.
Why that choice was made.
What was rejected and why each option was ruled out.
Open questions left unresolved, if any.

A typical entry is under 40 lines. Frontmatter carries the metadata; freeform markdown carries the content. Here is the shape of one:

---
date: 2026-06-22
title: OAuth token encryption — KMS-direct, SSM for app credentials
areas: [ingestion, credentials]
topics: [security, kms, oauth]
status: active
---

## Summary
Per-location GBP refresh tokens are stored as KMS-encrypted ciphertext in the
`locations` table. App-level OAuth credentials (client ID + secret) live in SSM
Parameter Store. No envelope encryption; no cross-invocation credential caching.

## Decisions
- **Per-location refresh tokens:** using `KMS.Encrypt` / `KMS.Decrypt` with encryption context `{"location_id": id}`.
  One KMS decrypt per job invocation; no data-key caching.
- **App credentials (client ID/secret):** SSM Parameter Store SecureString, fetched
  at cold start. Free, KMS-backed at rest, no per-secret monthly fee.
- **Access-token caching:** cache the short-lived access token in `sync.Map`; never
  cache the decrypted refresh token. Cache hits transitively skip the KMS call.

## Why
Postgres disk encryption protects a stolen disk, not anyone who can read the table —
a refresh token is effectively a long-lived password and must be encrypted at rest
behind a real key boundary. Co-locating the ciphertext with the location row is the
correct data model. Secrets Manager would charge $0.40/location/month for rotation
we don't use. KMS-direct costs ~$1–3/month at hundreds of locations.

Access-token caching (not refresh-token caching) gives the best risk/reward profile:
a ~1h self-expiring credential sits in process memory; the refresh token is decrypted
transiently per job and discarded. Caching the refresh token would hold the long-lived
credential for the container's entire lifetime — maximum blast radius — to save cents.

## Alternatives considered
**Envelope encryption (AWS Encryption SDK or hand-rolled AES-GCM):** envelope helps
when payloads exceed KMS's 4KB limit or when one data key is amortized across a batch.
Neither applies: a refresh token is a few hundred bytes; the worker processes exactly
one location per invocation. Envelope would make the same single KMS call plus an
AES-GCM nonce-management layer on top — strictly more code, zero savings.

**Secrets Manager per location:** correct security model, but $0.40/secret/month scales
linearly with location count. Rejected in favor of encrypted column.

**Cached data key across warm invocations:** holds a plaintext key that unlocks every
location's token in memory for the container's lifetime. Rejected — maximum blast radius
to save a sub-$3/month KMS bill.

## Open questions
None. The KMS CMK is wired via `sst.Linkable` (couples ARN injection with the IAM
grant so they can't drift); the Go implementation of the decrypt path is pending `gbp.go`.

The skill instructs Claude to extract decisions and reasoning and drop everything else. If nothing was actually decided in a session, open questions go under that heading rather than manufacturing a conclusion that was not there.

The tagging system

Entries are tagged along two dimensions: areas and topics.

Areas are feature slices or product domains. The what. Something like order-process or user-auth or reporting. Topics are cross-cutting technical concerns. The how. Something like performance or caching or third-party-integration.

The distinction matters for retrieval. If someone asks what decisions were made about caching, they want everything tagged with the topic caching, regardless of which feature it touches. "What about the checkout flow?" lands differently: everything in the area checkout, whatever the technical concern. The two dimensions let you slice it either way.

The controlled vocabulary is the part that actually makes this work. Early in a project, you populate a topics.md file with the tags that matter for your codebase. From that point on, the skill reuses existing tags rather than inventing new ones. This sounds like a minor detail. It is not. Uncontrolled tagging fragments search results across synonyms and near-duplicates within a few months. The plugin includes a /wherefore:seed command that bootstraps the vocabulary from your codebase structure, so you're not starting from a blank page.

When a decision changes

The status system handles supersession. When a later discussion reverses an earlier decision, the new entry records supersedes: YYYY-MM-DD-old-slug and the old entry gets updated with status: superseded and a pointer forward.

Both entries stay in the log. The old decision still happened, and the reasoning behind it is still worth keeping. Sometimes you need to know not just what the current approach is, but that the original one was tried and why it was abandoned. The chain gives you that.

The supersede skill handles this directly: point it at a past entry and it marks the entry superseded or obsolete without requiring a new discussion session. Obsolete differs from superseded: obsolete means the decision no longer applies and there is no replacement, just a change in direction.

Installing and using it

Two commands, then restart Claude Code:

/plugin marketplace add DustinVK/wherefore
/plugin install wherefore@dustinvk

The plugin ships its own tooling. The log itself lives in each project repository, created on first use.

First-time setup

Bootstrap your tag vocabulary. Rather than inventing area and topic tags from scratch, run:

/wherefore:seed

Claude inspects your codebase, module layout, routes, dependency manifests, migrations, and proposes a starter set with a short justification for each tag. Confirm, edit, or trim the list and it writes wherefore/topics.md. Good tags are coarse and stable: checkout, billing, auth, postgres. Not price-rounding-edge-case.

Wire up the trigger. Paste the snippet from CLAUDE.snippet.md into your project's CLAUDE.md. This makes Claude offer to log a decision when a session reaches one. Capturing becomes a yes instead of something someone has to remember to initiate.

Both steps are optional. The log works without them; the trigger just becomes manual and the vocabulary grows organically.

Logging a discussion

At the end of a huddle or design conversation, paste the summary and say "log this discussion." Raw transcript, Slack export, AI-generated recap: any of these work.

Claude distills it into a compact entry: what was decided, why, and what alternatives were rejected. Not a transcript. The useful residue. It tags the entry from your controlled vocabulary, checks whether it reverses any earlier decision and links the two entries if so, and shows you the result before writing anything. You get a chance to correct the tags or title before anything is committed.

The entry lands in wherefore/log/YYYY-MM-DD-short-slug.md and a one-line summary is appended to wherefore/INDEX.md. Both files go into the repo like any other code: PR-reviewable, blame-traceable, and searchable with standard tools.

Querying the log

Ask in plain English:

"Why did we implement the price calculator the way we did?"
"What did we decide about PROJ-1234?"
"How are we handling tenant isolation?"

Claude reads INDEX.md to shortlist relevant entries without opening every file, then pulls the decisions and rationale from the matching ones. If a decision was later reversed, it follows the supersession link and answers from the current entry, and tells you the decision changed so you are not acting on something that was revisited. If nothing matches, it says so plainly.

What it does not do

A few honest limitations.

It only captures what you bring to it. If your team makes a significant call in a meeting that does not involve a Claude session, that decision will not end up in the log unless someone takes time afterward to summarize it and run the skill. It is not passive. It requires a habit.

It is also not a replacement for formal decision records on things that affect the whole organization. An ADR process with review and stakeholder sign-off is the right tool for that. This covers the smaller daily calls that are not worth a formal process but are still worth more than a Slack thread that scrolls away.

Final notes

The thing I wanted most from this was the ability to ask "why does this work this way?" and get a real answer instead of a shrug or a two-hour archaeology project through old messages. That is what it does. The log is not comprehensive, but it has been useful enough to pull up more than once already, which is more than I can say for most documentation I have written.

That is all for today.

How This Site Got Its Look.

2026-06-19T00:00:00Z

Design works like software. You sketch something, mock it up, keep what lands, and throw out what doesn't. Then you go again, and again, until it stops feeling wrong.

When I started on my portfolio, I looked around at what other developers had built. Plenty of good templates out there. None of them felt like me. I wanted something personal, closer to a craft workshop than a landing page. Somewhere that looks like a person makes things there, on purpose: sophisticated, jewel-toned, terminal energy used as punctuation instead of the whole sentence.

Here's how I got there.

The Palette Journey.

Iteration 01 — finding the right colors

I tried four directions before one of them stuck. The first was the default you land on when you don't make any choices at all. The next two were fine designs that just weren't mine, and weren't right for this.

//Direction 1

Plain Default.

No fuss, no decisions. Black text on white, system-ish sans, default everything.

About

Dustin VanKrimpen

Software engineer building things in Michigan. View my projects or get in touch.

White

#FFFFFF

Black

#000000

Mid Gray

#6B7280

Light Gray

#EEEEEE

The first instinct was to just not make decisions. White background, black text, gray secondary text, default sans-serif. The "I'm not a designer, I'm a developer who happens to need a website" approach. The thinking: don't pretend, don't perform, let the content speak for itself.

It's the safest possible direction. Nobody could call it tacky or overdesigned. It would fit any context, any device, any decade.

Verdict — moved on

Plain. Fine. Said nothing. On a portfolio it reads as "I couldn't be bothered," which isn't what I want a hiring manager walking away with.

//Direction 2

Modern Refined.

The "thoughtful SaaS" direction. Safe, modern, approachable.

The Developer

Dustin VanKrimpen, software engineer.

Me as a SaaS platform. Your software, delivered with care. Join now, free for the first 30 days.

Warm Cream

#FAF6EE

Soft Navy

#1A2536

Terracotta

#C2624A

Sage

#5D7A6B

I wanted color, so I built around a muted pairing of clay red and sage green. Terracotta (#c2624a) on the primary CTA carries the same energy as red but reads as craft and earth instead of civic or political. Sage (#5d7a6b) is the earthy grounding accent, used for labels and italics. Together they drop the page straight into "modern software" territory. I warmed the background to a buttery #faf6ee and softened the navy to #1a2536, a notch less stark than full navy.

The typography shifts. Headings switched to Fraunces, a variable serif, with italics for emphasis. Fraunces reads as thoughtful modern software. Sentence case on buttons and labels read as conversational rather than commanding. Pill-shaped buttons instead of hard rectangles are softer, more contemporary.

Verdict — moved on

Good, but not me. I'd built something you couldn't tell apart from a startup's marketing site. The craft was there. The personality wasn't. It felt like cosplaying another company's brand.

//Direction 3

Neon Cyberpunk.

The opposite swing. Electric purple, neon green, heavy glow, all monospace.

// SYS_ONLINE

_DUSTIN_VANKRIMPEN

> init l33t haXX0r skillz...

Void Black

#050510

Neon Green

#00FF80

Electric Purple

#B300FF

Hot Magenta

#FF00CC

If the refined direction was too safe, this was the overcorrection. Pure cyberpunk. Electric purple (#b300ff) and neon green (#00ff80) on void-black, heavy glow on every element, monospace all the way down.

Borrowed energy from cyberpunk movie posters, Defcon talks, hacker forum aesthetics. Buttons had glow on top of glow. Headlines had double text-shadows. The whole thing felt like a launch sequence.

Verdict — moved on

All volume, no quiet. Nowhere to rest your eyes. Fun as a vibe. Still not me.

//Direction 4 — the keeper

The Flannel Epiphany.

Unexpected inspiration from real life.

//Grand Rapids, MI

Dustin VanKrimpen.

Just a chill software dev in Michigan. Build logs, projects, and the occasional thought.

Charcoal

#1A1A22

Purple

#221F3D

Teal

#3A9B9D

Spark

#C2392E

I ran through several more rounds trying to split the difference between safe-and-mature and fun-and-techy. Nothing clicked. I wanted something grounded and humble that still carried color and a character of its own.

Then I looked down at the shirt I was wearing. A flannel I wear constantly: deep navy-purple base, charcoal, a jewel-tone teal, thin red stripes through it. I thought, this is the palette.

Not the plaid itself, but what the colors were doing together. The dark base wasn't pure black; it had warmth and depth. The teal sat muted and low, nothing like neon. The red was one thin stripe, used sparingly. And purple wasn't a background at all. It was a destination.

The charcoal (#1a1a22) carries a faint purple-warm undertone. That little bit of warmth keeps the whole thing from going cold and sterile. It reads as low-light workshop, not data center. The teal (#3a9b9d) is muted and shifted slightly green, away from bright cyan. It looks more like an old phosphor display than a neon sign. The spark red (#C2392E) shows up only for emphasis: a thin line above the hero, the primary button, and that's it.

Verdict — shipped

It worked because textile designers had already proven these colors can live together, for decades. Real-world objects come with color harmonies built in. It worked because every color had a job too: teal is the workhorse accent, purple the destination, spark red the action signal, charcoal the foundation.

Style Elements I Cut.

Iteration 02 — choices that didn't make it

Beyond color, there were a dozen smaller choices I tried and cut. Some were generic anti-patterns I knew to dodge from the start. Others almost made the final cut before I caught them doing more harm than good.

Generic anti-patterns

My first attempts looked exactly like the thing I was trying to avoid. None of them said anything about me. They were templates I'd dropped my information into.

Skipped

DEV PORTFOLIO

Building things since 2020

Pure Black Background

Goes too dark. Feels cold and sterile, like a server room dashboard.

Skipped

$ whoami
> dev_xtreme
$ cat skills.txt

Acid/Lime Green Text

Too cartoonish. Reads as Defcon costume, not craftsperson.

Skipped

$ whoami

Blinking Cursor Animation

Theatrical. The static > and // markers convey terminal energy without being a costume.

Skipped

EVERYTHING GLOWS

even the body text glows softly

Glowing Button

Glow On Everything

If glow is everywhere, it stops meaning anything. Make it earn its place.

When everything glows, nothing does.

Almost made the cut

These four got closer. Each one ended up clarifying what the site is actually for.

Cut

HEADLINE TEXT

Body text underneath the heading

CRT Scanline Overlay

Tried it across the whole site. At full opacity it felt like a costume. Kept a faint version at 2.5%, felt more than seen.

Cut

[01]Cut the Unnecessary

[02]Priced for Small Biz

[03]Built to Work

Bracketed Numbers [01]

Too "look at me, I'm a terminal." Just 01 in mono is cleaner.

Cut

Card 1

Card 2

Card 3

Sliding-In Cards on Scroll

Theatrical and slows the reader down. Subtle fades are fine. Nothing more.

Cut

Hover Me

Wobbling Cards on Hover

Adds movement that doesn't communicate anything. Animations should be functional.

The pattern I noticed: every time I cut something, it was because the element was performing rather than communicating. Decorative motion that didn't tell you anything. Costume-coded type that screamed "look how terminal I am" rather than just being terminal-flavored. The good moves are the ones that get out of the way once you've absorbed them.

Typefaces Considered.

Iteration 03 — picking the right voices

With the palette settled, I had to pick type. Four faces, each with one job, no overlap. Before I locked the display face, I tried three that didn't work. Each showed me a way the site shouldn't go.

Crafting quiet tools.

Fraunces

Variable Serif · Display

Cut

Beautiful and considered, but it's turned into the house serif for a lot of well-funded software. It made the site read like someone else's marketing. Borrowed authority.

Crafting quiet tools.

Inter

Modern Sans · Internet default

Cut

A default on a lot of dev portfolios. Genuinely good, genuinely characterless. Wanted something more distinct.

Crafting quiet tools.

Space Grotesk

Geometric Sans · Tech-launch energy

Cut

Has the modern startup-launch feel. Felt cliché, but I do like it.

CRAFTING QUIET TOOLS.

Bebas Neue

Condensed Display · Industrial signage

Kept — display

Reads as workshop signage, news headlines, industrial labels. No decoration, no nostalgia. It gets out of the way and lets the words do the work. Free, one weight, hard to misuse.

Crafting quiet tools — a workshop in Michigan, since 2026.

Barlow + Condensed

Humanist Sans · Body and labels

Kept — body

Pairs with Bebas Neue without competing. Quiet enough at body sizes that you forget it's there. Shares a family with Barlow Condensed for labels and UI, so the system unifies cleanly.

//crafting quiet tools

JetBrains Mono

Coder Monospace · Terminal accents only

Kept — terminal

The // comment-style eyebrows depend on this one. Real ligature support, drawn by people who actually write code. Used only as punctuation, never for body.

The rule that emerged: JetBrains Mono only for terminal-energy moments. Comment-style eyebrow text. Metadata. The numbers in numbered lists. Never body copy. The moment you put mono on long-form text, it goes from "this is from the terminal" to "this is uncomfortable to read."

Signature Moves.

Iteration 04 — making it feel like mine

A palette and a type system get you 80% of the way there. The last 20% is the small recurring elements that make a site feel like it belongs to a specific person, not a Figma template.

I built three of them. Each one earns its place.

// The logo lockup

DUSTIN/VANKRIMPEN

The wordmark sets a teal forward-slash between my first and last name, last name in purple. The slash glows, just barely. It's the only place that slash-and-purple combo shows up anywhere on the site, which is what makes it work. It's my signature, not a motif I reuse until it turns into wallpaper.

// The status dot

AVAILABLE FOR WORK

A small pulsing teal dot in the nav, with a "STATUS" label in mono. It says "alive and present" without spelling anything out. The pulse is slow, a full 2.5 seconds, so it reads as ambient instead of anxious.

// Comment-marker eyebrows

//Grand Rapids, MI · Est. 2026

For the eyebrows above section headlines, I use a teal // marker followed by the label in mono. It frames the section like a code comment: "this is metadata about the thing below." Once you notice it, the whole site starts reading a little more like a code editor.

The Destination Rule

Purple Only Shows Up Once Per Page.

Purple is the destination color. One section per page gets it: the headline feature, the spot I most want a visitor to land. When purple finally shows up, it should feel like stepping into a velvet room in a slate-floored studio. Spread it everywhere and the hierarchy collapses, nothing feels special. The restraint is what makes the rare thing read as rare.

What I Learned.

Iteration 05 — the takeaways

Three things I came out of this with that I'll take into the next design:

Restraint is a feature. Every accent color, every glow, every animation has to earn its place. If everything is loud, nothing is loud.
Borrow from physical objects, not other websites. That flannel taught me more about a palette than an hour of scrolling Dribbble ever did. Things that already exist in the real world have survived the test of looking good together.
Rules beat decisions. "Purple only once per page" is easier to follow than "use purple thoughtfully." Codified constraints free you from having to make every choice from scratch.

The site you're reading this on isn't finished. It'll keep changing as I learn more. But the foundation feels right: it looks like somewhere a person actually makes things, not a template with my name dropped in. That was the entire goal.

I keep a reference doc for the whole design system and update it as I go. Drop me a line if you'd like a copy.

Migrating Password Hashes Without Anyone Noticing

2026-06-16T00:00:00Z

Most security upgrades come with a tax. You change something under the hood and your users feel it. A password-hash upgrade is the rare one where that tax is optional, but most teams pay it anyway by firing off a "please reset your password" email to the entire user base. That email tanks engagement and fills the Monday support queue with "why did you change my password???"

When I took over an existing Spring Boot codebase, one of the first things I did was a security review of what I was inheriting. One item I flagged as a top priority was password storage. The app hashed passwords with salted SHA-256, a solid choice years ago that has aged like milk. The hard part was never picking a replacement. It was rolling one out without forcing every user to reset their password.

I moved password-hashing to Argon2id without sending a single one of those emails. Every user kept their existing password, nothing ran as a batch job, and the app never went into a maintenance window. As far as our users could tell, nothing happened at all. Here is how the pattern works and why it flows naturally from the way password hashing is handled.

Note: the examples below are in Spring and Kotlin, but the pattern holds up whatever framework or language you're using. They're simplified to show the shape of the approach, not lifted out of a production codebase. Always do your own research and validation when performing critical security updates rather than blindly following what is presented here.

Why salted SHA-256 is the wrong tool for passwords

SHA-256's fatal flaw as a password hash is that it's fast. A modern GPU churns through something like 10 billion SHA-256 hashes a second, so a budget box with four consumer cards can grind an enormous candidate list in an afternoon. Salting doesn't fix that. A per-user salt stops one precomputed rainbow table from unlocking everyone at once, but it does nothing to slow a brute force against a single account, and each user is still cheap to crack if their password is weak.

The real fix is a hash that's deliberately slow and memory-hungry, 100 to 500 ms per attempt: practically invisible during an interactive login, brutal for an attacker who needs billions of guesses. The technique is called adaptive hashing, and the "adaptive" part means you can crank the cost up as hardware gets faster.

Picking a secure password hash

Three candidates were worth taking seriously. bcrypt (1999) is mature, battle-tested, and built into Spring Security, but it is not memory-hard and it silently truncates anything past a 72-byte input limit. scrypt (2009) is memory-hard and genuinely solid, but under-supported by libraries. Argon2id (2015) is the hybrid Argon2 variant that won the Password Hashing Competition: memory-hard, three tunable knobs, OWASP's current pick for new applications, and exactly what Spring Security's Argon2PasswordEncoder gives you.

	bcrypt	Argon2id
Cryptographic strength	Solid	Solid, plus memory-hard
GPU/ASIC resistance	Modest	Strong
Maturity (years deployed)	25+	~10
Spring Security support	Built-in, default	Built-in (needs BouncyCastle)
Tunable parameters	1 (cost)	3 (memory, iterations, parallelism)
Hash output	Self-contained, ~60 chars	Self-contained, ~100 chars
OWASP recommendation	Acceptable	Recommended
Operational complexity	Low	Slightly higher

I went with Argon2id, not because bcrypt would have been wrong, but because the marginal cost of stepping up to the OWASP-recommended option was tiny and we already had the BouncyCastle dependency it needs registered for another integration. Otherwise, bcrypt at cost 12 is a defensible answer. scrypt got the least thought: same memory-hardness, older and less-recommended, no upside I could name for a fresh start.

You can't rehash what you can't read

My first instinct was the obvious one: write a migration script, loop over every user, rehash each password with Argon2id, done by lunch. That plan survived about thirty seconds. You cannot rehash a password without the plaintext, and the plaintext is the one thing a password table never stores. That is the whole point of a hash, and it makes the tidy batch job impossible, not just impractical. There is nothing to feed the new algorithm.

The only moment you ever hold a user's plaintext is the instant they type it to log in, so that is when the migration has to happen. You do not migrate users in a batch. You migrate each one on their next login, riding along on a verification step that was going to run anyway.

At any point during the rollout you have three groups:

Active users log in regularly and migrate within a week or so.
Occasional users migrate whenever they next show up, maybe a month or three out.
Dormant users never come back and stay on the old hash indefinitely. That is fine. Their accounts are no more exposed than before, the hash is still valid, and if they ever return they migrate on the spot.

The dormant tail is not a security problem, it is at most a future UX decision. You can always force a reset of it sometime later if you prefer to leave no threads hanging.

A caveat on dormant legacy hashes

On calling the dormant tail a UX decision rather than a security risk: That holds for salted SHA-256, which still forces an attacker to grind each hash on its own, so the residual exposure on a dormant account is low enough. If your legacy hash is genuinely weak (unsalted, MD5, bare SHA-1), or you are in a high-stakes context, those dormant hashes are a real risk, since they can be cracked in bulk whether or not the user ever comes back. OWASP's Upgrading Legacy Hashes guidance covers this: expire the old hashes and force those users to reset, or layer the strong algorithm over the weak one. Layering sidesteps the no-plaintext problem from earlier, since you feed Argon2id the hash you already have instead of the password, storing argon2id(md5($password)) for every account in one pass and protecting even the dormant ones immediately. A layered hash is a bit weaker than a clean one, so treat it as a stopgap and still swap in a real argon2id($password) on the user's next login.

The lazy migration

The core idea in pseudocode:

for each successful login:
    if the user already has a modern hash:
        verify normally, return the result
    else:
        verify against the legacy algorithm
        if it matches:
            hash the plaintext with the modern algorithm
            store the new hash and clear the legacy one
        return the result

Two properties matter. First, failed logins migrate nobody: a wrong password behaves exactly as before, with no database writes, so brute-force attempts never migrate themselves into anything. Second, the user sees nothing. They typed a password, they got logged in, same as always, with no "we have updated our security, please confirm" prompt.

The code

Spring Security setup is one bean:

@Configuration
open class PasswordHashingConfig(
    @Value("\${security.argon2.memory-kib:19456}") private val memoryKib: Int,
    @Value("\${security.argon2.iterations:2}") private val iterations: Int,
    @Value("\${security.argon2.parallelism:1}") private val parallelism: Int,
) {
    @Bean
    open fun passwordEncoder(): PasswordEncoder =
        Argon2PasswordEncoder(16, 32, parallelism, memoryKib, iterations)
}

The first two arguments are easy to skim past: 16 is the salt length in bytes (a 128-bit salt) and 32 is the length of the hash output in bytes (256 bits). Both are Spring's defaults. The three named values after them are the ones that set the actual work factor.

That same encoder both creates and verifies Argon2id hashes. Argon2 hashes are self-describing, so on verification the encoder reads the parameters straight out of the stored string.

One thing the constructor does not show is which Argon2 variant you get. There is no argument for it, because Argon2PasswordEncoder is hardwired to Argon2id and gives you no way to pick Argon2i or Argon2d. If you ever want to confirm it, the variant is the first field of that self-describing string, so any stored hash beginning with $argon2id$ settles it.

Worth a quick aside: Spring's DelegatingPasswordEncoder has out-of-the-box scheme-switching for hashes stored in its prefixed {id} format. Our legacy hashes were a bare SHA-256 scheme with no prefix, so a small custom dispatcher was simpler than retrofitting the prefix onto every old row.

The data model has two homes during the migration:

The legacy columns on the user_account table: salt and password (the SHA-256 output), both made nullable in a migration.
A new user_verification table, one row per migrated user: user_id, token (the Argon2id hash), date_updated.

The presence of a user_verification row is the migration flag. No is_migrated boolean, no nullable enum. Either the row exists and you are on Argon2id, or it does not and you are still on SHA-256.

You do not need a second table for any of this. Migrating in place works fine. Widen the existing password column for the longer Argon2id hash and overwrite it on a successful login. That is simpler, and it is what most write-ups do.

I split the new hash into its own table for application-level separation. It keeps credentials off the main user entity (no leaking through a stray SELECT *, an API response, or a log line), lets me scope tighter database grants, and allows checking "who is migrated?" by a simple row query instead of matching hash prefixes. To be clear, it buys nothing against a security breach where both tables fall together. It is defense against accidental exposure, not a wall against an attacker who already has your database.

The dispatcher:

@Service
class PasswordVerificationService(
    private val passwordEncoder: PasswordEncoder,
    private val verificationRepo: PasswordVerificationRepository,
) {

    /**
     * Verifies that [plaintext] matches the stored password for [user].
     *
     * As a side effect, lazily migrates users still on the legacy hash to
     * Argon2id on successful verification. The migration is invisible to
     * the caller. They just see a Boolean.
     */
    fun verifyPassword(plaintext: String, user: User): Boolean {
        val stored = verificationRepo.findByUserId(user.id)

        if (stored != null) {
            // User has already been migrated to Argon2id.
            return passwordEncoder.matches(plaintext, stored.token)
        }

        // No verification row, so the user is still on legacy SHA-256.
        if (sha256Hex(user.salt + plaintext) != user.password) {
            return false
        }

        // Plaintext matches the legacy hash. Migrate to Argon2id while we have it.
        verificationRepo.insertAndClearLegacy(
            userId = user.id,
            token = passwordEncoder.encode(plaintext)
        )
        return true
    }
}

That is the whole engine. Two branches, no flag columns, no scheme-detection guesswork. Here is what happens per request:

User state	Wrong password	Correct password
Already migrated (Argon2id row exists)	`matches()` returns false. No writes.	`matches()` returns true. No writes.
Not yet migrated (legacy SHA-256)	SHA-256 check fails. No writes.	SHA-256 check passes, then hash with Argon2id and write the new row plus clear the legacy columns, in one transaction.

One honest weakness: the two failure paths do not cost the same. A wrong password for a migrated user runs the full Argon2id verify, while a wrong password for someone still on legacy fails on a fast SHA-256 compare. That timing gap leaks whether a given account has migrated yet, which is low value to an attacker but not nothing. If you care, run a throwaway Argon2id hash on that fast-fail path so both failures take about the same time. The path where the user is not found at all has the same shape and deserves the same treatment; that is out of scope here since verifyPassword already receives a User.

The repository layer is the boring part, an insert plus an atomic clear of the legacy columns:

@Repository
class PasswordVerificationRepository(private val em: EntityManager) {

    fun findByUserId(userId: Long): PasswordVerification? = ...

    @Transactional
    fun insertAndClearLegacy(userId: Long, token: String) {
        em.createNativeQuery("""
            INSERT INTO user_verification (user_id, token, date_updated)
            VALUES (:userId, :token, NOW())
            ON CONFLICT (user_id) DO NOTHING
        """).setParameter("userId", userId)
           .setParameter("token", token)
           .executeUpdate()

        // Idempotent: a concurrent login may have already nulled these.
        em.createQuery("""
            UPDATE User u
               SET u.salt = NULL, u.password = NULL
             WHERE u.id = :userId
        """).setParameter("userId", userId).executeUpdate()
    }
}

Both writes live in one transaction, so they commit together or roll back together. There is never a window where a user has both an Argon2id hash and a populated legacy hash. The dispatcher would behave correctly even if there were, since it checks for the verification row first, but clearing the old columns keeps the data clean and the "is this user migrated?" question crisp. If you're updating the hashes in place, then this happens automatically.

One concurrency edge: two simultaneous logins for the same un-migrated user can both read no verification row, both pass the SHA-256 check, and both attempt the insert. Put a unique constraint on user_verification.user_id and make the insert idempotent (ON CONFLICT (user_id) DO NOTHING as above, or catch the constraint violation and fall through to verifying against the now-present Argon2id row) so a duplicate is a no-op rather than an error.

This lets me track the progress in two simple queries.

-- migrated users
SELECT COUNT(*) FROM user_verification;

-- users still on legacy SHA-256
SELECT COUNT(*) FROM user_account WHERE password IS NOT NULL;

Watch those two numbers converge over the weeks after deploy.

Tuning Argon2id

Argon2 has three knobs:

memory: KiB allocated per hash. More memory, more resistance to parallel attacks.
iterations: passes over that memory. More passes, more time per hash.
parallelism: threads per hash. More threads is faster wall-clock but costs more CPU per login.

The OWASP Password Storage Cheat Sheet currently recommends a baseline of m=19456 KiB (19 MiB), t=2, p=1, which lands around 150 to 300 ms on commodity hardware. I ran the defaults through our test and staging environments to confirm logins still felt fast. This was more of a sanity check than rigorous latency profiling. If login latency is critical, measure it properly on production-like hardware and tune it yourself instead of relying on a default or a number from someone's blog (including this one). The same goes for the recommended parameters themselves. They move as hardware gets faster, so treat the numbers here as a snapshot and check the cheat sheet for the current guidance before you ship.

One note on parallelism: every concurrent login burns p threads. On a small, busy instance, leave p=1. The rough test for raising it is (spare cores at peak) ÷ (peak concurrent logins) ≥ p. For a typical low-login-throughput B2B app, p=1 is almost always right.

A free bonus: self-invalidating reset tokens

I got one nice side effect for free. Password-reset tokens are signed with a server secret concatenated with the user's current password hash:

// A signed token is just a payload plus an HMAC over it, keyed by some secret.
fun createToken(payload: String, secretKey: String): String {
    val body = base64UrlEncode(payload.toByteArray())
    val signature = base64UrlEncode(hmacSha256(body, secretKey))
    return "$body.$signature"
}

// Reset token: key the signature with the server secret PLUS the user's current hash.
fun createResetToken(user: User): String {
    val payload = """{"sub":"${user.email}","exp":$expiresAt}"""
    return createToken(payload, secretKey = serverSecret + currentPasswordHash(user))
}

The important piece is currentPasswordHash(user), which returns whatever the hash is right now, in whichever scheme:

fun currentPasswordHash(user: User): String =
    verificationRepo.findByUserId(user.id)?.token  // Argon2id (post-migration)
        ?: user.password                            // SHA-256 (pre-migration)

Because the signature is keyed by the current hash, anything that changes that hash invalidates every outstanding reset token for that user. Two things change it. A completed reset or password change rotates the hash, so the token that was just used stops verifying the instant the new password lands, which means it cannot be replayed. The migration counts too: when a user logs in and flips from SHA-256 to Argon2id, any reset link issued beforehand quietly dies along with the old hash. You end up with single-use reset tokens for free, with no consumed flag, no per-token rows, and no server-side state to track. The exp field in the payload handles expiry; the signing scheme handles the rest on its own. The one flip side: a reset link issued before migration silently dies if the user logs in and migrates before clicking it. That is fine; if the user could log in, the reset was not needed.

Aside: the real reset token also carries an action field, but that's orthogonal to the self-invalidation trick.

What about new users?

Nothing special. New signups run through the normal flow and get an Argon2id hash from day one, because the passwordEncoder.encode(...) call in the registration path writes straight to user_verification. They never touch the legacy branch. The "no verification row means SHA-256" path exists only for accounts that predate the migration.

Final notes

If you are sitting on fast legacy hashes, SHA-256, MD5, anything quick, lazy-on-login is the standard way out. It works, users never notice, and the same scaffold stretches to cover the next hash upgrade too. The hard parts are picking parameters and writing the dispatcher (which really isn't hard at all). The rest is config and patience.

The one thing to hold onto: a hash you cannot reverse can only be replaced when its owner hands you the plaintext again. Build around that constraint instead of against it, and the migration runs itself.

That is all for today. Go find out what your old hashes are actually made of.

Hello World!

2026-06-15T00:00:00Z

Editor's note (2026-07-10): This blog was originally called the "Build Log." It has since been renamed to "Undefined Behavior." The original name is left intact below, where it appears as it was first written.

Intro

Welcome to the first entry in the Build Log, my personal software engineering journal. It exists mainly to serve as my personal knowledge-repository of challenges faced, topics researched, discussions had, and decisions made in my day-to-day job building software. But if anyone else gets some value out of it, that's a great side-effect to have!

Why write a dev blog?

One of my favorite things about being a software engineer is the constant array of new challenges I get to research and solve for. Often, it's a pattern or concept I've seen before, but occasionally I get to tackle something that is brand new to me too. As the years go by, I find myself losing the finer details of what I learned and researched. I often remember the broad details of what I did, but lose the details of the whys and hows. In the process of documenting my work, I hope to lock in a deeper understanding of these challenges and solutions. And if not, the Build Log will serve as my personal decision audit-table where I can go in and see the specifics.

Putting my reasoning in public is also partly self-interested. The quickest way to find the flaw in your own thinking is to write it down and let someone correct you. So please feel free to reach out if you disagree with anything I write here, or have a better solution for a problem than what I came up with. I welcome any and all feedback I can get!

What goes in here

Expect more working notes and decision logging than hot takes and juicy gossip. Posts will mostly be short to medium length and almost always pulled from real work.

My current work is primarily in web application development, so expect topics like:

Multi-tenant data isolation patterns, especially when Postgres RLS is on the table.
Serverless trade-offs on AWS, mostly Go on Lambda with SST.
Auth flows you have to live with after you ship them.

If a post does not pass the "would I send this to a teammate" test, I will not publish it.

How it is built

The blog is Markdown plus Eleventy v3 on top of my otherwise hand-coded site. The rest of dustinvk.com is plain HTML/CSS/JS. To publish a post, I drop a .md file into posts/, push to main, and Cloudflare Pages rebuilds. No CMS, no component framework, no JavaScript at runtime beyond the existing theme switcher.

Why Eleventy

I wanted a static site generator with as little ceremony as possible. I'd been writing posts straight into HTML, which works exactly once. I didn't want a CMS either, since I'm the only one publishing here.

Eleventy was the simple middle ground: I write in Markdown, keep my own hand-coded design, and a new post is just a file I drop in and push. As a bonus, it's generic enough to reskin for any client sites I build.

Here are some more things I liked about Eleventy:

It ships zero client-side JavaScript by default. Whatever JS ends up in the build is JS I wrote or added on purpose.
It does not assume a frontend framework. Templates can be Nunjucks, Liquid, Markdown, or plain HTML, and they mix freely.
The config is one JavaScript file. No magic, no plugin ecosystem you have to learn before you can ship.
It only processes the file types I opt into and copies everything else across with passthrough copy, so my existing hand-coded pages ship exactly as I wrote them.

Eleventy is the simplest tool that gets the job done.

A short setup tour

If you want to do the same, the four moving parts are: a config file, a folder of Markdown posts, a layout that wraps each post, and a build command. The whole thing fits on one screen.

1. Install it.

npm init -y
npm install --save-dev @11ty/eleventy

2. Write a minimal eleventy.config.js. This tells Eleventy where to read from, where to write to, and which file types to treat as templates.

export default function (eleventyConfig) {
  return {
    dir: { input: ".", output: "_site", includes: "_includes" },
    templateFormats: ["njk", "md"],
    markdownTemplateEngine: "njk",
  };
}

Set "type": "module" in your package.json if you want the ESM syntax above. Anything that is not one of those template formats (CSS, images, my existing hand-coded HTML) stays out of the template pipeline. I copy those across with eleventyConfig.addPassthroughCopy(...), which is how the rest of the site comes through the build untouched.

3. Make a layout at _includes/layouts/post.njk. It wraps every post. Nunjucks is just HTML with {{ variables }} and {% blocks %}:

doctype html>
<html lang="en">
<head><title>{{ title }}title>head>
<body>
  <h1>{{ title }}h1>
  <article>{{ content | safe }}article>
body>
html>

4. Write a post at posts/hello.md. The frontmatter tells Eleventy which layout to use and provides the variables that layout reads.

---
title: Hello
layout: layouts/post.njk
---

Hi, this is my first post.

5. Build and preview.

npx @11ty/eleventy           # one-shot build to _site/
npx @11ty/eleventy --serve   # local dev server at http://localhost:8080

That is the entire happy path. The Eleventy docs are genuinely good. The Get Started page covers everything above in more depth, and Collections is where things start to get interesting.

Where it goes from here

The next thing you probably want is a collection to power a post list. Here is a trimmed version of the one driving this page. It grabs every Markdown file under posts/, drops anything marked draft: true, and sorts newest first:

eleventyConfig.addCollection("posts", (api) =>
  api
    .getFilteredByGlob("posts/*.md")
    .filter((p) => !p.data.draft)
    .sort((a, b) => b.date - a.date)
);

After that, the usual additions are an RSS feed via @11ty/eleventy-plugin-rss and code syntax highlighting via @11ty/eleventy-plugin-syntaxhighlight. Both are one-line additions in your config.

I also plan on using giscus to power a comment system in my blog posts via Github Discussions. But I will save that for another day.

Configuring Eleventy on Cloudflare Pages

Wiring this up to Cloudflare Pages took about 30 seconds. In the build configuration you pick Eleventy as the framework preset, which fills in the build command (npx @11ty/eleventy) and the output directory (_site) for you. The only thing I added by hand was a NODE_VERSION environment variable set to 20, so the build runs on a current Node. That is the whole setup, and every push to main rebuilds and deploys on its own. Almost too easy.

Final notes

There you have it. My thoughts on developer blogging, choosing the right tool, and a very quick rundown of how to setup Eleventy to power your own personal blog through basic .MD files.

Next up, I'll be diving into a practical security migration: How to seamlessly upgrade user password hashing algorithms in a Spring Boot web app without disrupting the user experience. I'll cover how to audit the existing setup, implement a rolling migration strategy that upgrades hashes dynamically upon user login, and handle the database schema updates without downtime.

That's all for today. Let's build! 🚀