CaRMen's public demo lives at /demo/ on the project's landing site. The landing site is its own nginx server block on the host; the demo is a separate application in Docker, listening on a local port.
My search engine's crawler backed off from hosts that kept failing: each consecutive failure doubled the wait before the next attempt, up to a cap of one day. During one long working session in July, one test of that logic failed in every run, and it kept being written off as a "pre-existing, unrelated" failure.
CaRMen's deploys run from GitHub Actions: once the tests pass on the main branch, a job builds and publishes the Docker images, and a deploy job connects to the server over SSH and tells it to switch to the new version. Within a day of setting that up, the deploy job started failing some of the time with SSH errors, while the images it was meant to deploy had been published just fine.
In early July the admin statistics page of my search engine started reporting zero: zero pages crawled in the last hour, zero in the last 24 hours, on a pipeline that was visibly busy. At the same time, re-crawls were being scheduled two hours early. Both had the same cause, and none of the data was wrong. The database and the application disagreed about what time it was.
The PHP language server setup in my Emacs used to be a single setting that offered Eglot a list of servers, phpactor and Intelephense, to choose from. In October, I replaced it with a small function and a settings function.
Tightening a file's permissions is supposed to be the safe direction. In July, on my search engine's frontend server, setting the application's .env file to mode 0600 instead did two things at once: it broke every newly started PHP process, and it left the admin area answering without a password for a few minutes. A smoke test after the deploy caught it.
In October, CaRMen, my CRM, got an endpoint for something other than a logged-in person: a website contact form that should be able to create a lead without anyone logging in. That needs an API key, and an API key is a password that's meant to be pasted into other systems.
This build's wifi documentation got rewritten once the desktop environment grew a GUI network applet — not because the original instructions were wrong, but because a second, complete way to do the same thing now existed alongside the first, and the two actively fight each other if both run at once.
In July, while debugging a data export script for my search engine, I ran ps aux on the server as part of the diagnosis. The output contained the application's MySQL password, in plain text, because the script passed it on the command line.
A method's own comment already explained exactly what its SQL needed to do, and why. The actual SQL did the opposite of what the comment described.