Whatever you have, select more. Whatever you achieve, mark it insufficient. If you are tired, that is a configuration error in your morning routine. Have you tried waking at 04:30, drinking something the colour of reactor coolant and listening to a podcast where a man with three assistants explains self-reliance?

Tech gives this machinery root access to your personality. There is always another language to learn, title to earn, company to join, project to ship or person on the internet whose career can be converted into evidence that you are falling behind. You must grow. You must become bigger, faster and more impressive. You must spend your one wild and precious life maintaining an internal Jira board called Reasons I May Eventually Deserve To Exist.

My last two fieldnotes were about refusing to optimize the joy out of writing and accepting that my tools do not need to be the future. Under both was an elephant I had politely configured Hugo not to render.

I did not only optimize the joy out of writing.

For a long time, I optimized the joy out of being alive.

I thought success would prove I was not useless#

There is nothing inherently wrong with wanting a mansion or expensive cars. A mansion is a building. A car is an unusually complicated chair that converts money into movement and dashboard warnings. Neither has a moral alignment.

The useful question is what job you have secretly hired those things to perform.

I did not merely want success because parts of a successful life seemed pleasant. I wanted it to issue a verdict.

If I had the right home, cars, career and invitations, they would prove I was not useless. They would show everyone that I had finally made it. More importantly, perhaps they would show me. The mansion was not a place to live. It was a unit test for my worth.

This is a marvellous arrangement for the grind because the test can never pass. Every achievement becomes ordinary shortly after it arrives. The new title turns into the title printed in your email signature. The difficult project becomes a line on your CV. The salary that once sounded impossible becomes the number from which bills leave. The room full of impressive people becomes, on closer inspection, a room full of people checking whether everyone else is impressed.

Nothing can permanently prove an internal belief wrong when the belief gets to grade its own exam.

So I kept submitting more evidence.

Stockholm was supposed to be the solution#

I believed moving to Stockholm would solve my problems. I spent time around Östermalm and in the “right” circles. I worked in places some people dream of reaching.

I do not regret going. Stockholm taught me a great deal about work, people and myself. It also taught me that you can successfully arrive in the life you planned and discover that somebody else wrote the requirements.

I thought I wanted the mansion, the cars and the social world orbiting them. What I wanted was the proof they seemed to contain. Once that became the purpose, friendship started degrading into networking. Being with the right people mattered more than being close to them. A night out was not simply a night out; it was an opportunity to be observed in the correct place with the correct company.

There was no single conversation that revealed it. It was the repeated experience of being at the right clubs and the cool events, almost always surrounded by people, while feeling more alone and isolated than I ever had in my life.

I kept smiling. I performed the version of me who genuinely wanted to be there because that was who the people around me expected to meet. I had gained access to the rooms I thought would prove that I belonged, then spent my time inside them cosplaying someone who felt at home.

Everything became a transaction:

1person        -> connection
2conversation  -> opportunity
3job           -> credential
4home          -> temporary base for the next move
5free time     -> capacity that should be monetized
6me            -> product requiring better market positioning

I stopped having friends in any meaningful sense. I knew people, sometimes useful people, and they knew me. That is not the same thing as having someone with whom you can sit around a kitchen table for too long, become progressively less articulate and solve none of capitalism’s problems.

The tragedy was not that everybody around me was shallow or malicious. The machinery worked because I had accepted its measurements. I was evaluating myself and everyone else by proximity to whatever I thought success looked like.

When every relationship had to advance the roadmap, I could no longer simply be close to someone.

Every apartment came with a countdown timer#

The same thing happened to where I lived.

I moved constantly, but not because I wanted every home to become a stepping stone toward a more impressive one. Stockholm’s brutal second-hand rental market made the moving unavoidable. The places available to me were temporary, so the moment I had the keys, the countdown to losing them had already started.

An apartment became storage, a shower and somewhere I might sleep. It was difficult to become attached to a place while knowing I would soon have to dismantle my life and carry it somewhere else again. Arrival did not feel like arrival. It was the beginning of another deadline.

The housing market caused the instability. The grind mindset shaped how I explained it to myself.

Instead of admitting that the constant moving was exhausting me, I treated it as another temporary cost of the life I was building. Endure this apartment. Endure the next move. Once the career, money and everything else finally aligned, stability would arrive as part of the reward package.

The apartment was a staging environment, but not because I had chosen to architect my life that way. I was trying to construct a life inside a system that would not let the ground stay still.

There was always a finish line, but it ran on Kubernetes and rescheduled itself whenever I approached.

I wanted stability, but I confused stability with the maximum visible quantity of success. Those are not the same thing. Living alone in a mansion with seventeen rooms sounds impressive until you realize fourteen of the rooms have not seen a human being since the estate agent took the photographs. That is not abundance. That is running a very expensive museum dedicated to your absence.

The life looked increasingly substantial from outside while becoming almost entirely transitional from within.

Suffering is not an investment account#

I had one foundational theory: if I suffered enough now, I would be rewarded later.

This is one of the more dangerous stories ambitious people tell themselves because it contains enough truth to survive code review. Some worthwhile things are difficult. Learning takes effort. Building something meaningful can be exhausting. Careers contain unpleasant seasons. Caring for people, changing your life and doing work properly will sometimes ask more of you than is comfortable.

But difficulty is a cost, not proof of value.

Suffering does not compound into guaranteed future happiness. There is no loyalty programme. Nobody stamps the little card after each terrible year and gives you the tenth one free, although burnout does make a determined attempt.

I kept treating pain as evidence that the plan must be working. When my life became harder, I did not question the direction. I assumed I needed more discipline. When I became tired, I treated rest as a reward I had not earned. When an achievement failed to make me feel whole, I concluded that the achievement had not been large enough.

The system had one input and one output:

1not enough -> work harder -> still not enough

This is not a growth loop. It is a wood chipper with OKRs.

Eventually, I burned out hard.

Before burnout, photography, games and reading were places I could go to recharge. Afterwards, even those became inaccessible.

For years I could not hold a controller for more than ten minutes. My camera collected dust because when I picked it up, I could not focus enough to use it. The same thing happened with books. Even watching a comfort show or listening to music could require more attention than I had left.

I was too exhausted to do the things that helped me recover from being exhausted. Then I became frustrated with myself for being unable to enjoy them, which only pulled me deeper into depression.

There was nowhere left to flee except into my own head.

It took about five years before I began to feel something resembling normal again and to find real joy in things. I am still not fully recovered. Burnout altered what I could do, how much it cost to do it and how long recovery took.

Was the suffering worth it?

No.

Some of the work was useful. Some jobs gave me experience and credentials that helped me reach where I am now. I can value what I learned without pretending the damage was tuition I had to pay. Good things growing in the wreckage do not retroactively make the collision a transport strategy.

I had outsourced more than my career#

Work was not the only place where I followed somebody else’s requirements.

That took me longer to understand.

Careers make their requirements obvious. There is a title, a salary, a person who decides whether you are doing well and an industry ready to explain which achievement should matter next. The rules may be ridiculous, but at least somebody has written them down.

The requirements I followed elsewhere were quieter.

I spent years trying to become what other people expected me to be. I became good at reading a room, locating the available role and squeezing myself into it. I could work out which parts of me would be useful, impressive or at least unobjectionable, then present those parts as if they were the whole person.

That can look like social competence. Sometimes it is. Being able to understand other people matters. But there is a difference between meeting people with care and rebuilding yourself around every room you enter.

I had spent so long asking what version of me would be accepted that I had almost stopped asking whether that version was true.

I let jobs tell me what success meant. I let social circles tell me which people mattered. I let the instability of every apartment become another cost I was supposed to endure. I let an imagined future audience choose the house, cars and life that would supposedly prove my value.

Then I had to face the possibility that I had applied the same process to my identity.

I honestly think I would have come out as queer and trans much earlier if I had understood sooner that other people do not get to define me.

I do not mean that I had one clear answer hidden inside me for years and simply refused to open the envelope. Lives are rarely that narratively convenient. I mean that I had trained myself not to trust any desire until it had survived everybody else’s imagined review.

Before I could ask what do I want?, my mind produced a queue of other questions.

Will this disappoint someone? Will it make my life more difficult? Will people still understand me? Will they think this is real? Can I justify it? Is there enough evidence? Have I suffered enough to be certain?

Those questions can sound responsible. Together, they meant everybody else received a vote before I was allowed to speak.

I was waiting for permission that nobody could meaningfully give me.

Coming out did not magically remove the habit. I did not cross a clean boundary between a false life and an authentic one while the old requirements disappeared into the credits. I still catch myself looking outside for confirmation that what I feel is sufficiently reasonable. I still sometimes try to build an airtight case for wanting something before admitting that I want it.

But I began to see the pattern.

The career, the friendships, the apartments and the identity were not separate mistakes. They were all consequences of the same decision: I had outsourced authorship of my life.

That realization hurt because it made the scale of the loss visible. I did many impressive things while moving farther away from myself. I could point to jobs, places and achievements, but I had spent years treating the person experiencing them as an implementation detail.

It also gave me somewhere to begin.

There is an important distinction here. I have not stopped caring what other people need or how my choices affect them. Other people have feelings, hopes and expectations. Loving them means taking those things seriously.

It does not mean giving them merge rights.

The question is no longer what version of me will make every room comfortable?

It is what kind of life can I recognize as mine?

That is a much less efficient question. It does not produce a universal roadmap. It has led to fewer status symbols and considerably more discussion of goat infrastructure.

It is also the first requirement I remember writing for myself.

Then I remembered what I actually wanted#

My real dream is not especially compatible with the luxury advertisement playing in my old head.

I want a farmstead. I want a workshop where I can build things and tinker with random electronics until a completely innocent device develops firmware and a personal grievance. I want a reasonable living space with enough room to have people over for board-game nights.

I want a huge kitchen, not because marble worktops will certify my socioeconomic tier, but because I want to cook. I want people leaning against the counters, food taking longer than planned, wine being opened and the evening running past the sensible stopping point. I want a home that participates in my life instead of documenting that I can afford rooms I never enter.

I still have dream cars. They are just very revealing dream cars.

I want an original Fiat 500 restored until it feels factory new, perhaps with a few quality-of-life upgrades because historical authenticity is lovely right up to the moment it begins fighting modern traffic. I also want a mid-1990s-ish Nissan King Cab to restore, perhaps convert to electric and use as a farm truck.

Neither is an obedient symbol of having won capitalism. One is a tiny Italian punctuation mark. The other is a future engineering incident with a cargo bed.

And I want goats.

One of the goats will naturally be named Ralf, because that is law. Ralf will have a suspiciously large goat tower and an enrichment programme with better funding than several public services. The other goats will have names once the naming committee has completed stakeholder consultation.

This dream may sound smaller than the old one. It is not.

The old dream was optimized for being seen. This one is full of things I would still want if nobody were watching.

Joy is not the reward at the end#

Only recently have I started allowing myself to enjoy things without forcing them to justify their place in a five-year plan.

I found my way back to writing. I tinker with random electronics. I can slow down without automatically interpreting it as evidence of personal failure. I spent a week of my vacation playing Factorio because Factorio is fun, not because conveyor-belt routing develops a leadership competency that can be added to LinkedIn.

Although, to be fair, Factorio is an excellent environment for discovering that your beautiful scalable architecture has been starving the copper bus for six hours.

The important part is that the week did not build toward anything. It did not become a side business, video series or carefully quantified recovery sprint. I played a game. I enjoyed it. Nothing was produced except several preventable railway deaths and a factory that had become difficult to explain.

For years I believed joy would be issued at the finish line. I could enjoy life after the career was secure, after the right move, after I became successful enough, after I proved whatever case I thought the universe was hearing.

But the grind does not contain a finish condition.

It knows only how to grind. In the end, the main thing I was grinding down was myself.

The new acceptance criteria#

I am not arguing that nobody should work hard, pursue a demanding career or want expensive things. I still love building difficult systems. I still have ambition. Apparently I am considering an electric conversion of a thirty-year-old farm truck, so nobody needs to schedule an intervention about my lack of projects.

I am arguing for inspecting the requirement before devoting a life to implementing it.

When I want something now, I try to ask:

1Would I want this if nobody could see it?
2Do I want the thing, or the verdict I expect it to deliver?
3What am I sacrificing, and is that cost temporary or simply my life now?
4Does this goal make room for people, rest and joy before it is complete?
5Who wrote this requirement?

Sometimes the answer still points toward hard work. Fine. A meaningful life is not frictionless, and rest is not a personality. But I no longer accept suffering as automatic evidence of progress. I no longer treat friendships as networking infrastructure. I no longer want every hobby to submit a business case.

Take the painting class even if the paintings will be terrible. Spend the vacation playing a factory game whose primary lesson is that manufacturing logistics can colonize a human nervous system. Cook dinner with people who cannot advance your career. Learn something because it delights you. Sit still long enough to notice whether the life you are building contains anywhere you would actually like to live.

You do not have to earn every good moment by converting it into future value.

What is the point of reaching the life you wanted if you trained yourself never to be there while it was happening?

I still want stability. I still want to build things. I still want to grow.

I just want the person doing the growing to survive the process.

A new language, editor or framework appears. Its website has a dark background, one suspiciously perfect benchmark and a code sample compressing twelve deliberately ugly lines into three that nobody has deployed. Within a week, people happy on Tuesday are writing migration plans on Friday.

Then comes the testimony.

I used to love that language, but it sucks. This one is so much better. I am more productive than ever. It is the future of programming.

The future of programming arrives remarkably often for an industry that still cannot reliably centre a rectangle.

I have struggled with this anxiety too. I like my tools. I can solve the kinds of problems I care about with them. Then the internet explains that liking them is evidence of professional decline and that a genuinely serious engineer would have replaced the entire stack before lunch.

After programming since roughly 1994, I have now survived enough futures to notice that most of them become ordinary tools, obscure trivia or abandoned GitHub organisations. The useful question was never whether a tool belonged to the future.

It was whether the tool belonged in my hands.

I do not use the best programming language#

I write a lot of Go. Not because Go is the best language ever written. It is not. Please put the pitchfork back in the monorepo.

I use it because Go maps reasonably well onto how I tend to think about services and systems. Data moves explicitly. Control flow is visible. Deployment often ends with one binary rather than a travelling circus of runtime dependencies. Errors remain in the room instead of teleporting into a distant exception handler wearing a fake moustache.

Go has its little acts of hostility. Error handling can become a geological layer of if err != nil, and the type system spent years responding to requests for generics with the emotional availability of a concrete bollard. Still, I can usually hold the program in my head, find the part that is lying and ship it. That balance works for me.

Sometimes I am an ANSI C enjoyer. C maps better to keyboard firmware, where a tiny metal leg of an STM32 can become both UART and somebody’s punctuation key. C does not protect me from C. That is practically its brand. But when a peripheral register contains the wrong bits, being close to the hardware helps.

At work I use a lot of C# because that is what our integration platform speaks. I also enjoy parts of it. Its mature runtime and tooling let me model dreary business systems without pretending an invoice is a revolutionary distributed-computing primitive.

These languages are not competing to become my personality. They have different costs, failure modes and relationships with my brain.

The closest thing I have to a selection algorithm is this:

1value(tool) = problems_solved
2            - cognitive_friction
3            - operational_cost
4            - migration_tax
5            - amount_of_weekend_lost_to_build_system

There is no term for social-media excitement because social-media excitement has never paged me at 03:00 and repaired a production integration.

None of those choices were made because somebody promised me they were the future.

I have already seen the future#

When I started doing web development, people told me Lasso was the future of the web.

Now, do not be shy. Put up one hand if you have heard of Lasso. Put up both hands if you have actually used it. Keep them up if you are a web developer.

So, zero.

Yeah. Thought so.

Lasso was not uniquely foolish, and the people using it were not idiots. It solved real problems. That is precisely the point. A tool can be useful without becoming the permanent future of its field. It can dominate conference talks and still become something future engineers meet only while excavating an old system.

