Bare Metal Software

If you run your own servers, the book now makes one container the default. Each server program ships as a single container on a plain host with a container runtime, and a second container needs a technical reason, such as a PostgreSQL server or a managed service like Amazon RDS. Litestream now runs inside that container as the process that starts your program, so backups come with it. The program handles its own TLS certificates and enforces its own rate limits, size limits and timeouts, which removes the separate Caddy container everywhere it appeared. Kubernetes is never assumed. The change runs through the Premise, Chapters 1 through 11, the tables, and the container figure that now compares four stateful designs.

The book now opens every storage decision with one question: what is the simplest reliable way to store this state? The State Complexity Ladder climbs from plain files to SQLite, to a local PostgreSQL, to a managed database such as Neon or Turso, and tells you to climb a rung only when a requirement forces you to. It comes with a new figure, two new tables, a deployment acceptance test you can run against your own system, and five new exercises with AI prompts that walk you through choosing a rung. If a team of one or two has to run production software for years, this is the part to read first.

AI can write more code, and that changes which layers of software you still need. Software stacks grew tall because human developers needed abstractions, frameworks and managed services to make hard work practical. Bare Metal Software starts with a simple rule: use the protocol directly when the protocol is simpler than the abstraction around it. It then asks whether one engineer or a tiny team can maintain production software through durable specifications and an agentic coding harness. The goal is Software Sovereignty, which does not mean zero dependencies. It means fewer accidental obligations, portable data, replaceable services, and systems that keep working when outside dependencies change. You learn to decide when HTML, HTTP, SQL, SMTP, FHIR or a native platform capability beats the library that wraps it, when mature libraries and security primitives are the simpler choice, and how to move a brownfield system toward sovereignty one protocol boundary at a time. It is for engineers and technical leaders who will own software for years.