These posts are preserved from the original site. Some commands and products are historical; read them as an archive, not current instructions.
Why a two-person infrastructure team moved roughly 150 users from self-hosted mail and collaboration to Microsoft 365, and what remains after the MX cutover.
At work, we use several systems that contain the information people need to answer everyday engineering questions: documentation, source control, wikis, and databases. The problem is not that the information is missing. The problem is that it is spread across different interfaces, APIs, and permission models. I have been building Model Context Protocol servers to […]
It is easy to describe a home lab by listing its containers. That is the visible part: dashboards, media services, databases, and utilities. The harder part is the network underneath them. Services depend on names resolving, routes existing, certificates renewing, storage being available, and access remaining possible when something else is broken. The container is […]
A home lab starts as a few machines and quickly becomes a collection of exceptions: one service lives in Docker, another in a virtual machine, a third only works because of a change made two years ago. My answer has been to treat the whole estate as infrastructure. Not because every home server needs to […]
A CI pipeline is often treated as a build script with a web interface. I find it more useful to treat it as executable documentation for how a change becomes a release. The order tells a story Linting, unit tests, integration checks, packaging, promotion, and deployment should appear in an order that reflects the project’s […]
Fiber changed the ceiling on my internet connection, but it did not make the network simpler. Once local services, remote access, automation, and multiple clients share the same link, the interesting problems are still local: names, routes, failure modes, and boundaries. Bandwidth is not topology A fast uplink does not tell a client where a […]
Documentation becomes part of the system as soon as people depend on it to deploy, troubleshoot, or recover a service. At that point, a page hidden behind a browser-only workflow is a weak integration point. The documentation needs an interface that tools can use too. Structure beats a wall of text Books, chapters, pages, categories, […]
I use Debian in one environment and Arch in another. The useful lesson is not that one distribution wins. It is that a workflow should survive a distribution boundary without depending on muscle memory or an undocumented package name. Keep the intent stable The intent is usually straightforward: install a tool, run a test, inspect […]
Configuration management makes a system easier to reproduce, but it is not automatically a safe place to put every value the system needs. Public state, environment-specific settings, and secrets have different lifecycles and should be handled accordingly. Describe the shape openly A Salt state can describe that a service needs a configuration file, a user, […]
The best deployment is usually the one nobody talks about afterward. It built the intended artifact, applied the intended configuration, passed its checks, and left enough evidence to explain what happened. Separate the three questions A deployment pipeline often becomes confusing because it tries to answer several questions at once: Did the source produce a […]