I have watched this happen to languages, databases, compilers, application servers, package managers, operating systems and enough JavaScript frameworks to make carbon dating a frontend skill.

Some disappeared. Some survived in a niche. Some ideas returned twenty years later with a new logo and a launch post explaining that nobody had ever thought of them before. Meanwhile COBOL continues processing money, C continues operating everything with a memory address, and JavaScript continues escaping every containment strategy devised by computer science.

Predictions about programming are usually predictions about communities, economics and organisational inertia disguised as opinions about syntax. An elegant language can lose because it lacks libraries, documentation or employers willing to bet payroll on it. An irritating platform can survive because replacing it requires three years, forty integrations and the cooperation of a vendor whose support portal only works in Internet Explorer.

Code is never selected in a laboratory. It lives inside teams, budgets, existing systems and the cruel passage of time.

Switching tools is real work#

The standard argument assumes tools are interchangeable skins over the same abstract activity. If editor A has more features than editor B, switch and receive productivity. Product comparison pages do not include the model already living in your nervous system.

I have used some form of Vim for as long as I can remember. These days it is Neovim with a small TUI setup I understand. Its motions are motor memory. Text objects, registers, macros and quickfix lists compose into an editing language that fits how I move through code.

Replacing that is not brew install other-editor. It is replacing thousands of tiny, practised decisions.

People have told me for years that I would be more productive in Emacs, VS Code or whichever JetBrains product currently has enough RAM to develop self-awareness. They recite features without asking which problems my setup solves. I do use VS Code with Lean 4, usually while crying. That may be more about Lean than VS Code. Another editor can be the sensible choice; I just do not owe it a permanent migration.

My terminal preference did not begin as vintage computing cosplay. I spent roughly eight years using laptops without Xorg because terminal workflows made better use of the hardware, let me run more terminals, and the web was still usable through ELinks. Then websites decided documents required GPU acceleration, six megabytes of JavaScript and consent from seventeen tracking vendors. The terminal remained where I could see the system clearly.

Familiarity reduces the distance between intention and result. It can create blind spots, but accumulated fluency has value even if the new tool has rounded tabs and launches 11 percent faster on the founder’s laptop. A migration should solve a problem large enough to pay for what it discards.

The productivity cargo cult#

The cargo cult begins when we copy the equipment of productive people and expect productivity to arrive with it. Someone builds remarkable systems using a modal editor, split keyboard and language released last Thursday. The internet extracts the easy lesson: acquire all three. Nobody can install the judgement, failed projects and quiet practice which did the work, so we buy the props and hope competence appears during the firmware update.

Tools are fun. Configuring an editor can be a satisfying hobby, and a new language can teach you another way to model state or ownership. I built a Kubernetes platform for a static website; I am in no position to arrest anyone for excessive tooling.

The problem is confusing tool activity with problem progress.

You can spend a week moving a working project to the fashionable framework and end with the same product plus newer build errors. You can rebuild an editor into an air-traffic-control dashboard while never writing the thing you opened it to write.

You can have the shiniest tools available and still do nothing all day.

The industry encourages this for one simple reason.

Tools are much easier to market than judgement.

Nobody can sell you ten years of experience in a launch-week discount. They can sell you an AI-powered terminal which summarises the error message immediately above it.

So every tool becomes a lifestyle and every preference becomes a faction. People stop saying this works well for my constraints and start saying anyone still using that is unserious. A local choice turns into a universal law because Twitter has once again slapped its e-penis on the table and mistaken noise for engineering evidence.

That is not technical discussion. It is status theatre with a package manager.

Curiosity without conscription#

None of this means staying inside the same toolchain until the heat death of the universe.

New tools matter. Rust forces useful conversations about ownership and memory safety. Functional languages change how you think about data and effects. A different editor may reveal friction you had stopped noticing. Better debuggers and static analysis can remove entire categories of wasted time.

Curiosity is good. Conscription is not.

Personal fit stops being the only criterion when other people inherit the result. In municipal systems and integration platforms, the best technology for an organisation is often the one twenty engineers can understand, not the one two engineers adore.

The launch enthusiast eventually changes jobs. The payroll integration stays. A boring language with known failure modes, usable documentation and a credible upgrade path can be the more ambitious engineering choice because the organisation can still operate it five years later.

Collective fluency is a system property.

When something shiny appears, I try to ask what specific pain it removes:

• Does it make a problem I actually have easier to express or debug?
• What operational machinery arrives with it?
• Can the team maintain it after the enthusiast leaves?
• Is the ecosystem alive, or merely loud?
• What working knowledge and tooling would the migration discard?
• After the novelty wears off, do I still want to use it?

Sometimes the answer justifies a switch. Sometimes the experiment itself is valuable. Sometimes the new thing is genuinely better and the old tool has become an expensive collection of workarounds held together by institutional memory and one build server nobody is allowed to reboot.

Then move.

But move because you found a better relationship between the tool and the problem, not because a stranger posted a bar chart where the bars began at 97 percent.

Does this bring me joy?#

“Does this bring me joy?” sounds unserious as an engineering criterion. It is still more informative than “is this the future?”

Joy does not mean frolicking through a meadow while the tests applaud. Sometimes the right tool is boring, a team standard outranks personal taste, security support ends or the only maintainer retires to raise goats. Responsible engineering contains many things which do not spark joy.

But enjoyment often points toward cognitive fit: fast feedback, understandable failures, useful constraints and a willingness to return. A tool you enjoy invites practice. Practice builds fluency. Fluency makes difficult work feel possible.

Misery has a cost too, despite the industry’s long experiment with treating it as proof of professionalism.

So have an honest look at whatever you are using. Does it bring you joy? Does it let you do the work in front of you? Do you understand how it fails and can you operate what it produces?

If so, keep using it.

Try new tools because curiosity is one of the pleasures of programming. Learn new languages because each one gives you another angle from which to attack a problem. Replace your setup when the new thing earns its migration cost.

Just stop comparing your toolbox to somebody else’s career performance on social media. There is no magical editor, language or framework that will turn you into a 100x engineer. There is only knowledge, practice, judgement and a long sequence of tools which either help those things reach the machine or get in their way.

The future will arrive whether or not your editor has a minimap.

You still have to write the code.

Why do you only write in English? You are Swedish. Would you not reach more people if you translated the articles? Perhaps add a newsletter while you are there. Maybe publish more regularly. Have you considered SEO? A membership tier? Sponsored posts? Short videos in which the first sentence appears as six different captions while I point at a terminal?

Individually, none of these suggestions is absurd. Translation makes writing available to more people. Newsletters help readers remember that a site exists. Search optimization helps them discover it. Recurring support gives independent writers predictable income. This is all true.

It is also how I ended up spending years doing everything around writing except writing.

This site exists because I eventually escaped that machinery. I am not rebuilding it because somebody found a friendlier name for the conveyor belt.

I used to have a content strategy and no desire to create content#

Many moons ago, there was a younger Ellie who loved writing small rants, long essays and observations about whatever had attached itself to her brain that week.

Then I did what the internet said a writer was supposed to do.

I published on Medium. I was present on every social network under the sun and probably two operating near the moon. I thought about posting schedules, audience growth, headlines, engagement, cross-promotion and which platform wanted which ritual sacrifice that quarter. The internet called this building a personal brand, because developing a stress response to dashboards did not perform as well in search.

The fundamental thing I wanted to do was write. Somehow, writing became the task I squeezed between distributing, measuring and repackaging the writing.

I learned which subjects produced clicks. I learned that a hot take could travel farther than a careful thought. I learned that disagreeing with another writer in public created a neat little engagement loop in which everyone became briefly furious and a platform sold several advertisements.

Sometimes I joined arguments about things I did not care about because I knew people would click. Sometimes I considered a subject I genuinely loved and discarded it because it did not have enough reach. I spent more time predicting what people wanted to read than finding out what I wanted to say.

That changes the work even when nobody explicitly tells you what to write. The dashboard moves into your head. Every idea arrives with an imaginary performance review:

1interesting to me?                 yes
2likely to trend?                   no
3brand-safe?                        uncertain
4sponsor-friendly?                  probably not
5can become a seven-part thread?    please let me die

The mission quietly stops being write something worth writing and becomes feed the machine enough material that it does not forget your name.

Eventually everything became a chore. Then I stopped loving writing. Then I stopped writing for a very long time.

I did not run out of ideas. I ran out of the desire to turn them into content.

This was not a productivity problem. I did not need a better content calendar. I needed to take the content calendar behind the barn and explain that it had served the organisation well.

The pink keyboard would never have passed planning#

The article about my pink keyboard firmware incident is exactly the kind of thing I would not have written back then.

The story began because I went to Gliched, near Elgiganten, and impulse-purchased a NuPhy Halo75 V2 because it was pink. I flashed the vendor firmware, accidentally removed several ISO keys from society, found an abandoned QMK tree, ported thousands of lines onto a modern version, fixed UART pins, Bluetooth, LEDs and latency, and somehow became the maintainer of my own shopping decision.

That is a perfect fieldnote. It is technical, ridiculous, specific and mine.

Under the old rules, it would have died during ideation.

The audience might be too small. The title would be difficult to optimize. Making fun of a keyboard vendor could make another vendor less interested in working with me. Firmware debugging is not a broad lifestyle category. There is no obvious conversion event after the section about an STM32 alternate-function mode. The reader may reach the end without buying anything, which marketing science assures us is a medical emergency.

So the article would have become a generic list of five things to check before flashing keyboard firmware, written for search intent and drained of the part where a pink rectangle turned into a month-long embedded-systems side quest.

It would have reached more hypothetical people and sounded less like me.

That is the trade I am no longer willing to make.

This website is a recovery environment#

The machinery behind this site is, objectively, a bit much. Hugo produces the pages. Tailwind compiles the theme. Woodpecker builds a container. Harbor stores it. Terrakube asks OpenTofu to deploy it onto Kubernetes. A Gateway serves the result with enough security headers to make a bank nod respectfully.

I could have installed WordPress.

Instead, I built a small production platform for a website decorated like a terminal princess. This is what happens when an infrastructure engineer attempts self-care.

The machinery is elaborate, but the writing path is deliberately tiny:

1hugo new content content/fieldnotes/some-ramble.md
2nvim content/fieldnotes/some-ramble.md
3
4# write until the idea stops making dial-up noises
5:wq
6git add
7git commit
8git push

Neovim is my editor. Git is my CMS. Markdown is the only form field. There is no WYSIWYG editor asking whether I want to insert a call-to-action block. There is no publishing dashboard displaying a streak. There is no plugin suggesting that my headline lacks emotional power words.

A fieldnote normally begins as a long and structurally irresponsible ramble. I write the thought before I try to manage it. Later I switch into editorial mode, find the argument hiding under the furniture, move sections around, remove repetitions and make the jokes appear intentional.

That order matters. Creation happens before optimization is allowed into the building.

The site has no advertisements and no affiliate links. It has no sponsored posts. It has no paywall, account system or premium tier containing the paragraph where I finally reveal the UART pin.

It does have a small self-hosted analytics service, but the loader treats privacy signals as instructions rather than decorative browser trivia. If the browser sends Global Privacy Control or Do Not Track, or if the local opt-out is enabled, analytics do not load. Query strings and fragments do not leave the page. What remains is a rough signal that somebody visited, not a behavioural dossier describing which person hovered over which joke before failing to convert.

The useful question is is anyone reading this at all?

There is a Markdown file and, at the far end, another human being.

English is the language in which this voice arrives#

On paper, Swedish is my native language. I was born in Sweden. I speak Swedish every day. I am perfectly capable of writing Swedish.

In practice, English is the language in which these fieldnotes happen.

It is the language in which I think through most technical work: code, infrastructure and the particular flavour of absurdity produced when a vendor firmware image converts working hardware into a support ticket. The rhythm arrives in English. The jokes arrive in English. The first ugly draft arrives in English quickly enough that I can catch the thought before it escapes into another terminal tab.

That does not make English better than Swedish. It makes it the native language of this project.

Consider this line from the keyboard article:

That is not a supply-chain event. That is self-care with USB-C.

Translating the words is easy. Translating the sentence is not. The joke depends on rhythm, contrast, technical vocabulary and the cultural tone of declaring an impulse purchase to be healthcare. A literal Swedish version may preserve the nouns while leaving the cadence dead on the kitchen floor.

A good translation would need to be rewritten. References may need replacing. Sentence lengths would change. Some jokes would need entirely different setups. English technical terms that sound natural in Swedish engineering conversations become strange when everything around them is formally translated. Suddenly I am not translating an article. I am writing a second article that must produce the same emotional checksum from different bytes.

That is real creative work. Translators deserve considerably more respect than being treated as a search-and-replace operation with a flag emoji attached.

It is also work I do not want to add to every fieldnote.

One article becomes a release train#

Suppose every fieldnote exists in English and Swedish.

Now every correction has two destinations. Every changed fact has two versions to audit. Every rewritten paragraph has another paragraph that may no longer say quite the same thing. Internal links need language-aware targets. Metadata needs translating. RSS needs decisions. Search needs decisions. Code samples may remain English while surrounding explanations do not. Screenshots contain text because screenshots are malicious compliance in PNG form.

The publishing model changes from this:

1write -> edit -> publish -> walk away

to this:

 1write English
 2  -> edit English
 3  -> rewrite Swedish
 4  -> edit Swedish
 5  -> compare both
 6  -> publish both
 7  -> discover typo
 8  -> patch both
 9  -> wonder which version contains the newer explanation
10  -> invent a localization pipeline
11  -> somehow end up maintaining a translation memory on Kubernetes

Then somebody reasonably asks for German. Somebody else offers to contribute a French translation. These are kind gestures. They also turn a personal fieldnote into a versioned publication with contributors, review queues and synchronization semantics.

At work, I am quite fond of systems that support several languages, formal review and reliable release management. I am paid to care when the German error message describes a different failure than the English one.

This is not work.

The entire point is that I can spend forty minutes writing about a strange technical discovery, make it coherent later, publish it and go make tea. I do not want every post to arrive dragging a maintenance matrix behind it like a badly configured service mesh.

This is not an argument against translation. Multilingual publishing is valuable. It can be essential for public information, accessibility, education and communities that should not be forced to operate in English. If this site had a public-service obligation, a commercial product or an editorial staff, the decision would be different.

It has one writer with Neovim and a history of optimizing herself into silence.

Constraints are not always failures waiting to be fixed. Sometimes they are the fence around the part you are trying to protect.

What I may build instead#

I may eventually add something like fieldstudies: longer tutorials and technical guides that sit beside the observations, arguments and incident reports. They could help somebody reproduce a system without first reconstructing the decisions from jokes about Kubernetes.

They would carry stronger maintenance promises because instructions rot when software changes. They would still be free, ad-free and without a publishing schedule. Ko-fi would remain a tip jar.

English would remain the working language unless a particular piece genuinely wanted to be written in something else. I may write something in Swedish because its subject, audience or voice belongs in Swedish. What I will not do is maintain this site as a mirrored multilingual product whose completeness must be managed.

One is writing.

The other is localization operations.

I know which one makes me want to open Neovim.

I do not want subscribers waiting for output#

There is an RSS feed. You can subscribe to it in a reader, and the feed will quietly tell your software when I publish something. RSS is excellent because the relationship belongs to the reader. I do not receive your email address. I cannot send a subject line engineered to manufacture urgency. There is no open-rate dashboard asking why you did not click. You leave by deleting a URL from an app. Nobody launches a retention flow.

What I do not want is an email newsletter, membership programme or recurring publishing promise. Once people hand me their inboxes or pay every month, I will feel that I owe them output. They may explicitly say otherwise. My brain will open Jira anyway:

1WRITING-41  publish something before subscribers forget me
2WRITING-42  create exclusive supporter update
3WRITING-43  apologize for not posting
4WRITING-44  turn apology into content

I want to publish three fieldnotes in a week when several ideas catch fire at once, then disappear for two months because I am busy, tired or have nothing worth adding to the global pile of words.

Silence should remain a valid state, not an incident requiring stakeholder communication.

Ko-fi is a tip jar, not a tiny venture-capital round#

