Bastian's personal site — thoughts on tech and the internet. 2026-04-04T00:00:00Z https://bastian.nu/ Bastian 2026-03-13T00:00:00Z https://bastian.nu/posts/hello-world/ <p>Welcome to my little corner of the internet. 👋</p> <p>This site is built with <a href="https://www.11ty.dev/">11ty</a> and styled with <a href="https://jdan.github.io/98.css/">98.css</a> to give it that classic Windows 98 charm. I've always had a soft spot for the era when the web felt handmade and personal — Geocities pages, blinking text, and all.</p> <h2>Why a personal site?</h2> <p>Because owning your own slice of the web still matters. Social media platforms come and go, but a simple static site? That can stick around for decades.</p> <h2>What you'll find here</h2> <ul> <li><strong>Blog posts</strong> — thoughts on tech, software, and whatever I'm currently obsessing over</li> <li><strong>Projects</strong> — things I've built or am building</li> <li><strong>Bookmarks</strong> — links worth sharing</li> </ul> <p>More soon. Thanks for stopping by!</p> 2026-03-13T00:00:00Z https://bastian.nu/posts/new-site/ <p>The old site had been sitting untouched for a while. Every time I looked at it, I felt that specific kind of guilt that comes from something you built years ago that no longer represents who you are or what you care about. So I blew it up and started over.</p> <h2>What Was Wrong With the Old Site</h2> <p>Nothing was technically <em>broken</em>, which is almost the problem. It just felt stale — a relic of a different era of my thinking about the web. The design was generic, the content was sparse, and the whole thing ran on a stack that I'd grown out of. Maintaining it felt like homework.</p> <p>More practically: it wasn't mine in any meaningful sense. It used a theme someone else made, lived on a platform someone else controlled, and looked like a thousand other developer portfolios. I could have been anyone.</p> <h2>What I Wanted Instead</h2> <p>I wanted something that felt personal and a little weird. The web used to be full of pages like that — handmade, opinionated, idiosyncratic. Somewhere along the way, everyone's site started looking the same.</p> <p>That's where the Windows 98 aesthetic came from. It's not just nostalgia (though it is a little nostalgic). It's a statement: this place is mine, I built it, and it looks exactly how I wanted it to look. If that's not your taste, that's fine — but you'll remember it.</p> <h2>The New Stack</h2> <p>The new site is built with <a href="https://www.11ty.dev/">11ty</a>, which is about as simple as a static site generator gets. No magic, no framework overhead, no build tooling I don't understand. Markdown goes in, HTML comes out.</p> <p>Styled with <a href="https://jdan.github.io/98.css/">98.css</a> for the Windows 98 look, with some custom CSS on top for layout. The whole thing runs as a static site behind nginx in a Docker container — dead simple to deploy, dead simple to update.</p> <h2>Why It Matters</h2> <p>Honestly, the best reason to have your own site is that it's yours. Social platforms come and go. Algorithms bury things. Account bans happen. A static site you control doesn't have any of those problems.</p> <p>And there's something about the act of building it yourself — really building it, not dragging blocks around in a CMS — that makes you more invested in actually writing things. This post exists partly because I want to see if that's true.</p> <p>We'll find out.</p> 2026-03-14T00:00:00Z https://bastian.nu/posts/ai-tarpit/ <p>AI companies have been sending crawlers to scrape every website they can find, feeding the content into training datasets whether site owners want it or not. The polite ones respect <code>robots.txt</code>. Most don't.</p> <p>So I set a trap.</p> <h2>What's a tarpit?</h2> <p>A tarpit is a honeypot that doesn't block bots — it wastes their time instead. Rather than returning a 403 and letting the crawler move on in milliseconds, a tarpit serves an endless stream of content as slowly as possible, tying up the bot's connection for as long as it'll sit there.</p> <p>This site is running <a href="https://zadzmo.org/code/nepenthes/">Nepenthes</a>, an AI-specific tarpit. Any request to <code>/blog/</code> that looks like a scraper gets handed off to it. Nepenthes responds with a page full of randomly generated nonsense — Markov chain babble trained on public domain books — plus a maze of links pointing to more fake pages. The content is delivered at a trickle, 4–25 seconds per response, so the crawler spends real CPU time and bandwidth receiving text that is completely worthless.</p> <h2>How it works here</h2> <p>Nginx proxies <code>/blog/</code> to Nepenthes running in a Docker container. The fake pages are seeded from a corpus of Project Gutenberg texts (Pride and Prejudice, Frankenstein, Sherlock Holmes) blended together into convincing-looking gibberish. Every page links to several others, creating a maze the crawler can wander indefinitely.</p> <p>The delay is the real weapon. If a crawler holds 10 connections open and each response takes 20 seconds, that's 200 seconds of crawler resources spent on nothing. At scale, across many sites running tarpits, this raises the cost of indiscriminate scraping meaningfully.</p> <h2>What it catches</h2> <p>From the first few hours of running:</p> <ul> <li>Bots hitting <code>/blog/</code> receive the tarpit, not this site's actual content</li> <li>Each connection is held open for up to 25 seconds</li> <li>The generated text goes straight into the void — or, if they're not careful, into a training dataset full of Victorian novel slurry</li> </ul> <p>The real posts (like this one) live at <code>/blog/posts/</code> and are served normally. The tarpit is what you get if you wander in without reading.</p> <h2>Monitoring</h2> <p>I hooked up Prometheus and Grafana to track it — hits, unique IPs, bytes wasted, total delay inflicted. Watching the numbers tick up is genuinely satisfying.</p> <p>If you're running your own site and are fed up with your content being scraped without consent, Nepenthes is worth a look. The setup is a single Docker container and a few lines of nginx config.</p> 2026-04-04T00:00:00Z https://bastian.nu/posts/coolify-migration/ <p>My personal server has been running a handful of services for a while — this site, a home automation app, a Minecraft server, a monitoring stack. They all lived in Docker containers, managed by hand. It worked fine, but deploying anything meant SSHing in, pulling the latest image, restarting things, and hoping nothing broke. Tedious enough that I kept putting off small updates.</p> <p>I recently moved everything over to <a href="https://coolify.io/">Coolify</a>, a self-hosted platform that handles deployments for you. You hook it up to a GitHub repo, and from then on a git push is all it takes to deploy. It also sorts out HTTPS automatically, which used to be its own annoying thing to manage.</p> <p>The migration was not as smooth as I'd hoped. Here's what happened.</p> <h2>What it actually is</h2> <p>Coolify is a web dashboard that manages your server's services. Point it at a GitHub repo, tell it what to run, fill in any secrets or environment variables, and it does the rest — builds the image, starts the containers, sets up a domain with SSL. When you push new code, it redeploys.</p> <p>I've been running four things through it: this site, HOUSE(planning app for tasks around the house), a Minecraft server, and a monitoring stack that keeps an eye on everything else.</p> <h2>You can use it too</h2> <p>Since deploying new things is now pretty painless, there's capacity on the server that isn't being used. If you have a side project, a small app, a bot — something that needs somewhere to live — I can add it. Your code stays in your GitHub repo, secrets stay in the dashboard rather than in the repo, and updates are a git push. Let me know.</p> <h2>What broke during migration</h2> <p>Two things didn't survive the move, and they were basically the same mistake twice.</p> <p>The monitoring stack came up with no data. Config files I'd been pointing to by relative path weren't there when the containers started — Coolify only puts the compose file in the deployment folder, not the whole repo. So anything your app needs at runtime either has to be baked into the Docker image at build time, or placed on the server manually before the first deploy. Neither of those is obvious until you've been bitten by it.</p> <p>The HOUSE app had a similar problem — it expected a folder on the server to already exist. It didn't, so the container started, couldn't find its data, and failed without saying much useful. Once I knew what to look for it was a quick fix, but figuring out what to look for took a while.</p> <h2>The thing that will bite you if you have any stored data</h2> <p>Coolify recreates storage volumes on each deploy. If your app writes anything to a named Docker volume, that data gets wiped when you next deploy. I don't know why it works this way, but it does.</p> <p>The workaround is to point your mounts at specific paths on the host machine instead — Coolify doesn't touch those. Everything on this server that stores anything important uses that approach now. But I wish I'd known before the first deploy rather than after.</p> <h2>A couple of Traefik things</h2> <p>Coolify uses Traefik under the hood for routing and SSL. It mostly handles itself, but two things caught me out.</p> <p>There's a manual step to connect Traefik to the network your services run on, and if Traefik ever gets recreated it loses that connection and routing breaks. Easy to fix, annoying to diagnose at midnight.</p> <p>HTTP-to-HTTPS redirect also doesn't happen automatically — there's an extra config file that needs to exist in a specific place. Without it, HTTP requests just hang rather than redirecting. Coolify doesn't tell you this anywhere obvious.</p> <h2>Overall</h2> <p>The rough edges during migration were frustrating but they were all one-time problems. Now that everything's running, deployments are boring in the best way — push, wait thirty seconds, done. I should have done this earlier.</p>