Self-Hosted
A Fully Local AI Assistant in One docker agent YAML
Point Docker Agent at a local OpenAI-compatible server, declare a few toolsets, and you have a private assistant that reads files, runs shell commands and calls your own scripts — no cloud API key required
docker agent is Docker’s agent runtime (the CLI plugin built on the open-source cagent project — you’ll
see that name in ~/.config/cagent). Its whole contract is a single YAML file: one block describing agents,
one describing models. Nothing stops you from pointing the model block at localhost, which is the
interesting part — the same declarative agent, tools and all, running against a model on your own machine.
opencode.json: Wiring a Terminal Coding Agent to a Local Model
One JSON file turns opencode into a fully local assistant — declare an OpenAI-compatible provider, describe your models, and check the resolved config before you trust it
opencode is a terminal coding agent, and it has no opinion about where its tokens
come from. Providers are declared in an opencode.json file, so pointing it at a model running on your own
machine — LM Studio, an MLX server, llama.cpp, vLLM — is a matter of a baseURL and a couple of lines of
metadata. Here’s a config with three providers side by side: a LAN box, a hosted API, and a local server.
Serving a static site securely with static-web-server
Hardening a Hugo site behind Traefik with static-web-server: read-only rootfs, dropped capabilities, a non-root UID, and security headers
A Hugo build is a folder of files. Nothing executes, nothing talks to a database, nothing parses user input. The interesting attack surface isn’t the content — it’s the server you put in front of it, and for years that meant an nginx image carrying a config language, a module system, and a package manager I never used.
This blog now runs on static-web-server instead. Here’s the compose file that serves it, and what each hardening line actually buys.
The Local AI Toolbox: 13 Tools That Run Entirely on Your Machine
A tour of the local-AI tooling I'd actually install in 2026 — runtimes, hardware-fit checkers, on-device speech and TTS, and document parsing, with the licenses and caveats that matter.
The interesting thing about local AI in 2026 isn’t that it’s possible — it’s that the boring parts finally work. A Mac with 16 GB of unified memory, or a PC with an 8 GB GPU, runs a 7B–13B model well enough for transcription, OCR, routine chat and the small repetitive tasks that make up most of the day. No API key, no per-token meter, no outage on someone else’s status page.
What follows is the toolbox: thirteen tools, grouped by what they actually do. I verified each one’s repository, language and license while writing this, because half the “top tools” lists circulating right now cite projects that have been renamed or abandoned. Where something surprised me, I say so.
RunRun: a small web UI for running shell commands on a server
A self-hostable Go web app that schedules, executes and live-streams the output of shell tasks — with auth, CSRF and rate limiting baked in
I have a recurring problem: I want to give someone (sometimes future-me) a button to push that runs a specific shell command on a server. A backup, a deployment dry-run, a cache flush, a database snapshot. Cron isn’t quite right because the trigger isn’t time-based. SSH is fine but assumes the person has SSH and remembers the exact command. A bespoke Flask app is too much yak-shaving.
RunRun is my attempt at the smallest reasonable thing that fills that gap: a Go web app where you declare tasks in YAML, log in, click “run”, and watch the output stream live in your browser.