I do have Ko-fi. The link sits quietly underneath articles instead of arriving as a modal with a countdown timer and the emotional energy of a casino carpet.

If a fieldnote solved a problem, made you laugh, or convinced you that your own month-long keyboard side quest was medically normal, you can put some money in the tea fund. That is kind. I appreciate it.

If you read the article and leave, that is also the website working exactly as intended. You do not owe me money for allowing your browser to download a static file I deliberately published in public.

I disabled recurring Ko-fi subscriptions on purpose. Recurring money is not morally suspicious, and independent creators deserve to be paid. But for me, a recurring payment would create a recurring obligation even if the person paying insisted otherwise. The support would stop feeling like thank you for this thing and start feeling like please continue producing the expected quantity of things.

The contract I want is much smaller:

1if (someone_sends_coffee_money) {
2    tea += 1;
3    gratitude += a_lot;
4}
5
6editorial_calendar = null;

No supporter-only posts. No early-access tier. No private Discord with seventeen channels and one person typing hello?.

Ko-fi can help pay for tea, domains and whatever piece of hardware has most recently developed a personal grievance. It does not buy influence over what I write next. It does not move a topic up the queue, because there is no queue. It is a gift, not a service-level agreement.

The other reasonable suggestions#

Translation is only one version of the request. The others sound like this:

You are good at writing about technical things. You should write about currently fashionable technical thing. More people would read that.

Maybe they would. But more people would read it is not the same as I have something to say about it. Trend-chasing, sponsorships and affiliate deals all bring the dashboard back into my head, this time wearing a sponsor logo.

So there will be no ads, sponsored fieldnotes or affiliate strategy. I can still mention a product; apparently I can write several thousand words about a keyboard without adult supervision. But it gets no editorial approval, and nobody pays me to discover adjectives for it.

I also refuse to publish on a schedule merely to prove the site is alive. The server has health checks for that.

The grand growth strategy#

The plan for this website is aggressively unambitious:

• Write in the language where the voice feels alive.
• Publish when there is something worth publishing.
• Let RSS notify people without collecting them.
• Keep analytics small, self-hosted and optional.
• Keep Ko-fi one-time, quiet and genuinely optional.
• Do not sell attention to advertisers.
• Do not turn readers into leads.
• Do not confuse a larger audience with a better reason to write.

Perhaps this means the site grows slowly. Perhaps some articles reach fewer people than they could. Perhaps a person who would love a fieldnote never finds it because I failed to perform the correct search-engine courtship dance.

That is acceptable.

The most important metric is not page views, subscribers, recurring revenue or the number of languages in the navigation. It is whether, after publishing one article, I still want to write another.

I lost that once by doing everything correctly.

This time I would rather do it wrong and keep the joy.

Then a public-sector ERP hands you a spreadsheet saying that the credit marker goes in column 140.

Not a property called credit. Not a signed decimal. Column 140. One character. A minus sign if the row is credit, a space if it is debit. The amount next door is the absolute value, expressed using an exact number of positions, and its decimal representation is dictated by whichever Raindance import you are currently trying to appease.

This has been my personal integration hell.

I have built two open-source Frends task packages in this particular mess: MomentumToRaindance, which turns Momentum accounting data into customer invoices, and PigelloSIERaindance, which turns SIE vouchers from Pigello into Raindance entries. The implementations are not the interesting part. I am going to replace a fair amount of that code anyway, as is tradition after learning exactly which assumptions production intends to punish.

The interesting part is the format itself: how to understand it, how to make it deterministic, and how to prove that the invisible spaces are in the correct invisible places.

The request that sounded harmless#

On paper, the job is one sentence.

Take accounting data from system A and import it into system B.

Excellent. Both systems contain numbers. Computers have been moving numbers since before product managers discovered the word “AI.” This should be fine.

System A may even be civilised. Momentum exposes structured data through an API. Pigello exports SIE, an old format but at least one with recognisable records and an existing ecosystem. The source data contains invoices, voucher dates, accounts, dimensions, VAT, row text and amounts.

Raindance wants a text file that looks approximately like somebody flattened a database record with a steamroller:

1K 1510      9997                                                        870       EK23                                              1530000-    Some row text

That line is not meant for human eyes. Its meaning comes from position:

11  3         13        23        33        43        53        63        73        83
2|  |         |         |         |         |         |         |         |         |
3K  konto     ansvar    verksamhet aktivitet objekt    projekt   fri       motpart   källa

Calling it “plain text” is technically correct in the same way that calling a land mine “garden hardware” is technically correct.

The title’s particular act of accounting vandalism looks like this in the invoice K layout:

1field             positions      encoded value
2amount            125–139        "        1530000"
3credit marker     140            "-"

This is a fixed-width positional format. There is no delimiter character to split on. The delimiter is how many positions you have already consumed. Once encoded, those positions must still land on the expected bytes. A field is defined by a one-based start position and a length. Empty fields are not absent; they are stretches of spaces which preserve the position of everything after them.

Delete one space and motpart becomes källa. Add one character to the row text and a periodisation key starts three fiscal years into the future. The file can remain perfectly readable while becoming semantically radioactive.

First, stop looking for the object model#

The natural instinct is to model an invoice and then serialise it. That works for JSON because JSON has structure. Here, the record layout is the structure.

Raindance distinguishes records by the first character or characters. The records currently emitted by the Momentum integration are:

1S  customer
2H  invoice header
3R  invoice row
4K  accounting row

The SIE flow uses an H header followed by one or more K accounting rows. A file is therefore closer to a tiny line-oriented protocol than a document:

1S -> H -> (R -> K+)+

or:

1H -> K+

That distinction matters. A valid field in an invalid record sequence is still an invalid file. So is a valid string encoded using the wrong bytes. So is a line with the right visible contents but the wrong trailing spaces.

The useful mental model is not “export some text.” It is “construct a byte-addressed protocol frame for an accounting system.” Suddenly the spreadsheet starts looking less like documentation and more like a packet layout written by someone who really trusted Microsoft Office.

The spreadsheet is the schema, unfortunately#

Where do you start attacking a format like this?

Not in the string interpolation. Start by turning the spreadsheet into an explicit schema. For every record type, write down only the facts needed to construct and validate it:

1record type
2field name
3one-based start
4length
5requirement
6formatting rule

Then calculate the end of every field:

1end = start + length - 1

Sort by start and reject overlaps unless the format explicitly defines one. Record the final line length. Mark gaps as reserved space rather than pretending they do not exist. A gap is still bytes you must emit.

The first Raindance mapping below ends its K record with 166 positions of “other available space.” That is not an invitation to omit the space. It means the record extends through column 359. The void has a length requirement.

A robust writer begins with a buffer already filled with spaces:

1record = 359 spaces
2put(start: 1,   length: 1,  value: "K")
3put(start: 3,   length: 10, value: account)
4put(start: 125, length: 1,  value: creditMarker)
5put(start: 126, length: 15, value: amount, align: right)

Every put operation should enforce the contract:

• Convert the one-based spreadsheet position to a zero-based buffer offset exactly once.
• Normalise carriage returns and line feeds inside values.
• Apply the field’s alignment rule.
• Reject or deliberately truncate values longer than the field.
• Reject writes beyond the record boundary.
• Encode the final record and verify its byte length, not merely its character count.

That last point is where pleasant Unicode abstractions meet payroll software carrying a chair.

Characters are not bytes, except when the ERP says they are#

The Momentum import expects ISO-8859-1, commonly called Latin-1. Swedish names and addresses therefore need to become the exact single-byte values Raindance expects. If the generated file is opened as UTF-8, å, ä and ö may look broken even when the byte stream is correct for the receiver.

This is more than an editor inconvenience. Fixed-width layouts are often byte layouts disguised as character layouts. UTF-8 encodes an ASCII character such as K as one byte, but ö as two. A 40-character customer name can therefore exceed a 40-byte field even though the runtime reports a string length of 40.

Latin-1 makes the supported Swedish characters one byte each, which preserves the positions, but it introduces another obligation: decide what happens when the source contains a character Latin-1 cannot represent. An emoji in an invoice reference is no longer whimsy. It is a serialisation policy decision.

The safe order is:

1. Normalise the source value.
2. Validate that every character is representable in the target encoding.
3. Truncate or reject according to an explicit business rule.
4. Pad and align the field.
5. Encode the complete line.
6. Assert the expected byte length.
7. Append the required CRLF line ending.

Do not let a library silently replace an unsupported character with ?. Silent substitution is how an organisation number becomes a support ticket three weeks later.

Accounting signs, now sold separately#

Numbers have their own failure mode because these formats do not merely serialise a decimal. They deconstruct it.

In the SIE K layout, the credit marker lives at position 125 and the amount begins at 126. In the invoice-accounting K layout, the amount begins at 125 and the credit marker lives at 140. For an invoice row, the amount begins at 63 and its credit marker lives at 78.

Same target ERP. Similar concept. Different positional contract.

This is why the phrase “Raindance format” is dangerously reassuring. There is no one universal row you can generalise from after seeing it twice. There are record layouts, import routines and local agreements. Reuse the mechanism for placing fields, but keep each schema explicit.

The underlying conversion should be boring and testable:

1source amount:  -1234.56
2magnitude:       123456
3credit marker:   -

For a format with two implied decimal places, multiply the absolute value by 100 using decimal arithmetic, round according to an agreed rule, and render with invariant digits. Then place the sign in its own field. Never inherit numeric formatting from the machine’s current locale. Render exactly the representation prescribed by the selected record layout. The spreadsheet, not the operating system, wins.

This also needs accounting semantics, not just amount < 0. In SIE, debit and credit may be conveyed through the sign. In API data, an amount may arrive with a separate debit flag. When accounting rows are grouped, signs must be applied before summation. Zero-value groups should disappear only if the receiving business rule says so.

The minus sign is one byte. Determining whether it belongs there is the entire integration.

Tables do not map themselves#

The most exhausting work is not writing padding code. It is translating between two unrelated descriptions of reality.

Momentum might call something a customer identity, an official number, a distribution, a ledger row or an account coding string. Raindance wants Kundidentitet, Person-/organisationsnummer, Motpart, Konto, Ansvar, Verksamhet and several optional dimensions with ten characters each.

SIE contributes voucher records and dimension identifiers. A local agreement then decides that dimension 1 is Ansvar, dimension 2 is Objekt, dimension 3 is Motpart, dimension 4 becomes row text, and EK23 is a fixed source code. None of those transformations is difficult in isolation. Together they form a dense pile of tiny obligations:

• Which source field wins when there are two possible references?
• Does a personal identity number retain its separator?
• When is a VAT number constructed from an organisation number?
• Which customer classes map to PRIV, FTG or ÖVR?
• Which account dimensions are mandatory for a particular account?
• Should repeated revenue rows with identical coding be grouped?
• Are rounding rows transferred, ignored or posted separately?
• Is an empty field spaces, zeroes, a fixed default or a rejected invoice?
• Does “optional” mean optional to Raindance, optional for this municipality, or not currently supplied by the source API?

Once those decisions are explicit, padding is the easy part. Until then, the serialiser is merely business policy hiding inside string interpolation.

This is not an algorithmic challenge. It is contract reconciliation. The complexity comes from the number of independent rules and the cost of violating any one of them.

An ERP consultant may describe this as dark magic. It is not dark magic. Dark magic would at least have coherent lore.

It is just fucking annoying.

How to test invisible structure#

These integrations need tests at three levels.

First, test fields. Given a value and a schema entry, verify truncation, padding, alignment, unsupported characters and numeric conversion. Boundary tests matter: empty, exactly full, one character too long, maximum amount, negative amount and zero.

Second, test records. Render a known invoice-accounting K row and assert all of these independently:

1record byte length == schema byte length
2record[0]          == "K"
3record[2..12]      == expected account field
4record[124..139]   == expected amount field
5record[139]        == expected credit marker

The slices above use zero-based, end-exclusive notation. The spreadsheet does not. Mixing those coordinate systems casually is an excellent way to spend an afternoon moving a minus sign between two equally plausible spaces.

Third, test complete files as bytes. A golden fixture should include Swedish characters, long text, debit and credit rows, absent optional dimensions, multiple record types and exact CRLF endings. Compare byte for byte and print a useful positional diff on failure:

1record 4, position 140
2expected: 0x2D '-'
3actual:   0x20 ' '

A normal text diff is not enough. Trailing whitespace is the data, and many diff viewers exist specifically to pretend trailing whitespace does not exist.

I also want a validator that reads the generated bytes back using the same declarative schema. It cannot prove the accounting is correct, but it can prove structural invariants before a file leaves the integration platform:

• Every line has a recognised record marker.
• Every line has the exact byte length for that marker.
• Required fields are populated.
• Numeric fields contain only permitted bytes.
• Credit markers contain either - or space.
• Reserved positions remain spaces.
• The record sequence is legal.

The target system should not be the first parser to encounter the file. Production is an expensive hex editor.

The aha moment#

That makes the correct abstraction obvious: this is a compiler.

You are not “formatting a string.” You are compiling structured source data into a legacy record layout. The compiler has a symbol table—the mapping between source concepts and accounting dimensions. It has a target ABI—the starts, lengths, encoding and line endings. It needs type checking, range checking and deterministic output. The ERP import is the runtime, except its diagnostics may be a Swedish modal dialog last redesigned when Internet Explorer was considered a strategic platform.

The analogy also draws the boundary for reuse. Reuse the fixed-width writer, encoding checks, amount formatters, schema validation and byte-level test tools. Do not bury every Raindance dialect behind one clever universal serialiser with seventeen boolean options. The layouts below disagree in meaningful ways. Make those differences visible as data.

Something like this is easier to audit than a cathedral of interpolated strings:

 1K_ACCOUNTING_SIE = [
 2  field("postmarkering",    1,   1, fixed="K"),
 3  field("konto",            3,  10, required=true),
 4  field("kreditmarkering", 125,  1),
 5  field("radbelopp",       126,  15, align=right),
 6  field("text",            142,  30),
 7]
 8
 9K_ACCOUNTING_INVOICE = [
10  field("postmarkering",    1,   1, fixed="K"),
11  field("konto",            3,  10, required=true),
12  field("belopp",          125,  15, align=right),
13  field("kreditmarkering", 140,  1),
14  field("radtext",         145,  30),
15]

The difference is no longer an implementation accident. It is reviewable documentation.

The post-mortem#

Fixed-width ERP files are archaic, but age is not their worst property. A fixed-width format can be perfectly reliable. It is deterministic, streamable, compact and easy to process in systems that do not want to discover XML namespaces before breakfast.

The real danger is that its schema lives in screenshots, spreadsheets, consultant memory and example files which are almost representative. The format has no field names in transit, weak self-description and little room for graceful evolution. Every unstated assumption becomes a byte somebody eventually has to debug.

So if you inherit one of these integrations, do not begin by admiring the existing string concatenation. Recover the contract:

1. Inventory every record type and legal sequence.
2. Transcribe starts, lengths and requirements into machine-readable schemas.
3. Clarify every numeric, sign, date, encoding and truncation rule.
4. Separate source-system mapping from fixed-width serialisation.
5. Validate record structure before delivery.
6. Keep byte-exact golden files for every important business case.
7. Treat every new spreadsheet revision as an API version, because that is what it is wearing business-casual clothing.

The task is not intellectually impossible. It is precision work performed against a contract whose type system is cell borders.

And yes, the spaces at the end matter.

Appendix A: SIE voucher layout#

Appendix B: Momentum customer-invoice layout#

Kundpost#

Fakturahuvud#

Bilaga#

Fakturarad#

Konteringsrad#

But if you want a complete picture of debts currently being collected from you, the official workflow is apparently remember every company that might have bought one.

This is an interesting definition of digital government.

A debt may begin with a lender, telecom company, landlord, energy supplier, region, online shop or some business whose checkout flow turned pay later into the default because restraint performs badly in conversion metrics. It can then move to an inkasso company, be transferred to a new creditor, migrate again when a portfolio is sold, and acquire a different company name because firms merge, rebrand or emerge from the financial-services spawning pool.

