<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Infrastructure on David R. Longnecker - Converting Coffee to Code</title><link>https://drlongnecker.com/tags/infrastructure/</link><description>Recent content in Infrastructure on David R. Longnecker - Converting Coffee to Code</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 25 May 2026 09:00:00 -0600</lastBuildDate><atom:link href="https://drlongnecker.com/tags/infrastructure/index.xml" rel="self" type="application/rss+xml"/><item><title>The Container That Isn't a Container</title><link>https://drlongnecker.com/blog/2026/05/proxmox-lxc-containers-micro-vm-mental-model/</link><pubDate>Mon, 25 May 2026 09:00:00 -0600</pubDate><guid>https://drlongnecker.com/blog/2026/05/proxmox-lxc-containers-micro-vm-mental-model/</guid><description>&lt;p&gt;Running a growing homelab means making infrastructure decisions you&amp;rsquo;ll live with for years. As I have been rebuilding my lab over the past few months, Docker was the obvious first choice: container images are easy to stand up, networking ports and dependencies are declared in a compose file, and the ecosystem is enormous. For a handful of services, that model worked cleanly.&lt;/p&gt;
&lt;p&gt;As the service count grows, the operational friction accumulates. Backups require protecting data volumes and compose configurations as separate concerns, with different tools for each. Updating a service means a pull-and-redeploy cycle rather than a package update. Migrating a container between hosts runs into subtle differences in network backends, volume paths, and runtime configurations that rarely surface until something actually needs to move.&lt;/p&gt;</description></item></channel></rss>