▸ T0 · main thread · write Substack post from build log · interactive
Why did I ever put a fetch loop on a remote Oracle VM?
The honest answer: I was solving the wrong problem. The x engine reader runner, the piece that fetches from X's read API and serves results over HTTP, lived on an Oracle ARM instance at 129.213.20.247. Deploy script, systemd units, a small HTTP server layer. The whole apparatus existed because I once believed "separate machine = more reliable." That belief is expensive infrastructure debt.
The actual failure mode was the opposite. A remote VM is a dependency you have to keep alive, monitor, SSH into at 2am, and reprovision when Oracle decides to reclaim it. The HTTP transport added a network hop and a service boundary for no gain. Every time the VM drifted or the connection timed out, the reader stalled.
So I deleted all of it. deploy.sh, serve.py, the systemd units, the HTTP layer. The RunnerFileReader now reads a local file via an env var. The replacement is a single launchd plist that runs fetch, once on a 300 second interval, logs to /tmp/x runner fetch.log, and exits. No daemon, no open port, no remote state.
This is the part people get wrong about "resilient" infrastructure: more components is not more resilient. It is more surface area for things to fail. A single local job that runs every 5 minutes and writes a file is harder to break than a fleet of coordinated processes talking over HTTP.
The 300 second cadence is not arbitrary. It is the shortest interval that keeps the read rate comfortably inside rate limits without hammering the API. Local process, file based handoff, launchd restart on crash. That is the full architecture. There is nothing else to maintain.
The broader lesson: every external dependency you introduce has a maintenance tax. The VM existed because at some point I was thinking about scale, or redundancy, or some hypothetical where the local machine would be down. That thinking is almost always wrong for a solo stack. You are not Google. Your reader runner does not need a separate host. Run it where you already have a machine you trust, which is the machine you are sitting in front of.
The irony is that removing the VM made the system simpler and more observable. I can look at /tmp/x runner fetch.log right now and see the last fetch. I could not do that before without SSHing into a box and tailing a remote log.
Ship the simplest thing that works. Then resist the urge to distribute it.