Each participant may have its own portal, case number, payment instructions and authentication flow. Some use BankID. Some send paper. Some use digital mailboxes. Some expect you to locate the correct customer portal from a letter sent three corporate identities ago. The information exists, but it is distributed across organisations whose ownership structures are changing while the citizen is expected to maintain the index.

We have reinvented distributed systems, except the consistency model is anxiety.

I do not think the first answer needs to be abolishing inkasso, redesigning every fee or pretending legitimate debts stop existing when the interface is hostile. Those are separate political arguments, and some are already happening. I want something both less revolutionary and more immediately useful:

Build a minPension for debt.

One secure public portal. Every company conducting inkasso against private individuals connected by law. Every active claim visible to the person it concerns. Current amounts, current owner, original creditor, payment instructions, status, history and the correct place to ask questions or object.

Not debt forgiveness.

Not a new way for lenders to inspect people.

Just the radical proposition that a person should be able to see who says they owe money.

The missing layer#

Kronofogden already has Mina sidor. If a claim has reached the authority, you can see debts, balances and payment demands there. That service is useful.

It is also downstream.

An inkassokrav comes before a debt necessarily reaches Kronofogden. If you act during that period, you may be able to pay, object, correct a mistake or arrange a plan without the claim proceeding further. Once a claim arrives at Kronofogden, additional costs and consequences can follow. The best time to discover an active inkasso case is therefore not when another authority finally receives it.

Today, that earlier layer belongs to whichever companies happen to be handling the claims. The citizen sees fragments; each company sees its own ledger.

This is backwards. The moment when quick action matters most is the moment when the overview is worst.

The fragmentation is not merely annoying. Debt changes how people process information. Financial stress consumes attention and makes administrative tasks harder. Someone managing several claims may also be dealing with illness, unemployment, disability, addiction, separation, insecure housing or a mailbox that has become a paper-based denial-of-service attack.

Our current response is to give that person several portals, reference numbers and opportunities to miss something—then describe the result as personal responsibility.

Personal responsibility requires usable information. You cannot responsibly manage a system whose state is hidden behind an unknown number of vendor dashboards.

We already know this pattern works#

minPension is not the pension company. It does not seize custody of every pension asset in Sweden or answer every question about every policy. It collects information from the Pensionsmyndigheten and participating pension companies, gives the individual a consolidated view, and directs detailed questions to the organisation responsible.

That separation is exactly what a debt portal needs.

The portal would not decide whether a claim is legally valid. It would not replace an inkasso company’s case handling, Kronofogden’s statutory role, municipal budget and debt counselling, or a court. It would not need to hold anyone’s money. It would provide the missing coordination layer between systems that already exist.

The happy path is almost offensively ordinary:

1citizen
2  -> signs in once
3  -> sees every active collection claim
4  -> opens one claim
5  -> sees who currently owns it
6  -> sees who administers it
7  -> sees principal, interest and fees separately
8  -> pays, contacts or objects through verified instructions

This is not moonshot technology. It is an authenticated read model with notifications. Sweden has built more complicated systems to let me declare the sale of a house and check whether a pharmacy has my prescription. We can probably aggregate a few ledgers without first inventing a blockchain and appointing a minister for synergies.

What every company should have to report#

A legal obligation without a common data model is just a future spreadsheet incident. The responsible authority should define a versioned technical standard, certification tests and strict update deadlines. Connection should be a condition of permission to conduct collection activity involving people in Sweden.

For each claim, the minimum useful record should include:

• the original creditor and a plain-language description of the claim,
• the current legal owner and collection administrator,
• a stable identifier that survives transfers,
• original and remaining principal, with interest and fees shown separately,
• the applicable interest rate, important dates and last update time,
• current status, including disputes, payment plans, transfers and closure,
• verified payment instructions, contacts and objection routes,
• and a history of transfers and material status changes.

The stable identifier matters. A debt should not become a new creature merely because a portfolio changed hands. If Company A sells a claim to Company B, the citizen should see one continuous timeline:

1original creditor -> first collector -> new owner -> current administrator

Not three unrelated letters and a side quest through Bolagsverket.

Finansinspektionen’s rules already require useful pieces of this behaviour. Since July 2025, its inkasso regulations say that a collection claim should identify the basis of the claim clearly enough for the debtor to understand and assess it. The rules also require information about whom to pay, whom to contact with an objection, and notification when a claim has been transferred. FI took over full supervisory responsibility under the Inkasso Act in 2024.

So the conceptual obligation already exists: keep records, identify claims, communicate clearly, disclose transfers.

I am asking for the information to be delivered through a standard interface as well, so clarity does not depend on finding every individual envelope.

Put it near Kronofogden, but keep the boundary clear#

Kronofogden is the obvious public home because it already handles debt, enforcement, payment orders and debt restructuring. It already operates services through which people can see claims that have reached the authority. Extending the citizen-facing overview to the stage before enforcement would close the most dangerous visibility gap.

There is a legitimate argument for Finansinspektionen owning the reporting standard because FI licenses and supervises inkasso companies. There is also a legitimate role for Digg in identity, interoperability and digital notifications. Public administration is allowed to contain more than one competent organisation without making the citizen attend the coordination meetings.

A sensible division could be:

1. FI defines reporting duties and sanctions inaccurate or late reporting.
2. Kronofogden operates the citizen-facing service and combines pre-enforcement claims with the information it already holds.
3. Digg provides or certifies identity, notification and interoperability components.
4. Collection companies remain responsible for source data, payment handling and case decisions.

The public portal should clearly distinguish between reported by an inkasso company and established or enforced by Kronofogden. Displaying a claim must not magically grant it legal authority. A disputed claim must look disputed, not acquire a state crest through proximity.

That boundary is essential. The portal is an index and interface, not a machine for converting allegations into judgments.

Authentication should not mean BankID or exile#

The service should support BankID and Freja+, but it should not build permanent dependence on one private identity provider. Digg already lists both among approved Swedish electronic identities, Sweden-id is planned for December 2026, and Sweden is developing a state digital identity wallet under the revised European framework.

Use the national identity infrastructure, support notified European e-identities where required, and design for the European Digital Identity Wallet rather than bolting it on later.

And keep a non-digital route.

A portal does not help someone who lacks an e-ID, device, accessibility support, stable housing or confidence with digital services. The same consolidated view should be available through authorised service channels and municipal budget and debt counsellors. A person should be able to grant a counsellor explicit, limited and revocable access instead of arriving with a carrier bag of letters and hoping it contains the complete economy.

Digital first is fine.

Digital only is how efficiency becomes exclusion while everyone admires the dashboard.

Notifications are prevention infrastructure#

The portal should not only answer when someone remembers to log in. It should notify them when:

• a new collection claim is registered,
• a balance or payment deadline materially changes,
• a claim is transferred to a new owner or administrator,
• a payment is registered,
• an instalment plan changes status,
• a company records or resolves an objection,
• or a claim is about to move to Kronofogden.

Notifications can be sent through digital mail, email or SMS without exposing sensitive details in the message itself. “You have a new update in the national debt overview” is enough. Authenticate before showing the contents. Financial data does not need to appear on a lock screen merely because product management discovered push notifications.

Speed matters. A person who learns about a new claim immediately has more options than a person who finds a forwarded paper letter six weeks later. Early visibility can prevent fees, mistaken payments, missed objections and claims escalating by administrative momentum.

This may be the least dramatic anti-debt policy imaginable: tell people promptly what is happening.

Do not turn it into a lender surveillance portal#

A centralised view of debt is sensitive enough to glow in the dark. Any proposal like this should trigger privacy questions immediately, not after a consultancy has already uploaded production data into an analytics lake called citizen360-final-v2.

The purpose must be narrow: give the individual an operational overview of claims being collected from them, support authorised advice, and allow regulators to enforce reporting quality.

It should not quietly become a general database through which landlords, employers, advertisers or curious lenders inspect people. Sweden has separately discussed debt and credit registers intended to improve credit assessments. That is a different purpose with different access rules and different risks.

The 2023 over-indebtedness inquiry proposed a Skri register covering many consumer credits and payment delays, primarily to give credit providers a fuller basis for lending decisions. That is a different purpose from this proposal, which includes collection claims whether they began as a loan, electricity bill, healthcare fee, rent or subscription because the citizen needs a complete action list.

Access should be tight: the person concerned, an explicitly authorised representative, the reporting company for its own records, and authorities only where law and purpose require it.

No search by neighbour.

No “financial wellness partners.”

No targeted offers for consolidation loans arriving eleven seconds after login.

No lender API disguised as consumer empowerment.

The citizen is the user, not the data source.

This does not replace the harder reforms#

On 9 July 2026, the government published SOU 2026:43, Åtgärder mot överskuldsättning. It proposes changes to debt restructuring and a special order for allocating payments on overdue consumer claims. The larger debate includes absolute limitation periods, how payments are divided between principal, interest and fees, lending practices, and how people remain trapped as so-called eternal debtors.

Those questions matter.

At the beginning of 2026, almost 450,000 people had debts registered with Kronofogden. The total was SEK 154 billion, up twelve percent in one year. More than thirty percent consisted of interest and fees. This is not an edge case affecting twelve unusually disorganised people and a man called Conny who refuses to open mail.

A portal will not solve unaffordable debt. It will not make an unjust claim just, lower an interest rate, create income, negotiate an instalment plan or repair the consequences of decades of over-indebtedness.

But material reform and usable administration are not competing ideas.

While politicians, creditors and consumer organisations fight over fee structures and limitation periods, we can also stop forcing debtors to perform corporate archaeology. Better information helps under the current rules and under whatever rules replace them. It helps people who can pay immediately, people who need a plan, people who need counselling and people who need to dispute a claim that is wrong.

It may even help inkasso companies. Fewer payments sent with obsolete references. Fewer calls asking who owns a claim. Fewer cases escalated because a notice disappeared during a transfer. A shared standard makes compliance auditable instead of interpretive theatre performed separately in every customer portal.

This is why the principle should be hard to oppose, even if the implementation will not be. It does not abolish anyone’s right to collect a legitimate debt. It does not decide the politically difficult question of what a creditor may charge. It says that if a regulated industry is allowed to pursue individuals for money, it must also publish accurate case data into a public interface those individuals can actually find.

That is not an attack on collection.

That is the minimum observability requirement for a system with consequences.

The diagnosis#

Sweden does not lack debt data. Creditors have it. Inkasso companies have it. Kronofogden has the part that reaches Kronofogden. Municipal counsellors reconstruct it manually with the people asking for help.

What Sweden lacks is a citizen-facing read model.

We would never accept an online bank that said, “Your money is probably held by four institutions. Please remember which ones, authenticate to each separately, account for any mergers, and call around if the totals look incomplete.” That is close to how we handle debt, where missing one record can have much worse consequences than forgetting an old savings account.

Debt is not a moral exemption from interface design.

People who owe money still have the right to accurate information, timely notice, accessible services and a complete view of decisions affecting them. Making a debt easier to find does not make it easier to escape. It makes it easier to address.

Build the standard. Require every collection company to connect. Authenticate the citizen once. Show the original creditor, current owner, current collector, full balance, status, history, next deadline and verified action routes. Send immediate private notifications when something changes. Keep lender access out. Preserve non-digital support.

We already built minPension to answer a difficult question about money spread across institutions and decades:

What will I have?

Now build the version that answers the question people are currently expected to solve with letters, browser tabs and dread:

What do I owe, and who do I owe it to today?

Your photos live in one company’s building. Your email lives in another. Your documents, passwords, conversations, calendar, finances, recipes, artwork and half-finished thoughts each occupy a furnished little room in somebody else’s data centre. The rent looks harmless because it arrives in twelve separate subscriptions, each priced somewhere between “a coffee” and “surely I cancelled this.”

Then the landlord changes the terms.

The free tier shrinks. The export button develops strong religious objections to portability. A feature you relied on moves into the Business Pro Max Enterprise Friendship Edition. The monthly price rises because the product now contains an AI assistant you did not request and cannot fully disable. A new paragraph appears in the terms of service granting the company broader rights to process what you upload. You receive an email titled We’re updating our terms, written in the warm, bloodless dialect corporations use when the update is mandatory and the explanation would frighten the horses.

Your options are to accept or leave.

Leaving means discovering that five years of your life have been stored in a format best described as “technically JSON.”

This is why I built a bare-metal cluster.

I built it because convenience had slowly turned into dependency, dependency had turned into exposure, and exposure had started to feel reckless.

I wanted a boundary I controlled.

The decision was less philosophical than the rest of this essay may make it sound. I looked at where the authoritative copies of my life actually lived and realised that almost none of them were under my control. Photographs existed primarily in somebody else’s library. Documents depended on accounts that could be repriced or closed. Conversations and creative work were scattered across companies whose future owners I could not predict and whose terms I could not negotiate. There was no single cinematic betrayal; just more irreplaceable data and fewer credible exit routes.

So I rented two dedicated machines. Each has a six-core Ryzen 5 3600 and 64 GiB of memory. One contributes two 2 TB spinning disks; the other has two 512 GB NVMe drives. Talos runs the nodes, Kubernetes schedules the applications, Cilium moves the packets, Rook Ceph turns four disks into storage, and OpenTofu records enough of the arrangement that future me has at least a fighting chance.

This is not the architecture I would sell to a bank. It is the architecture I chose for one person who wants custody, useful capacity and the ability to replace parts without rebuilding an entire digital life from memory.

We asked for the cloud, and for good reasons#

SaaS did not conquer the world solely through deceit and decorative gradients. It solved real problems.

Software used to arrive in a box. You bought a version, installed it, discovered that the installer needed three floppy disks in an order known only to the Oracle at Delphi, and eventually owned a working copy. Businesses ran servers in cupboards where the air conditioning was theoretical and the backup tape had last been tested during the Blair administration. If the disk died, your software did not float gracefully into another availability zone. It became a learning opportunity.

Salesforce made the subscription model culturally legible in 1999: business software delivered through a browser, without every customer maintaining the whole stack. Then Amazon launched S3 and EC2 in 2006, turning storage and compute into APIs instead of a procurement process involving six signatures and a Dell sales representative. The cloud made infrastructure previously reserved for large organisations available to anyone with a payment card and insufficient supervision.

That change was genuinely liberating. Small teams could deploy globally. Managed databases removed a category of 03:17 phone calls. PaaS products went further: push code, let somebody else care about the operating system, routing, certificates, autoscaling and the endless parade of CVEs produced by software continuing to exist.

Each layer removed work. Each layer also removed control.

At first that exchange was obviously worthwhile. Usually it still is. I do not want every hospital writing its own video-conferencing stack or every bakery operating an email server because somebody on the internet shouted “digital sovereignty” through a mouthful of ethernet cable.

The problem was not renting software.

The problem was allowing rented software to become the only place our lives existed.

Cloud software is different. What you buy is not an object. It is an ongoing relationship with an organisation whose incentives can change.

The service can be excellent and the people building it can care deeply. None of that suspends economics. The company may be acquired; investors may demand growth; the cheap product that attracted millions may now be expected to extract more money from them. Previously included features migrate upward through pricing tiers like frightened woodland animals escaping a forest fire.

And the company has three assets it can monetise:

1. The product.
2. Your attention.
3. Your data.

The first is respectable but apparently insufficient for the infinite-growth machine. The second gave us the advertising internet. The third has become extremely interesting now that every executive presentation contains the phrase AI strategy and at least one arrow pointing toward a cylinder labelled DATA.

I do not need to believe everyone involved is malicious. Incentives are more scalable than malice.

AI made the ownership problem impossible to ignore#

Generative AI did not invent extractive data practices. Advertising platforms, data brokers and recommendation systems had already industrialised those. AI changed the perceived value of the material.

Photos became potential training data. Posts became a language corpus. Voice recordings became speech data. Documents, illustrations and source code became examples from which models might learn.

The response across the industry has not been uniform, and accuracy matters here. The policies below were checked in July 2026; terms mutate like bacteria under a heat lamp. “Every company trains on all your private data” is a satisfying sentence and a bad argument.

