Digital Minimalism as a Config File

Willpower is a bad place to keep your boundaries

I’ve installed most of the popular app blockers at one point or another. The breathing-pause apps, the unlock-delay apps, the ones that make you wait five seconds and confirm you really meant it. They all worked for about two weeks. Then the friction faded into a reflex, my thumb learned the rhythm of tapping through the delay, and I was back where I started, now with an app congratulating me for “intentional usage” while I doom-scrolled exactly as before. The problem wasn’t the apps. It was that they put the decision in the same place it always failed: my willpower, in the worst possible moment to be relying on it.

What this solves

• Explains why app-layer blockers degrade into a tap-through reflex.
• Moves your attention boundaries from willpower into infrastructure.
• Shows how DNS blocking plus a cron schedule enforce rules you set once.

Subtraction plus rules, enforced by infrastructure

The version of digital minimalism that actually held for me wasn’t a feeling or a streak. It was subtraction paired with rules, and then the rules moved out of my head and into infrastructure that enforces them whether or not I’m feeling strong. That’s the whole shift. A rule you have to re-decide every day isn’t a rule, it’s a daily negotiation, and you will eventually lose a negotiation with yourself at 11pm.

Infrastructure doesn’t negotiate. A config file doesn’t care that you’re tired, bored, or telling yourself “just five minutes.” It applies the same boundary it applied yesterday, with no prompt for you to tap through. A DNS rule holds because the decision already happened, days ago, in a calm moment, and there’s no button in the scroll to undo it. You’re not stronger. You’ve just stopped storing the boundary somewhere it can be overridden by a mood.

DNS-level blocking can’t be bargained with mid-scroll

Here’s the piece that did the heavy lifting: blocking at the DNS layer instead of the app layer. I run Pi-hole on the spare-laptop home server I set up, and a domain that doesn’t resolve simply doesn’t load. There’s no five-second delay to wait out, no “ignore limit” button, no friction to adapt to. The site just isn’t there. To a compulsive thumb mid-scroll, that’s a wall, not a speed bump.

The difference matters more than it sounds. App-layer tools sit between you and the thing, which means there’s always a path through, and your brain learns that path fast. DNS-layer blocking removes the thing from the network’s vocabulary entirely. The request goes out, gets answered with nothing, and the impulse has nowhere to land. You can absolutely still defeat it, I know exactly how, but defeating it requires logging into a server and editing a list, which is a deliberate, calm-state action. That’s the trick. The bypass exists, but it lives outside the moment of weakness, so the moment of weakness can’t reach it. The decision and the temptation no longer share a screen.

Time-windowed blocking, enforced by cron

The blunt version, block a domain forever, is too crude for real life, because some of those sites I genuinely want sometimes. So the better setup is time-windowed: distracting domains only resolve outside the hours I care about protecting. A cron job flips the rules on a schedule. During work hours and late at night, the distractions don’t resolve. In a defined evening window, they do.

This is the part that feels like magic the first time it runs. I’m not choosing to block anything at 10am, that decision was made once, encoded in a schedule, and now it just happens. The machine handles the discipline so I don’t have to spend any. It’s the same principle as a thermostat: you don’t re-decide the temperature every hour, you set the rule and let the system hold it. My attention boundaries became a literal config file plus a cron entry, and the entire category of “should I check it right now” quietly disappeared, because the honest answer outside the window is “it won’t load anyway.”

App blocker vs DNS sink vs network schedule

It’s worth being honest about the trade-offs, because none of these is free.

An app blocker is the easiest to set up and the easiest to defeat, since it lives on the same device as the impulse and offers a button to override it. It’s a fine starting point and a poor finish line. It works until your thumb memorizes the workaround, which it will.

A DNS sink like Pi-hole is harder to stand up, it wants a Raspberry Pi or a spare machine and a willingness to edit lists, but the payoff is a boundary that doesn’t negotiate at the moment of temptation. The cost is that it’s network-wide and a little blunt, and it only protects you while you’re on that network. The time-windowed schedule on top is the most setup of all and the most calming to live with, because it removes the decision entirely instead of just making it harder. Roughly: app blockers buy you a pause, a DNS sink buys you a wall, and a schedule buys you the thing I actually wanted all along, which is to stop deciding.

The calm of rules you set once and stop re-litigating

What surprised me most wasn’t the reduced screen time. It was the quiet. Once the rules lived in infrastructure, I stopped having the same tiny argument with myself a dozen times a day. The pull was still there sometimes, but the answer was already settled by a config file, so there was nothing to litigate. That recovered a kind of mental quiet I hadn’t realized the daily negotiation was costing me.

That’s the real case for treating minimalism as infrastructure rather than discipline. Willpower is a renewable but expensive resource, and spending it to re-make the same decision every day is a waste of a scarce thing. A config file spends none. You make the call once, in a calm state, encode it, and then you get to forget about it, which was the entire point. This is the same logic as moving friction onto the compulsions and off the real work, just enforced at the network layer instead of by hand. Set the rule once. Let the machine be the one that doesn’t budge.