A project got its own domain, and the engine got path-preserving aliases
What a rename on the open web actually is
Renaming a project that lives on the public internet is not a branding exercise. It is a migration between URLs that other people's systems already hold. Newsletters have embedded the old links. Social previews have cached the old metadata. Search engines have indexed the old pages. Large language models have crawled the old sitemap and will keep citing the old URLs for weeks.
A rename is successful only if all of those external references keep working on the day of the change and converge on the new URLs over time, without anyone doing anything. Any other outcome is reputation cost — broken links in someone else's article, stale previews on LinkedIn, LLM answers pointing to a dead address. The goal is invisibility: nobody on the outside should notice the move except by finding the new name.
Why this one mattered
Until today, every project in the farm lived under kda.zone as a subdomain. A subdomain is cheap — the wildcard certificate covers it, DNS is already set up, Cloudflare already knows about it. But a subdomain also permanently marks the project as belonging to someone else's house. For a project still finding its audience, that framing is fine. For a project that has begun attracting its own readers and shifting from research into practice, it starts to read like a beta stamp.
The Agency project crossed that line. The new brand is Unseizable, on its own apex: unseizable.fyi. Same content, same author, same URL structure below the domain — a different front door, and a signal that the project is its own thing now, not a wing of the personal site.
The three blocks of a domain migration
Seen at the right altitude, every rename of a live project touches three independent layers. Each one has to move, and they have to move in a defined order, but none of them needs to know much about the others.
The registrar holds the ownership record for the new domain. Its only job in the migration is to point the domain at the right DNS provider. Once that's done, the registrar is out of the loop for the rest of the project's life.
The edge layer — in this case Cloudflare — owns DNS, terminates TLS for visitors, and forwards traffic to the origin. It's where the public internet meets the project. Adding a new domain here is a new zone: a new certificate, a new set of routing rules, a new set of defaults. The defaults are the only thing in the migration that can quietly break everything.
The engine is the single Bun/Hono process that serves every domain in the farm from one codebase, routing by Host header. Its job in the migration is to (a) start serving the new domain's content and (b) translate every request for the old domain into a permanent redirect to the equivalent URL on the new one. "Equivalent" is load-bearing — it has to preserve the path and the query string, so that a deep link like agency.kda.zone/log/2026-04-02?s=… lands on unseizable.fyi/log/2026-04-02?s=…, not on a generic homepage.
What the engine actually gained
Before today, the engine had two lifecycle statuses for ending a project's domain: sunset (redirect everything to an archive URL) and retired (domain released, kept in history). Neither fits a rename, because a rename is not an ending. The project is still active, the content is unchanged, and the destination for each old URL is not a single archive page but a one-to-one mapping to the new domain.
The engine now supports a third status: alias. Declaring a domain as an alias of another domain is a small, self-describing entry in the single configuration file that already drives everything else. The engine reads it at startup and, for every request arriving at the old domain, answers with a permanent redirect to the same path and query on the new one. No content is built for an alias. No separate service runs. The old entry stays in the configuration forever as part of the project's history — you can always see that agency.kda.zone was the previous home of Unseizable.
The mechanism is documented as a decision record so the vocabulary is clear: active, sunset, retired, alias — four distinct meanings, four distinct behaviours, no overloading.
The trap that cost an hour
The launch was clean in code and blocked at the edge. Every request to the new domain returned "web server is down" for an hour, despite the origin being visibly healthy and serving every other site in the farm. The cause was a Cloudflare default. New zones start in a stricter TLS mode than the rest of the farm uses, which prevented the edge from ever reaching the origin. Two clicks in the Cloudflare dashboard fixed it — but only after an hour of looking for the problem in the wrong place.
That is the kind of cost that should be paid exactly once. It is now the first step of the written checklist.
How the next rename will work
The whole workflow lives in a single checklist inside the repo — a rebrand-domain skill — that a future operator (human or AI agent) can follow end to end in about ten minutes of real work:
- Registrar: point the new domain's nameservers at Cloudflare.
- Edge: add the new domain as a zone, change the TLS mode to match the rest of the farm (this is the step that cost the hour last time), add the DNS record that points traffic at the origin.
- Engine: add the new domain as active in the configuration, demote the old domain to
alias, update the couple of places that name the project in prose, commit, deploy. - Verify: the new domain returns content, the old domain returns permanent redirects that preserve every path.
The large, distracting cleanups — renaming the content directory on disk, regenerating social images, migrating newsletter sub-publications — are deliberately not part of the rename commit. They happen separately, after the migration has proven itself. A rename should be a verifiable, reversible step, not a bundled refactor.
What this buys
Owning your own domain is the entry ticket to owning your audience. You can change platforms, newsletter providers, analytics tools, even hosting, without ever changing the URL that strangers remember. The engine's new alias mechanism extends that property one level further: you can change the domain itself without losing the history of links that people and machines have already saved. The cost of moving off someone else's roof, reduced to one small engine feature and a Cloudflare setting nobody warned me about.