Adobe prompted users to re-accept terms in 2024 and caused an entirely predictable panic among creators. Adobe subsequently clarified that it had not trained generative AI on customer content and promised to put that commitment into its legally binding terms. Its own explanation acknowledged that companies hosting creative work must be precise about what rights they claim and why.

That was a better outcome than people initially feared. It also demonstrated the power imbalance: each creator had to determine whether a broad licence was operational boilerplate or a combine harvester approaching their life’s work.

Other companies are explicit about using content. Meta announced plans to train its models on public posts, comments, photos and captions shared by adults in Europe, with a process through which users could object. Meta’s own description says exactly that: it wants to train on public content from European users.

Public posts are not private photo libraries, product improvement is not always generative-model training, and an opt-out is not an opt-in. We should criticise what companies actually do, not flatten everything into a single sinister blob wearing a conference lanyard.

But the pattern still bothers me. The default relationship is increasingly that a service receives broad access, the policy evolves, and the user is responsible for noticing, understanding and finding the correct toggle. Consent becomes a scavenger hunt conducted inside an interface the company can redesign tomorrow.

I am not against AI. I patched Mealie to use a language model for recipe imports, an act that combined artificial intelligence, Kubernetes and dinner with a level of restraint rarely seen outside defence procurement.

Machine learning is useful. Generative systems can translate, summarise, classify, help people write code and make interfaces more accessible.

The unresolved question is what we are entitled to feed them.

Training useful models requires a great deal of data. That does not make every accessible work ethically ownerless. “It was on the internet” is a description of network reachability, not a theory of consent. A forum post written to help one stranger debug a kernel panic was not necessarily offered as free industrial feedstock forever.

My position is not “stop developing models.” Tell people what is collected. Distinguish operating a service from training a new product. Ask before using private material, make refusal as easy as acceptance, respect creators’ reservations, and document sources well enough that accountability is possible. Do not call extraction innovation merely because it ends in matrix multiplication.

I will send some data to an AI service when the purpose is clear and the material appropriate. That is different from storing the canonical copy of my private life there and hoping its next business model remains charming. Agency is the point.

Privacy is not a confession#

Whenever privacy comes up, somebody announces that they have nothing to hide.

This sounds brave until you ask them to publish their passwords, medical history, private messages, bank statements, precise location, family photographs, search history and every unfinished thought they typed at 01:40 and wisely deleted.

Nobody actually has nothing to hide. What they mean is that they do not currently expect the information collected about them to be used by somebody hostile.

That is a prediction about power, not a fact about data.

Privacy scholar Daniel Solove has spent years dismantling the “nothing to hide” argument. Its central failure is treating privacy only as secrecy about wrongdoing. Privacy is also protection against aggregation, exclusion, distortion, secondary use, loss of context and systems making decisions about us that we cannot inspect or challenge. His essay, “I’ve Got Nothing to Hide” and Other Misunderstandings of Privacy, remains annoyingly relevant.

One isolated fact may be harmless. A collection becomes a map.

Your photographs reveal relationships, locations, homes, routines and health. Email reveals who you know and which institutions you depend on. Calendar entries reveal where you will be. Search history reveals fears before you have words for them. Metadata can reveal that two people communicate regularly even when the messages themselves are encrypted.

The danger also changes over time. Data collected under one government, one management team or one social norm remains available when those conditions change.

This matters to everyone. It matters especially to people whose safety has historically depended on controlling context.

I am queer. With the brown wave rising again across Europe and elsewhere, I do not consider it paranoid to ask how identity, relationships, location and private communication could be used under a more hostile political order. Rights that look settled can become campaign material. Healthcare can become evidence. A social graph can become an investigative lead. A list created for advertising can become useful to an authority with a different mandate.

The Electronic Frontier Foundation and Access Now have warned that data concerning sexual orientation and gender identity can enable surveillance and violence against LGBTQ+ people, and have argued for stronger protection of that data in a submission to the UN Independent Expert on sexual orientation and gender identity.

You do not build privacy only for the government you trust.

You build it for the next government, the next acquisition, the next database breach, the next policy update and the next executive who looks at a table of user content and sees an unmonetised asset.

Encryption changes who is capable of betraying you#

A privacy policy is a promise. End-to-end encryption is an architectural constraint.

Those are not equivalent.

If a service can read your data, it may do so for legitimate operational reasons. It can also be breached, compelled, acquired, misconfigured or persuaded by a future policy. Access may be carefully audited and restricted, but the capability exists.

With correctly implemented end-to-end encryption, the service does not possess the keys required to read the content. It can still expose metadata, clients can still be compromised, participants can still take screenshots, and backups can quietly ruin the whole arrangement if designed by a committee. E2EE does not solve every problem. It does remove the service operator from one extremely important trust boundary.

Self-hosting and end-to-end encryption solve different problems. Self-hosting changes who operates the service. E2EE limits what even the operator can read. Where possible, I want both.

Signal describes the principle plainly: its service is designed so it does not have access to message contents, and it also works to minimise retained metadata. The expensive part of Signal is not drawing a blue send button; it is maintaining a system deliberately built to know less about its users. Its explanation of the costs and architecture is worth reading: privacy is priceless, but Signal is expensive.

European data-protection authorities likewise describe encryption as necessary for privacy and free expression. The European Data Protection Supervisor warns that weakening or circumventing E2EE through backdoors or key escrow destroys its effective protection. Its encryption overview is much less ambiguous than most political proposals involving the phrase “lawful access.”

The recurring demand for systems that are private except when the correct authority asks is cryptographic astrology. A backdoor available only to good people is not a security property. It is a staffing assumption.

For queer people, journalists, activists, abuse survivors, migrants, healthcare workers and anyone living under a government with authoritarian ambitions, secure communication is not a decorative civil liberty. It is infrastructure.

Why bare metal, and why a cluster?#

The argument so far would justify a NAS, a VPS running Docker Compose, a managed Nextcloud provider, or three Raspberry Pis committing distributed-computing offences behind the television.

All of those can be good answers. Mine was dedicated servers because the workload stopped being one application and started becoming a small platform.

Photos are the largest part. Immich wants substantial storage, background processing, PostgreSQL with vector search, a machine-learning worker and room for the library to grow. Matrix, Vaultwarden, Mealie, Actual Budget, Outline, Grist, SearXNG, monitoring, CI and the rest add databases, caches, object storage and persistent volumes. Individually they are modest. Together they want predictable memory, direct disks and enough spare capacity that an update does not turn the scheduler into a Victorian workhouse.

Bare metal gives me dedicated RAM and CPU, direct access to the storage devices, predictable monthly capacity and no metered egress between my own workloads. Ceph can use the real disks rather than virtual volumes rented from the same abstraction it is trying to replace. Large photo and backup transfers do not produce a bill that reads like a ransom note.

Why two machines? One server would be simpler, but compute, storage and the control plane would all share one machine and one failure domain. Because both nodes are schedulable, Kubernetes can move stateless workloads and give me somewhere to move work while maintaining a node. Some databases can also place replicas apart. The second machine added fast NVMe storage alongside the larger spinning disks.

Why Kubernetes? Because it is the operational model I know and enjoy. It gives me declarative deployments, health checks, scheduling, identity integration, storage primitives and enough YAML to prevent dangerous levels of free time. Most of these applications could run under Docker Compose. I am not claiming a Deployment object makes the grocery list taste better.

Why Ceph? Applications need several kinds of persistence. RBD provides block volumes, CephFS provides shared filesystems, and RGW provides S3-compatible object storage. One storage system can serve PostgreSQL volumes, application PVCs, media and backup objects while allowing a disk to be replaced without teaching every application a new ritual.

Now for the sentence storage people have been holding their breath for: two nodes do not make a production-grade Ceph cluster.

There are four OSDs across the two machines and pools use two replicas with the CRUSH failure domain set to osd, not host. Ceph guarantees different OSDs, but both copies may still land on the same machine. The layout protects against an individual OSD failure; losing a host can mean restoration, not merely an outage. The cluster also has one Kubernetes control-plane node and one Ceph monitor.

This design is distributed. It is not highly available.

That is a deliberate cost and complexity boundary, not a hidden triumph. A third node would allow proper etcd and Ceph monitor quorum and stronger host-level replica placement. Until then, the second node improves maintenance options and some failure handling; it does not transform two computers into three.

The answer to “what failure can this survive?” is therefore specific: individual pods, processes and OSDs can fail without losing the whole service. A node or control-plane failure becomes a recovery event rather than a transparent shrug. Loss of the entire cluster requires restoration from somewhere that is not the cluster.

Distributed systems remain stubbornly opposed to inspirational arithmetic.

The cheapest invoice is not always the lowest cost#

This is where self-hosting evangelists traditionally produce a spreadsheet proving they save €14 per month, provided their labour has no value and hard drives emerge spontaneously from woodland soil.

Together, including their IP addresses, the two servers cost €78.80 per month before VAT, or €98.50 with Swedish VAT. They replace several subscriptions and provide terabytes of raw storage, 128 GiB of memory and twelve physical CPU cores across the cluster. Buying that capacity as separate managed databases, object storage, photo hosting, CI, monitoring and application plans would be expensive. Buying only the few consumer subscriptions I strictly need might be cheaper.

Then there is labour:

1Systems administration: financially catastrophic if invoiced honestly

I do enjoy this work. Debugging Cilium at two in the morning is not cheaper if accounted for honestly, but it is at least my preferred genre of regrettable decision.

The financial case works for my collection of storage-heavy services. The larger case includes control, portability and privacy. Sometimes the cheapest service has a low invoice because you are paying with lock-in, attention, exposure or the future difficulty of leaving.

A boundary, not a fortress#

Moving data onto my own infrastructure does not automatically make it safe.

Google has security teams, redundant data centres, hardware supply-chain programmes, abuse detection and people who understand email delivery at a depth normally associated with ocean trenches. I have strong opinions, two servers and a TODO file containing the phrase do these first.

The present architecture makes those limits concrete. Database backups written into the same Ceph cluster are useful for logical recovery, but they are not disaster recovery from loss of that cluster. Until encrypted off-site copies, external etcd snapshots and a tested restore path exist, this remains a migration in progress rather than a finished risk-management system. A green dashboard does not negotiate with a failed disk.

Backups are a process. Merely possessing backup-shaped objects is storage-themed optimism.

There is also concentration risk. Earlier I said that a collection becomes a map; this cluster deliberately assembles much of that map inside one administrative domain. A compromised administrator, identity provider or recovery account could reach several services at once.

Some mitigations already exist: applications have separate credentials and namespaces, while sensitive interfaces use restricted network paths. Independent recovery credentials, off-site copies and regular restore drills are still work to complete. One login button across everything is convenient. It is also a blast radius wearing a friendly logo.

Self-hosting changes the threat model. It reduces exposure to platform policy changes and mass commercial data use while increasing exposure to my mistakes, targeted attacks and hardware failures. A personal server is a small target with an administrator who occasionally deploys after midnight.

The correct questions are not “cloud or self-hosted: which is secure?” They are: which failures am I preparing for, who can access the data, who can change the rules, how do I leave, where are the backups, and what happens when I am wrong?

If those questions have no answers, the deployment model is branding.

The cloud gave us extraordinary capabilities. I do not want to reverse that history; I want its next part to be less extractive. Convenience should not require surrendering control over our memories and creative work. AI development should not pretend consent is implicit wherever a crawler can reach. Privacy should not be a luxury feature, and encryption should not be weakened because inaccessible data is administratively inconvenient.

Digital sovereignty is not a binary state. It is the practice of reducing unnecessary dependence and making the remaining dependencies explicit.

You do not need a bare-metal Kubernetes cluster to move in that direction. Export your photos. Keep local copies of documents. Use a password manager and E2EE. Choose services with credible business models and usable exports. Use a NAS if that solves the problem. Learn where your data goes.

Sovereignty is a direction, not a rack size.

My cluster is not a fortress. It is a boundary. I have not eliminated landlords; I have made them replaceable. A provider may still evict the machines, but it does not get to evict me from my own data. The SaaS vendors I chose not to use never receive the authoritative copy in the first place.

That matters more to me now than it did ten years ago. The industry is consolidating, generative AI has made data newly valuable, and the political weather is getting worse. Under those conditions, keeping intimate information inside systems I can inspect, move and shut down feels less like a hobby and more like basic risk management.

I still love technology. I love it enough to want better from it.

So I built the cluster: two servers, too many databases, several thousand lines of OpenTofu, and one very expensive way to say that my life is not an untapped dataset.

There is a very specific kind of optimism involved in clicking Import recipe and expecting a food blog to become structured data.

The page has a 900-word childhood memory, three newsletter pop-ups, an autoplaying video, twelve affiliate links, two incompatible versions of the recipe, and—somewhere beneath the GDPR consent manager—a list containing 1 cup of flour.

Computers love this. It is basically archaeology, except every pottery fragment has a Pinterest button attached.

I only wanted somewhere nice to keep recipes.

More specifically, I wanted to cook food from more cultures and stop cycling through the same handful of meals like a cron job with low self-esteem. Swedish comfort food is lovely. So are Sichuan pork, Malaysian mushroom korma, Serbian meat rolls, Polish cabbage rolls, Italian ragù, British cakes, and whatever delicious thing I discover at 23:40 while browsing recipes instead of sleeping.

That is how I arrived at Mealie: an open-source, self-hosted recipe manager. It stores recipes, images, categories and tags; builds meal plans and shopping lists; scales quantities; organizes cookbooks; and imports recipes from the web. In other words, it is the sensible domestic application I needed, so naturally I deployed it onto Kubernetes with PostgreSQL, OIDC, persistent Ceph storage, Gateway API routing, and backups.

Some people keep recipes in a binder. I keep mine behind a CloudNativePG cluster. We all have coping mechanisms.

The incident report#

Mealie’s URL importer is genuinely useful. Paste a recipe URL and, in the happy path, a complete recipe appears with its title, image, ingredients, instructions, times and servings. That is the kind of feature that feels like magic until you import recipes from several countries and discover that the magic has regional settings.

One recipe says 2 cups flour. Another says 200 millilitres whipping cream. A third says 1 EL Öl. Temperatures alternate between Celsius and Fahrenheit depending on which side of the Atlantic currently has custody of the oven. Instructions arrive with decorative entries such as Make the sauce occupying a whole step, followed by the actual instruction in the next step. Ingredient parsing occasionally decides that preparation notes are foods, units are philosophical suggestions, and fractions are an attack on its family.

What I wanted was less “preserve whatever the page happened to publish” and more this:

 1Source:
 21 cup water
 3Bake at 375°F.
 4Make the sauce:
 5Add the garlic, lemon juice and stock to the pan.
 6
 7Normalized:
 8240 ml water
 9Bake at 190°C.
10To make the sauce, add the garlic, lemon juice and stock to the pan.

Nothing revolutionary. Just consistent measurements, an oven setting compatible with the continent where my oven lives, and instructions that do not mistake typography for cooking.

Translation adds another layer. I do not want culturally specific dish names flattened into bland English product copy, but I do want instructions in one language I can reliably follow while holding a hot pan. Hui Guo Rou should remain Hui Guo Rou; the paragraph explaining when to add the doubanjiang can be English. This is a semantic decision, not a string replacement.

Under the hood, Mealie’s first URL strategy uses hhursev/recipe-scrapers, an impressive Python library with parsers for hundreds of recipe sites plus schema.org/JSON-LD support. For extraction, this is excellent engineering. Most competent recipe sites already publish machine-readable Recipe data because search engines reward them for doing so. The scraper can collect that data deterministically, quickly, locally, and without paying an API bill every time somebody wants soup.

The limitation is not that recipe-scrapers fails at its job. The limitation is that its job is scraping.

It can tell me the source says 1 cup all-purpose flour. It should not casually decide whether that means 120 g, 125 g, or 140 g, because volume-to-weight conversion depends on the ingredient and sometimes on how enthusiastically somebody packed the cup. It should not rewrite an entire Polish recipe into natural English, decide that a visual section heading is not a cooking step, preserve a culturally meaningful name, and keep the converted temperature consistent everywhere it occurs.

That is no longer extraction. That is editorial normalization with consequences. A deterministic scraper is a very good postal worker; I was becoming annoyed that it would not also translate the letter, convert the measurements, remove the advertising, and check whether the instructions made sense. A wildly unfair performance review.

The fallback that never fell back#

Mealie already has OpenAI integration. It also supports custom prompt files through OPENAI_CUSTOM_PROMPT_DIR. Lovely. I wrote custom prompts, mounted them into the container, enabled an AI provider, and imported a normal recipe URL.

Nothing changed.

This was not an AI problem. It was an ordered list problem, the natural predator of engineering confidence.

At the time of this deployment, Mealie’s default scraper order was:

1DEFAULT_SCRAPER_STRATEGIES = [
2    RecipeScraperPackage,
3    RecipeScraperOpenAITranscription,
4    RecipeScraperOpenAI,
5    RecipeScraperOpenGraph,
6]

Mealie tries each strategy and returns the first usable result. RecipeScraperPackage is the wrapper around recipe-scrapers, and on most recipe pages it succeeds. That means the loop returns before RecipeScraperOpenAI ever gets a turn. My magnificent custom scrape prompt was mounted correctly and being ignored with flawless reliability.

Fallbacks only happen when the first choice fails. A result can be technically successful and still not be the result you wanted. Distributed systems engineers know this as “Tuesday.”

So I applied a tiny, deeply impolite patch:

1DEFAULT_SCRAPER_STRATEGIES = [
2    RecipeScraperOpenAI,
3    RecipeScraperPackage,
4    RecipeScraperOpenAITranscription,
5    RecipeScraperOpenGraph,
6]

That is the whole behavioral change. OpenAI gets first refusal; the regular scraper remains as a fallback.

I call it monkey-patching because that communicates the correct level of shame, although technically it is a containerized file overlay. My OpenTofu creates a ConfigMap containing the patched recipe_scraper.py and mounts it over the installed module inside Mealie’s container:

1volume_mount {
2  name       = "scraper-patch"
3  mount_path = "/opt/mealie/lib/python3.12/site-packages/mealie/services/scraper/recipe_scraper.py"
4  sub_path   = "recipe_scraper.py"
5  read_only  = true
6}

The custom prompts are mounted separately under /app/custom-prompts, and Mealie is pointed there with:

1OPENAI_CUSTOM_PROMPT_DIR=/app/custom-prompts

Checksums of the environment, Secret, prompt data and Python patch live in the Deployment’s pod-template annotations, so changing any of them causes Kubernetes to roll the pod. Infrastructure as code is wonderful because even my crimes against package ownership are reproducible.

There is an obvious maintenance bill: the patched file is copied from Mealie’s installed version. Every Mealie upgrade now requires comparing that upstream module and verifying the path, imports and strategy interface still match. If upstream changes the scraper pipeline, my ConfigMap could replace new code with an old assumption and produce cuisine-flavoured sadness.

Do not cargo-cult this patch into production and then blame Python when an upgrade explodes. The repository README contains a large warning because future me deserves at least one witness.

What the AI path actually does#

The clever part is that Mealie does not ask the model to emit its internal database objects directly.

RecipeScraperOpenAI strips the page into text, appends its JSON-LD blocks, finds a likely recipe image, and sends that material to the model with the recipes.scrape-recipe prompt. The model returns a JSON representation of a schema.org Recipe. Mealie then wraps that JSON in a tiny fake HTML document as an application/ld+json script and passes it back through the existing package scraper and cleaner.

1web page
2  -> visible text + JSON-LD + likely image
3  -> GPT-5.6 Luna
4  -> JSON representation of a schema.org Recipe
5  -> synthetic <script type="application/ld+json">
6  -> existing recipe-scrapers/Mealie cleaning path
7  -> stored recipe

It is an adapter wearing a fake moustache so the mature import pipeline accepts the model’s output. I mean that affectionately. Reusing the existing validation and cleaning path is much safer than creating a second route into the database just because the words “AI integration” have entered the meeting.

Choosing Luna instead of hiring the Sun#

I used GPT-5.6 Luna, the fastest and least expensive member of the GPT-5.6 family.

The family has three tiers:

• Sol is the flagship: the most capable option for hard coding, scientific, cyber and long-running agentic work.
• Terra balances capability and cost for everyday professional work.
• Luna is the fastest, lowest-cost tier.

At launch, OpenAI priced GPT-5.6 per million tokens at $5 input / $30 output for Sol, $2.50 / $15 for Terra, and $1 / $6 for Luna. The ratios are wonderfully easy: for the same token profile, Terra costs 2.5 times Luna and Sol costs five times Luna.

Sol would be spectacular overkill here. I am not asking the model to prove a theorem, coordinate agents across a week-long migration, or discover a novel compiler vulnerability. I am asking it to look at 8 oz cream cheese and return roughly 225 g cream cheese without turning the author’s life story into Step 4.

Terra would also do the job, but the workload does not justify paying 2.5 times more unless testing shows a meaningful quality difference. It did not. Recipe extraction is bounded, repetitive, strongly instructed, and produces structured output. Luna already has much more linguistic and reasoning ability than this task needs.

Using the biggest available model for every workload is not architecture. It is standing at the kitchen counter slicing chives with a rescue helicopter.

The prompts became the product#

The default Mealie prompts are intentionally compact. Its stock scrape-recipe.txt is essentially: extract recipe data from webpage content as schema.org Recipe, do not invent information, and return {} when there is not enough data. The stock ingredient prompt adds sensible basics about order, ambiguity, ranges, multilingual grammar and common units.

Those defaults have to work for everyone. Mine only has to work for my kitchen, where I want English recipe text, metric measurements, Celsius ovens, exact unit abbreviations and no instruction step whose sole contribution is Make the sauce.

I could not get that behavior from the default prompts because they never ask for it. Models are capable, not psychic. “Extract this recipe” does not secretly mean “apply Ellie’s house style, but preserve the epistemological integrity of dumpling nomenclature.”

The full custom prompts live with the deployment, and I have also published both prompts in their full, gloriously over-specified form for anyone who wants to read the actual incantations instead of my civilized summary. Their jobs break down like this.

Prompt one: scrape and normalize the whole recipe#

scrape-recipe.txt is the large one. It tells Luna to:

1. Find the actual recipe. Prefer the author’s content over navigation, SEO text, advertising, comments, subscription prompts and related recipes. Deduplicate responsive layouts, print views and repeated metadata.
2. Return one schema.org Recipe object. Unsupported fields are omitted, insufficient pages become {}, and invented data is forbidden.
3. Normalize measurements sensibly. US customary units become practical metric values, Fahrenheit becomes Celsius, but teaspoons, tablespoons, counts and package units remain when conversion would make the recipe worse.
4. Avoid laboratory cosplay. 1 cup water can become about 240 ml; it must not become 236.588 ml, because my measuring jug has not completed a metrology doctorate.
5. Use a unit house style. Metric units become mg, g, kg, ml and l; kitchen units become tsp and tbsp. No grams in one ingredient, g in the next, and grammes arriving later with a fake passport.
6. Keep countable things countable. 4 cloves garlic remains natural language. It does not become 4 units garlic cloves, a phrase only a procurement database could love.
7. Clean the instructions. Every step needs a concrete cooking action. Heading-only steps are removed or merged into the following action. Temperatures and repeated quantities must agree with the normalized ingredient list.
8. Translate into natural English. Titles, descriptions, ingredients and instructions are translated, while proper nouns, brands, place names and culturally specific dish names survive when translation would reduce precision.
9. Choose the food image. Prefer the main finished-dish image, reject logos, portraits, ads, pixels and decorative nonsense, and return one absolute URL.
10. Audit itself. The prompt ends with a validation checklist covering ingredient order, unit forms, practical quantities, action-only instructions, image URLs and unsupported claims.

That final checklist mattered more than I expected. Long prompts are not automatically good prompts; often they are merely documentation that bills by the token. But explicit invariants gave Luna something concrete to verify before returning the JSON.

Prompt two: parse ingredients without eating any#

After importing, Mealie can parse ingredient strings into structured quantity, unit, food and note fields. My parse-recipe-ingredients.txt prompt treats that as a lossless transformation:

1"2 tbsp olive oil, plus more for frying"
2
3quantity: 2
4unit: tbsp
5food: olive oil
6note: plus more for frying

Its most important rule is one input ingredient in, one structured ingredient out, in exactly the same order. Never merge, split, remove, reorder or invent ingredients. If a fragment is uncertain, preserve it in the note instead of confidently throwing it into the void.

The rest handles vulgar fractions, mixed numbers, written numbers, ranges, grouped quantities such as 2 dozen, canonical units, preparation notes, multilingual grammar and ambiguous tokens. It explicitly separates recognition from output: the model may understand tablespoons, tbs and tbsp, but the stored unit must be exactly tbsp.

This distinction sounds fussy until shopping-list aggregation meets tablespoon, tablespoons, tbsp and T. Normalization is how four aliases stop pretending to be four pantry items.

The two prompts deliberately have different language policies. Whole-recipe scraping translates non-English recipes into English. Ingredient parsing preserves its source language unless translation was explicitly requested, because it may be invoked independently on an existing recipe. Context matters. Apparently even dinner needs an API contract.

Eight commits, one afternoon, several unit-related opinions#

The prompts did not work perfectly on the first attempt because nothing works perfectly on the first attempt except rm -rf, and that works much too well.

I tested against recipes from different sites, languages and formatting traditions. Then I inspected what Mealie actually stored, found a new species of nonsense, tightened an invariant, and tried again. The deployment history records eight prompt-and-scraper refinements on July 13 alone.

Early versions said “convert to metric” but did not constrain the final vocabulary, so long unit names still leaked through. Then I required abbreviations. The model produced heading-only instruction steps, so the prompt gained action tests and merge rules. Images needed stricter selection. Counts needed protection from over-normalization. Translation needed an explicit boundary around culturally meaningful names. Ingredient parsing needed stronger lossless guarantees.

Prompt engineering, at least the useful kind, looks less like wizardry and more like property-based testing conducted by an increasingly opinionated cook:

1invariant: ingredient_count(output) == ingredient_count(input)
2invariant: every instruction contains a cooking action
3invariant: Fahrenheit does not survive normalization
4invariant: supported metric units belong to {mg, g, kg, ml, l}
5invariant: culturally meaningful names are not translated into oatmeal

The goal was not to describe every possible recipe on Earth. The goal was to identify failures I actually observed and convert them into rules precise enough to test on the next import.

The bill, featuring an anticlimactic amount of capitalism#

After all the prompt testing and importing roughly thirty recipes, the OpenAI platform reported:

• 73 requests
• 360,724 total tokens
• $0.73 spent
• 0 blocked requests

That is about one US cent per request across the entire messy test session, or roughly two and a half cents per finished recipe if I unfairly charge all prompt-development traffic to the thirty recipes. Future imports should be cheaper because I am no longer repeatedly asking the model whether millilitres means ml and then updating a text file when it gets creative.

With the same token mix, Terra would have cost about $1.83 and Sol about $3.65. None of those totals would endanger the household economy, but cost discipline is a habit. The correct question is not “can I afford the flagship?” It is “does the flagship improve this workload enough to justify five times the price?”

For parsing recipes, Luna’s answer was already good. Sol cannot make 190°C more Celsius.

The aha moment#

The original scraper and the model are not really competitors. They solve different layers of the problem.

recipe-scrapers extracts what a page says. Luna applies a house policy to what it means. Mealie’s existing cleaner then converts the result into application data. The small Python patch merely changes which specialist speaks first.

That layering is why the result feels much better than replacing everything with “AI.” Deterministic code still fetches pages, controls the strategy pipeline, validates schema-shaped output, cleans fields and stores data. The model handles the fuzzy boundary where language, culture and inconsistent measurements make rigid parsers miserable.

The lesson is not that every scraper needs an LLM. Most do not. If you need faithful extraction from known sites, recipe-scrapers is faster, cheaper and more predictable. My requirement was different: translate, normalize, preserve meaning, reconcile repeated values, and enforce a personal editorial standard across many sources. That is precisely where a language model earns its tiny invoice.

The post-mortem#

My Mealie library now contains food from the places I wanted to explore, with English instructions, sensible metric quantities, Celsius temperatures, useful images and ingredients that can participate in shopping lists without developing multiple identities.

The final system is wonderfully disproportionate:

• Mealie runs as a single restricted Kubernetes pod.
• CloudNativePG stores the database.
• Authentik handles OIDC.
• OpenTofu mounts custom prompts and one patched Python module through ConfigMaps.
• GPT-5.6 Luna turns hostile food-blog archaeology into a normalized JSON representation of schema.org Recipe data.
• The regular scraper remains available when the AI path cannot help.

Would a notebook have been simpler? Yes. A notebook also refuses to translate a Serbian recipe, convert the oven temperature, build a shopping list and roll itself after a prompt checksum changes. Checkmate, paper.

The patch is small. The prompts are not. That is the real shape of this project: six rearranged lines of Python opened the route, but most of the engineering went into defining what “a clean recipe” actually means.

If you try something similar, start with the cheapest capable model, test on hostile real-world inputs, write down invariants instead of vibes, and keep deterministic validation on both sides of the model. Also leave yourself a very loud upgrade warning when you mount a ConfigMap over somebody else’s Python package.

Future you will already be maintaining Kubernetes for a recipe manager. Be kind to her.

So there I was at Gliched, near Elgiganten, doing the responsible adult thing: impulse-purchasing a NuPhy Halo75 V2 because it was pink, cute, and I needed a new keyboard. That is not a supply-chain event. That is self-care with USB-C.

Then I did what any normal person would do after buying a keyboard: I went to the manufacturer’s website, downloaded the firmware for the model I owned, flashed it, and expected my keys to continue being keys.

This was my first mistake. My second mistake was assuming “firmware for this model” included the ISO version of this model. My third mistake was having hope, which remains the most dangerous undefined behavior in consumer electronics.

The firmware flashed fine. The keyboard booted. The RGB did its little capitalism rainbow. And then the ISO keys were dead.

Not metaphorically dead. Actually dead. The useful Scandinavian/European bits of the board, the keys that make an ISO keyboard an ISO keyboard instead of an ANSI board wearing a taller Enter key as a disguise, simply stopped participating in society. The < > key, the section/sign key, the extra punctuation choreography, all gone sideways.

I had taken a working keyboard and converted it into a very expensive pink argument.

The incident report#

NuPhy published firmware for the Halo75 V2, but the downloadable build was effectively for ANSI. Flash that onto an ISO board and the matrix does exactly what firmware always does: precisely the wrong thing, with confidence.

I asked NuPhy for the ISO firmware. They could not provide it.

This is the part where the story should end with a support link, a zip file, and maybe a mild amount of shame about flashing vendor firmware like it came from a reliable civilization. Instead, the trail led to an abandoned-looking GitHub repository containing NuPhy’s QMK source for the ANSI version.

The good news: source code existed.

The bad news: it was old QMK source, vendor-shaped, copied across variants, and written in the dialect of embedded C where every file has three jobs, six globals, and at least one function name that looks like it was translated through a fax machine.

The worse news: I was now emotionally invested.

On June 16, 2026, the first commit landed on the nuphy-keyboards branch:

13064e8c506f Start working on ISO version of the halo75 v2 and add woodpecker

That commit was not a delicate edit. It added a full ISO variant: keyboard metadata, keymaps, LED tables, RF code, side LED code, sleep handling, VIA support, and CI. About 4,800 lines of “I bought this keyboard yesterday and now apparently I maintain it.”

At this point, the problem looked simple in the same way a leaking pipe looks simple before you learn the wall is load-bearing.

The ISO board needed:

• the right matrix positions,
• the right ISO keycodes,
• the right VIA definition,
• the right LED map,
• and the firmware to stop treating Nordic punctuation like optional DLC.

So I fixed keymaps. Then fixed keymaps again. Then fixed RGB. Then fixed an invalid matrix position. Then did some more layout fixes. The commit log from June 16 is basically firmware debugging as a cardio exercise:

1Fix invalid matrix position
2Maybe keyfixes for iso?
3Fix rgb
4Fix keymaps
5Fix keymaps
6Fix keymaps
7Minior layout fixes

Yes, “Minior.” The typo is part of the archaeological record. Leave it in the museum.

The rabbit hole#

The original NuPhy source was based around QMK 0.25.7-ish. Current upstream QMK had moved on to 0.33.7. That does not sound like a huge jump if you think version numbers are decorative. In firmware land, it means APIs moved, config schemas changed, old aliases disappeared, and whatever worked before now has the social stability of a JavaScript build tool after a minor release.

On June 18, the branch became nuphy-on-current, and this happened:

1977cf375c51 Port nuphy keyboards onto QMK 0.33.7; strip non-nuphy keyboards

That was the forklift upgrade. The old NuPhy code got dragged onto modern QMK, and the repo was stripped down so it was no longer carrying the entire keyboard directory like a cursed shipping container.

The migration broke in all the ways you would expect and several ways you would not unless you have personally offended an STM32.

QMK had renamed metadata expectations. Some keyboards had keyboard.json; newer QMK wanted info.json in the right places. RGB matrix coordinates needed to validate as integers. Old RGB keycodes had been deprecated, so the firmware needed modern RM_* names instead of legacy RGB_* aliases. EEPROM datablock functions had changed shape. GPIO helpers had changed names. ChibiOS configuration needed attention.

None of this is glamorous. This is the work where a compiler looks at you and says, “I see you brought me 2024 code. Unfortunately, this is 2026, and I have developed standards.”

Then came the proper embedded bugs, the ones that do not politely fail at compile time.

The keyboard that typed from the wrong pins#

The best bug was the UART pin conflict.

The Halo75 V2 uses an STM32F072 talking to an nRF wireless module. The keyboard matrix also uses MCU pins. This is normal until the firmware configures the wrong pins for UART and accidentally turns matrix columns into a serial peripheral.

That is not “a bug.” That is a séance with scan codes.

The QMK UART driver defaulted to pins that were fine in some universe, just not this one. On this board, USART1 needed PB6/PB7. Without overriding the UART TX/RX pins, the driver defaulted to A9/A10, which were matrix columns 13 and 14. So when rf_uart_init() ran, it reconfigured keyboard matrix pins as USART pins, and the keyboard started inventing input like it had discovered improv.

The fix landed at 05:15 on June 19:

1dea005ec792 Fix Nuphy Halo75 V2 ISO: LED matrix, typing, and UART pin conflict

That commit brought the board back toward reality: restore the IS31FL3733 compatibility macros, fix I2C addresses, re-enable the RF housekeeping path, bring the RGB matrix power rail up at the right point, restore DMA config, add missing LED positions, and force the UART pins to the board’s actual hardware.

This is the part of firmware work where the abstraction stack politely excuses itself and you are left reading datasheets like a medieval monk with a logic analyzer.

Then Bluetooth still did not work.

The keyboard would show the pairing blink locally, but nothing appeared in the Bluetooth device list. That is a special kind of insult: the UI says “pairing,” the radio says nothing, and your laptop says “new phone who dis.”

The next commit found it:

149352a2a3ac Fix RF/Bluetooth: set UART_TX/RX_PAL_MODE = 0 for STM32F072

On STM32F072, USART1 on PB6/PB7 uses alternate function 0. QMK’s default UART alternate-function mode was 7, appropriate for STM32F4-style expectations, but wrong here. AF7 on those pins was not USART1. The nRF module was never receiving the command to advertise. The keyboard was blinking into the void.

Firmware debugging is mostly asking, “is the hardware lying, is the code lying, or did I accidentally configure a comparator output and call it Bluetooth?”

The answer, as usual, was yes.

The LED side quest, because of course there was one#

Once the keyboard typed, the LEDs demanded legal representation.

The Halo75 V2 has 128 LEDs driven by IS31FL3733 chips. The main keys, status indicators, battery/system lights, and side/rim LEDs all share the stage. This is fine until RGB animations decide the entire LED array belongs to them and overwrite status indicators like a startup founder overwriting a database with a Notion export.

The commit log from late June 18 into early June 19 reads like someone negotiating with a disco:

1Fix side LED bugs so it leaves status leds alone
2Fix rim animations overwriting status LEDs
3Fix custom RGB matrix effects overwriting status LEDs
4Fix startup animation power_play_index bound
5Slow down startup animation timing for smoother effect
6Skip status LED indices in startup animation to prevent interference
7Prevent animations from turning off status LEDs
8Add rgb_matrix_indicators_user hook to restore status LEDs after built-in effects

The architectural fix was to separate responsibility. QMK RGB matrix effects can draw the main keyboard lighting, but status and side LEDs need to win at the end of the frame. Otherwise the keyboard loses the ability to tell you useful things like battery, mode, and “please stop turning my indicators into vaporwave.”

Later, that turned into a cleaner shared implementation:

1776478e78ab Major refactor, share the code between ansi and iso as much as possible

Before that refactor, ANSI and ISO carried duplicate copies of RF code, side LED code, sleep code, headers, and config. That is how you grow two firmware variants that look related but fail in different accents. The refactor pulled shared behavior up into keyboards/nuphy/halo75_v2/, leaving the variants to describe what is actually different: physical layout, keymaps, and LED zoning.

The result was smaller, less duplicated, and less likely to require fixing the same UART bug twice. A low bar, yes, but embedded firmware is built on respecting low bars. They are usually connected to ground.

The performance pass#

After the board typed and lit up, it still felt sluggish.

There is a very specific humiliation in making a boutique mechanical keyboard feel worse than a three-dollar office keyboard that has seen things in a municipal procurement closet. The Halo75 V2 had side LED work, RF housekeeping, UART command handling, sleep handling, and RGB animation all sharing a tiny real-time budget. Blocking waits in hot-ish paths are how you turn “firmware” into “firm maybe later.”

So June 19 turned into a latency cleanup:

1cf1f86e9329 Remove blocking waits from hot-ish paths
28f1c1a0b4d7 Cap rgb animations at approx. 60 fps
31b5728b8298 Coalesce/drop low-priority deferred UART commands
40314ae48b22 Harden RF parser and make device reset non-blocking
51b9638856b3 Remove dead ack-wait from uart_send_cmd, convert sleep callers to deferred

The idea was straightforward: keep the main loop moving. Do not block the scan path waiting for decorative work. Do not make a factory reset freeze the firmware for over a second. Do not let low-priority UART chatter pile up while key reports are trying to leave the building.

This is the point where “keyboard firmware” stops being a keymap and becomes a tiny cooperative scheduler with lighting and emotional baggage.

The RF parser also got stricter. Instead of trusting arbitrary packet lengths and setting ACK/sync state too early, it started validating command-specific lengths and resetting RX state on parse exits. In C, optimism is not a strategy. It is how you spend Saturday night discovering that one stale byte can become a lifestyle.

The HID console plot twist#

Then came the weird one: Cmd+V behaved strangely.

At this stage, it was reasonable to suspect ghosting. The keyboard had already had a real UART/matrix pin conflict. The firmware had just been ported across years of QMK changes. There were RF paths, NKRO reports, modifier state, layers, debounce, and a physical matrix all involved. Plenty of suspects. Nobody had an alibi.

So I added a debug console:

10de414bd565 debug: add matrix/report debug console for input diagnostics

It can be enabled like this:

1qmk flash -kb nuphy/halo75_v2/iso -km via -e CONSOLE_ENABLE=yes

The console logs raw matrix rows, debounced rows, per-column masks, key events, layers, mods, weak mods, oneshot mods, and the row state at the moment each event fires. It is intentionally cheap: compare MATRIX_ROWS, skip output if nothing changed, allocate nothing, and print only when useful.

This is exactly the kind of tool you write when you are convinced the machine is gaslighting you and you would like timestamps for the deposition.

And then the console proved the keyboard was innocent.

The “ghosting” was me.

Because of nerve damage in my left hand, I was accidentally bumping Ctrl without feeling it. So Cmd+V was sometimes not Cmd+V in the clean little mental model where fingers are reliable peripherals. The firmware was fine. The matrix was fine. The report was fine. The bug was an accessibility mismatch between switch resistance and sensory feedback.

That is the kind of debugging revelation that makes you stare at the ceiling for a moment.

Hours of firmware investigation. A custom HID console. Matrix masks. Modifier reports. RF paranoia. And the fix was not a bitmask.

The fix was replacing the Ctrl switch with one that has higher resistance, so I can feel when I bump it.

Honestly? That is beautiful. Annoying, but beautiful.

Software people love pretending all bugs live in software. Embedded work cures you of that disease. The system includes the PCB, the MCU, the wireless module, the firmware, the operating system, the desk, the key switch, and the human hand attached to the debugging session. Ignore any layer and it will eventually file a bug report in production.

The post-mortem#

By June 20, the branch had reached:

1d1fe40f3bcc Minior bugfix

The repository is public, if you want to inspect the suffering in its natural habitat: myceliatrix/qmk_firmware.

From June 16 to June 20, the firmware went from “I would like my ISO keys back” to a modern QMK 0.33.7 port with:

• ISO and ANSI variants,
• shared Halo75 V2 firmware code,
• VIA-compatible keymaps,
• fixed ISO matrix/key positions,
• working LED matrix and side LED zoning,
• IS31FL3733 compatibility fixes,
• UART pin and alternate-function fixes for STM32F072,
• RF/Bluetooth housekeeping restored,
• USB suspend behavior fixed for wireless mode,
• fewer blocking waits,
• a stricter RF parser,
• deferred UART command handling,
• and a HID console that found a human factors bug wearing a firmware costume.

This is why “just flash the firmware” is a cursed phrase. Firmware is not an app update. Firmware is a tiny treaty between silicon, timing, voltage, physical switches, protocol state, and somebody’s hand at 01:07 in the morning.

The lesson is not “never buy a pink keyboard impulsively.” That would be cowardice, and also aesthetically wrong.

The lesson is: if a device ships with QMK, source matters. If the vendor only publishes one layout’s firmware, layout matters. If an old firmware tree works, the exact QMK version matters. If wireless goes quiet, alternate functions matter. If keys appear haunted, matrix logs matter. And if your body is part of the input system, switch feel matters too.

Also, before assuming your firmware is broken, maybe check whether your Ctrl key is being lovingly shoulder-checked by a hand with partial sensation.

But still write the debug console.

Future you deserves receipts.

This is perhaps excessive for a personal website. That is also the point.

A static site is one of the nicest places to practice infrastructure discipline because the application itself is brutally simple. There is no database migration trying to eat your evening. No websocket fleet. No “just one background worker” that secretly wants to become a platform. The whole runtime requirement is: please serve these files over HTTP without doing anything cursed.

So this post is a tour of the whole thing. Not just the Hugo bits in this repository, but also the deployment estate in /Users/ellie/talos/opentofu-apps/augustini-wtf, because that repo is the other half of the creature. One repo makes the artifact. The other repo tells the cluster how to run it.

The shape of the system#

There are two repositories involved:

• augustini.wtf: the website source, Hugo theme, Tailwind source CSS, Woodpecker pipeline, and scratch-image Dockerfile.
• talos/opentofu-apps/augustini-wtf: the OpenTofu workspace that creates Kubernetes resources and Gateway API routes for the site.

The deployment path looks like this:

 1git push
 2  -> Woodpecker builds Hugo site
 3  -> Tailwind emits the final theme CSS
 4  -> Hugo writes public/
 5  -> Docker Buildx packages public/ with static-web-server
 6  -> Harbor receives latest and a timestamp tag
 7  -> Woodpecker updates Terrakube variable image_tag
 8  -> Terrakube runs the OpenTofu workspace
 9  -> Kubernetes Deployment rolls to the pinned image
10  -> Gateway API sends augustini.wtf traffic to the Service

The design goal is boring in the good way: the website repo should not need cluster credentials, my laptop should not be the deployment authority, and Kubernetes should not run an image named latest while everyone politely pretends that is a version.

Hugo: the part that makes pages#

The site is Hugo with a local theme named techprincess. The root hugo.toml is intentionally conventional:

1baseURL = 'https://augustini.wtf/'
2title = 'Ellie Augustini'
3theme = 'techprincess'
4enableRobotsTXT = true
5summaryLength = 24

Content lives under content/: home, about, fieldnotes, projects, and individual project/fieldnote pages. Hugo’s content model does most of the routing without ceremony. A post under content/fieldnotes/foo.md becomes a fieldnote. A project under content/projects/foo.md becomes a project page. The theme layouts decide how those sections feel.

The theme is very much not a generic “minimal fieldnotes” theme. It is a terminal UI cosplay machine, but with the useful parts kept and the fake-terminal nonsense mostly avoided. The base layout wraps the page in a bordered panel with a title bar, three colored dots, a scanline overlay, and then regular semantic HTML inside it:

 1<body class="min-h-screen bg-background text-foreground font-mono antialiased">
 2  <a class="skip-link" href="#main">...</a>
 3  <div class="...">
 4    <div class="... border border-border bg-card ...">
 5      <div class="... border-b border-border bg-secondary/60 ...">
 6        <span class="... bg-pink"></span>
 7        <span class="... bg-gold"></span>
 8        <span class="... bg-mint"></span>
 9        <span>ellie@princess: ~</span>
10      </div>
11      <div class="scanlines">
12        {{ partial "header.html" . }}
13        <main id="main" tabindex="-1">
14          {{ block "main" . }}{{ end }}
15        </main>
16      </div>
17    </div>
18    {{ partial "footer.html" . }}
19  </div>
20</body>

There is a real skip link. The main region is focusable. The terminal aesthetic is allowed to be cute, but it is not allowed to eat the accessibility basics.

The theme: one font, many little constraints#

The visual system is all Iosevka, all the time. The font files are self-hosted from themes/techprincess/static/fonts/, so the finished site does not ask Google Fonts, Bunny, Adobe, or some random CDN for permission to render text.

The full Iosevka latin woff2 files are about a megabyte each, which is silly for a site whose pages are a few hundred kilobytes. After Hugo writes public/, a small Python step (scripts/subset-fonts.py, run via npm run subset-fonts) walks every rendered .html, collects the set of characters actually used, and runs pyftsubset over each source font to produce a subset covering exactly those glyphs (plus a small safety set for the footer clock and CSS content bullets). The source fonts stay untouched; only public/fonts/ is rewritten. The result is roughly 4 MB of fonts shrinking to about 195 KB total, with no visible difference.

Tailwind is used as a compiler and constraint system, not as a browser dependency. package.json has the important scripts:

1{
2  "scripts": {
3    "build:css": "tailwindcss -i themes/techprincess/assets/css/source.css -o themes/techprincess/assets/css/main.css --minify",
4    "subset-fonts": "python3 scripts/subset-fonts.py",
5    "build": "npm run build:css && hugo --minify && npm run subset-fonts",
6    "serve": "npm run build:css && hugo serve --disableFastRender"
7  }
8}

The Tailwind config scans Hugo content and layouts, the theme JS, and both Hugo config files. It also enables Iconify’s dynamic selectors so the templates can use classes like icon-[lucide--heart] and icon-[simple-icons--forgejo] without manually vendoring SVGs into every partial.

The palette is expressed as OKLCH tokens in source.css:

 1:root {
 2  --background: 0.16 0.012 300;
 3  --foreground: 0.92 0.015 330;
 4  --card: 0.2 0.015 305;
 5  --primary: 0.8 0.16 350;
 6  --accent: 0.86 0.16 168;
 7  --pink: 0.82 0.17 352;
 8  --mint: 0.86 0.16 168;
 9  --gold: 0.87 0.15 92;
10  --lilac: 0.8 0.12 300;
11}

Tailwind maps those into named colors:

1colors: {
2  background: 'oklch(var(--background) / <alpha-value>)',
3  foreground: 'oklch(var(--foreground) / <alpha-value>)',
4  pink: 'oklch(var(--pink) / <alpha-value>)',
5  mint: 'oklch(var(--mint) / <alpha-value>)',
6  gold: 'oklch(var(--gold) / <alpha-value>)',
7  lilac: 'oklch(var(--lilac) / <alpha-value>)',
8}

That means the layouts can stay readable: border-pink/60, text-muted-foreground, bg-secondary/50, and so on. No component library. No design token runtime. Just CSS variables, Tailwind’s build step, and a strong preference for rectangles with manners.

Hugo pipes: cache-busted assets without a bundler-shaped monster#

The theme uses Hugo’s asset pipeline for the final CSS and JS includes.

In development, CSS is linked directly:

1{{- with resources.Get "css/main.css" }}
2  {{- if hugo.IsDevelopment }}
3    <link rel="stylesheet" href="{{ .RelPermalink }}">
4  {{- else }}
5    {{- with . | fingerprint }}
6      <link rel="stylesheet" href="{{ .RelPermalink }}" integrity="{{ .Data.Integrity }}" crossorigin="anonymous">
7    {{- end }}
8  {{- end }}
9{{- end }}

In production, Hugo fingerprints it and adds an integrity attribute. The JavaScript gets the same treatment after passing through js.Build with minification enabled outside development.

The browser JS is intentionally tiny. It does two things:

1. Adds the dark class to the document element.
2. Adds copy buttons to Chroma code blocks, stripping line number spans before writing text to the clipboard.

There is also a small inline footer clock and a privacy-aware loader for the site’s self-hosted Umami analytics. The loader respects Do Not Track, Global Privacy Control and the local opt-out, while removing query strings and fragments before a page view leaves the browser. This means the live browser behavior is not zero JavaScript, but it is measured in teaspoons. There is no client router, hydration pass, state manager, session recorder, or marketing attribution ritual.

Syntax highlighting: Chroma, but dressed for the room#

Hugo uses Chroma for syntax highlighting. The config keeps classes enabled:

1[markup.highlight]
2  noClasses = false
3  style = 'monokai'
4  lineNos = true
5  lineNumbersInTable = false
6  tabWidth = 2

The style = 'monokai' line mostly stops being the story once noClasses = false is set. Hugo emits semantic token classes, and the theme CSS decides what those classes mean.

Keywords become mint. Types and tag names become pink. Functions become gold. Strings become lilac. Comments get shoved into the quiet corner at muted 60 percent opacity, as comments deserve. Line numbers are non-interactive, unselectable spans, which matters because copy buttons clone the code block and remove .lnt and .ln before copying.

The result is syntax highlighting that belongs to the same visual world as the rest of the site. It does not look like somebody taped a Dracula code block onto a different website and fled the scene.

Woodpecker: from source tree to artifact#

The CI pipeline is .woodpecker/publish.yml. It runs on pushes and manual events.

The first step uses node:22-bookworm-slim, because the build needs npm for Tailwind and Hugo for the static site. Hugo is installed explicitly from GitHub releases:

1hugo_version='0.162.1'
2case "$(uname -m)" in
3  x86_64) hugo_arch='linux-amd64' ;;
4  aarch64|arm64) hugo_arch='linux-arm64' ;;
5  *) echo "Unsupported CI architecture: $(uname -m)" >&2; exit 1 ;;
6esac
7curl -fsSL "https://github.com/gohugoio/hugo/releases/download/v${hugo_version}/hugo_extended_${hugo_version}_${hugo_arch}.tar.gz" |
8  tar -xz -C /usr/local/bin hugo

Then:

1npm ci
2npm run build
3test -f public/index.html
4date -u +%Y%m%d%H%M%S > .release_tag
5printf 'latest,%s\n' "$(cat .release_tag)" > .tags

That .tags file is for the Docker plugin. Every build gets latest for convenience and a UTC timestamp tag for deployment. The timestamp is the important one. latest is a bookmark. The timestamp is a version.

The container: static-web-server inside scratch#

The image build is wonderfully rude:

 1FROM ghcr.io/static-web-server/static-web-server:latest AS sws-binary
 2
 3FROM scratch
 4
 5COPY --from=sws-binary /static-web-server /sws
 6COPY ./public /public
 7
 8ENV SERVER_PORT=8080
 9ENV SERVER_ROOT=/public
10
11EXPOSE 8080
12
13ENTRYPOINT ["/sws"]

It copies the static-web-server binary out of the upstream image, copies Hugo’s public/ directory, and then runs from scratch.

There is no shell. No package manager. No CA bundle unless the binary and app need one, which this site does not for serving local files. No busybox escape hatch. If someone gets arbitrary command execution inside this container, their prize is a filesystem containing a web server binary and some HTML. It is the infrastructure equivalent of opening a safe and finding a polite note that says “no.”

Static Web Server listens on 8080 and serves /public. The site is pure static output, so it does not need an application runtime. The container is not where logic lives. The container is where files wait to be sent.

The publish-image Woodpecker step uses woodpeckerci/plugin-docker-buildx, pushes to registry.augustini.xyz/sites/augustiniwtf, and targets linux/amd64.

The handoff: Woodpecker pokes Terrakube, not Kubernetes#

The deploy step is where the two repos shake hands.

Woodpecker does not run kubectl apply. It does not carry a kubeconfig. It does not patch a Deployment directly. Instead, it calls the Terrakube API.

The script:

1. Reads .release_tag.
2. Finds organization v0cloud.
3. Finds workspace augustini-wtf.
4. Finds Terraform variable image_tag.
5. Patches that variable to the new timestamp.
6. Finds the template named Plan and apply.
7. Creates a Terrakube job for that workspace/template pair.

This is the most important boundary in the deployment. Woodpecker is allowed to produce an artifact and request a deployment. Terrakube is the thing allowed to evaluate and apply infrastructure.

That gives a cleaner audit trail: source build in Woodpecker, stateful infrastructure action in Terrakube, actual reconciliation in Kubernetes.

After deployment, Woodpecker also prunes Harbor artifacts. It keeps five non-latest artifacts with timestamp tags matching ^[0-9]{14}$, deletes older artifacts by digest, and sweeps any already-untagged artifacts left behind by previous cleanup runs. This is housekeeping, not heroism, but housekeeping is how registries avoid becoming museums of forgotten builds.

OpenTofu: the other repo#

The OpenTofu workspace in /Users/ellie/talos/opentofu-apps/augustini-wtf is small, which is exactly what you want for an app layer.

It uses OpenTofu >= 1.12.0, < 1.13.0 and the HashiCorp Kubernetes provider ~> 3.1.0. The lock file pins provider checksums. The provider config supports both local validation and Terrakube execution:

1provider "kubernetes" {
2  config_path = var.kubeconfig_path != "" ? var.kubeconfig_path : null
3}

Locally, set kubeconfig_path. In Terrakube, leave it empty and let the runner pod authenticate in-cluster through its ServiceAccount.

State is not local, and Terrakube is not pretending to be the state backend. The backend is S3-compatible storage served by Rook Ceph RGW inside the cluster:

 1terraform {
 2  backend "s3" {
 3    bucket = "tofu-state"
 4    key    = "augustini-wtf/terraform.tfstate"
 5    region = "us-east-1"
 6
 7    endpoints = {
 8      s3 = "http://rook-ceph-rgw-ceph-objectstore.rook-ceph.svc:80"
 9    }
10
11    use_path_style              = true
12    skip_credentials_validation = true
13    skip_region_validation      = true
14    skip_metadata_api_check     = true
15    skip_requesting_account_id  = true
16  }
17}

That tells you quite a lot about the platform around the app: this is a Kubernetes-native setup, running on Talos, with Terrakube runners inside the cluster and Rook Ceph providing object storage for state. The app workspace does not define Talos itself, Rook itself, Terrakube itself, or the public Gateway. It attaches to those platform primitives.

That separation is healthy. App repo says “run this site.” Platform repos say “here is the cluster, object storage, runner identity, gateway, DNS automation, and so on.”

Variables: small escape hatches, tight defaults#

The OpenTofu variables are boring in the pleasing sense.

The resource base name and namespace default to augustini-wtf. The image repository defaults to registry.augustini.xyz/sites/augustiniwtf. The image tag has a validation rule:

 1variable "image_tag" {
 2  description = "Pinned container image tag."
 3  type        = string
 4  default     = "20260607072706"
 5
 6  validation {
 7    condition     = var.image_tag != "latest"
 8    error_message = "image_tag must be pinned to a concrete tag instead of latest."
 9  }
10}

That single validation block prevents the classic personal-site incident where latest works until the registry, node cache, rollout controller, and your assumptions all form a small committee and vote against you.

The Harbor credentials are sensitive variables. The registry host defaults to registry.augustini.xyz. Replica count defaults to 2, with validation requiring at least one. CPU and memory defaults are intentionally tiny:

1requests = {
2  cpu    = "10m"
3  memory = "32Mi"
4}
5limits = {
6  cpu    = "250m"
7  memory = "128Mi"
8}

This is a static web server. If it needs more than that under normal personal-site traffic, something is either famous or on fire.

Kubernetes: the runtime contract#

The OpenTofu module creates a namespace with common labels:

1"app.kubernetes.io/name"       = var.name
2"app.kubernetes.io/part-of"    = "talos"
3"app.kubernetes.io/managed-by" = "terrakube"

Then it merges in Pod Security Admission labels:

1"pod-security.kubernetes.io/enforce" = "restricted"
2"pod-security.kubernetes.io/audit"   = "restricted"
3"pod-security.kubernetes.io/warn"    = "restricted"

That means the namespace is not merely “please be secure” flavored. It asks Kubernetes to enforce the restricted profile. The pod spec then matches that intent:

 1automount_service_account_token = false
 2
 3security_context {
 4  run_as_non_root = true
 5  run_as_user     = 10001
 6  run_as_group    = 10001
 7  fs_group        = 10001
 8
 9  seccomp_profile {
10    type = "RuntimeDefault"
11  }
12}

The container security context tightens the rest:

1allow_privilege_escalation = false
2read_only_root_filesystem  = true
3run_as_non_root            = true
4
5capabilities {
6  drop = ["ALL"]
7}

This lines up nicely with the scratch image. The image has nothing interesting to mutate, and Kubernetes makes the root filesystem read-only anyway. The pod gets no service account token by default. Linux capabilities are gone. Privilege escalation is off. Seccomp uses the runtime default.

It is a very small box with a very small job.

The Deployment exposes one named container port:

1port {
2  name           = "http"
3  container_port = 8080
4  protocol       = "TCP"
5}

Readiness and liveness probes both hit / through that named port. The Service maps port 80 to target port http, giving the Gateway a stable backend target without making the container pretend it is allowed to bind privileged ports.

Registry auth: dockerconfigjson as infrastructure#

Because the image lives in private Harbor, the module creates a kubernetes.io/dockerconfigjson secret:

 1data = {
 2  ".dockerconfigjson" = jsonencode({
 3    auths = {
 4      (var.harbor_url) = {
 5        username = var.harbor_username
 6        password = var.harbor_password
 7        auth     = base64encode("${var.harbor_username}:${var.harbor_password}")
 8      }
 9    }
10  })
11}

Then the Deployment references it via image_pull_secrets.

This is a good example of infrastructure code being allowed to be unglamorous. The cluster needs credentials to pull the image. Terrakube owns the sensitive inputs. OpenTofu renders the exact Kubernetes secret. The pod uses it. Nobody needs to click around in a registry UI and hope the namespace has the right secret forever.

Gateway API: routing as an app-owned resource#

The app does not define a load balancer. It attaches routes to an existing Gateway named main-gateway in the default namespace.

For the apex hostname, the route attaches to section https-wtf-apex and sends / to the Service:

 1hostnames = [var.hostname]
 2
 3parentRefs = [
 4  {
 5    group       = "gateway.networking.k8s.io"
 6    kind        = "Gateway"
 7    name        = var.gateway_name
 8    namespace   = var.gateway_namespace
 9    sectionName = var.gateway_https_section
10  }
11]

The route also sets HSTS:

 1filters = [
 2  {
 3    type = "ResponseHeaderModifier"
 4    responseHeaderModifier = {
 5      set = [
 6        {
 7          name  = "Strict-Transport-Security"
 8          value = "max-age=63072000; includeSubDomains; preload"
 9        }
10      ]
11    }
12  }
13]

There is a separate www route attached to https-wtf that returns a 301 redirect to the apex host. There is also an optional HTTP route, enabled by default, that attaches to the Gateway’s http section and redirects both augustini.wtf and www.augustini.wtf to HTTPS on the apex hostname.

This is where Gateway API feels cleaner than the old Ingress pile. The platform owns the Gateway and listeners. The app owns its hostnames, redirects, headers, and backend references. The contract between them is explicit: route attaches to named listener section, listener accepts it, traffic moves.

ExternalDNS is controlled through route annotations. If publishing is enabled, the route gets:

1"external-dns.alpha.kubernetes.io/include" = "true"

If disabled, it gets a controller annotation pointing at an ignore value. That gives the app workspace a switch for “publish records from these routes” without making DNS a manual side quest.

The Talos part, and what this repo does not own#

The OpenTofu labels say part-of = talos, and the path says the same thing: this app belongs to a Talos-based cluster estate. Talos matters here less because of any one line in the app module and more because of the operational model it implies.

Talos is not a general-purpose Linux host that also happens to run Kubernetes. It is an immutable Kubernetes appliance OS. No SSH as the normal management interface. No “just apt install htop on the node.” No artisanal node drift. Cluster operations go through APIs and declared configuration.

That philosophy matches the site deployment:

• The app container is scratch.
• The pod has a read-only root filesystem.
• The namespace enforces restricted Pod Security.
• The deployment is driven by OpenTofu from Terrakube.
• State lives in object storage, not on a laptop.
• Routes attach to a pre-existing platform Gateway.

The website is tiny, but the operational shape is the same one you want for larger services: artifacts are built once, deployed by tag, reconciled by controllers, and exposed through platform-owned ingress.

What actually changes when I publish a post#

When this post gets merged and pushed, the pipeline does not mutate the cluster directly. It creates a new immutable-ish artifact and moves one pointer.

The only deployment variable Woodpecker changes is image_tag. That variable goes from one timestamp to another. Terrakube runs the plan and apply. Kubernetes sees the Deployment pod template image change from:

1registry.augustini.xyz/sites/augustiniwtf:20260607072706

to something like:

1registry.augustini.xyz/sites/augustiniwtf:20260607123456

That pod template change triggers a rollout. New pods pull the new image using the Harbor secret. Readiness probes pass. The Service selector keeps pointing at the same labels. The Gateway route keeps pointing at the same Service. Traffic gradually finds the new pods.

There is no “deploy content” step. The content is inside the image. That makes rollback boring too: set image_tag back to an older timestamp, apply, and let Kubernetes roll back to pods serving that older public/ tree.

Why this is funny and why it is not#

Yes, this is a lot of machinery for personal fieldnotes with a heart icon in the header.

But the machinery is not there because the website needs compute. It is there because I want the deployment path to teach the right habits:

• Build static output deterministically.
• Package the runtime as a small container.
• Push to a registry.
• Deploy pinned tags.
• Keep infrastructure state remote.
• Let CI request deployment, not impersonate the cluster admin.
• Run with fewer privileges than the app could ever need.
• Put routing, redirects, and headers in declarative resources.

The actual app is almost aggressively simple: HTML, CSS, a tiny amount of JavaScript, and a Rust static file server. The platform around it is the part that makes the simplicity durable.

That is the nice thing about static sites. You can make the runtime so small that all the interesting engineering moves to the edges: how assets are built, how images are tagged, who is allowed to apply infrastructure, where state lives, how traffic enters, and what the pod is forbidden from doing.

The result is a terminal princess website that deploys like a grown-up service and runs like a locked filing cabinet with a web server taped to it. It is pastel. It is strict. It contains almost no moving parts. It sparks joy, and then immediately drops all Linux capabilities.