[grade=A] overlay2 specifics, softened absolutes, metadata synced (urn:ump:esbkgfocmnincgxckipkxkevboer5vkhcsui2b5qihbcms772ftq)

src/content/blog/manifest.ts

@@ -18,7 +18,7 @@ export const POSTS: PostMeta[] = [
     slug: "why-shipdeck-replaced-docker",
     title: "Why ShipDeck Replaced Docker: One Binary, No Disk Bloat",
     description:
-      "Docker was eating disk space for no reason, so we built ShipDeck — a single Go binary that replaces Docker, Docker Compose, and handwritten deploy scripts. No daemon, no layered filesystems, no bloat.",
+      "Docker was eating disk space with overlay filesystems and build caches, so we built ShipDeck — a single Go binary that replaces Docker, Docker Compose, and handwritten deploy scripts. No daemon, no layered filesystems, no bloat.",
     date: "2026-10-08",
     author: "DashCaddy Team",
     tags: ["shipdeck", "docker alternative", "deployment tool", "fleet deployer", "systemd deployment", "self-hosted deployment"],

src/content/blog/why-shipdeck-replaced-docker.md

@@ -1,15 +1,15 @@
 ---
 title: "Why ShipDeck Replaced Docker: One Binary, No Disk Bloat"
-description: "Docker was eating disk space for no reason, so we built ShipDeck — a single Go binary that replaces Docker, Docker Compose, and handwritten deploy scripts with one command. No daemon, no layered filesystems, no bloat."
+description: "Docker was eating disk space with overlay filesystems and build caches, so we built ShipDeck — a single Go binary that replaces Docker, Docker Compose, and handwritten deploy scripts with one command. No daemon, no layered filesystems, no bloat."
 date: "2026-10-08"
 author: "DashCaddy Team"
 tags: ["shipdeck", "docker alternative", "deployment tool", "fleet deployer", "systemd deployment", "self-hosted deployment"]
 readingMinutes: 7
 ---
 
-We created ShipDeck to replace Docker because Docker was eating disk space for no reason.
+We created ShipDeck to replace Docker because Docker was eating disk space — gigabytes of it, sitting in overlay filesystems and build caches long after the build was done.
 
-Layered filesystems, image caches, build artifacts that never get cleaned up — a handful of Go services under Docker can quietly consume gigabytes. Multiply that across a fleet of hosts and the waste adds up fast. Our services compile to single binaries under 20 MB each. Wrapping them in a container that pulls a base image, layers a build, and leaves dangling images behind was burning storage we actually needed.
+Every `docker build` for a Go service stacks copy-on-write layers: base image → package installs → source copy → compile. In our fleet, a service whose binary was a few megabytes routinely left behind hundreds of megabytes of overlay data, BuildKit cache, and stale images. Multiply that across a handful of services on each host and the waste added up fast. Our services compile to single binaries. Wrapping them in a container that layers an entire filesystem on top of them was burning storage we actually needed.
 
 ShipDeck is a single Go binary. It takes a source repo and a TOML config file, then runs the full pipeline: build → package → SSH transfer → systemd install → Caddy reverse proxy → DNS record → live verification — one command, and the prior release is preserved so rollback is one command away after the first successful deploy. No daemon. No registry. No layered filesystems. Just the binary you built, running under systemd.
 
@@ -32,7 +32,7 @@ Docker is excellent at running isolated processes. It solves the "works on my ma
 
 But for your own software, which you already build from source, the container is dead weight. Here's why we replaced it.
 
-**Docker eats disk space.** A single Go service under Docker: base image (~100 MB), build layers (~200 MB), cached intermediates, dangling images from previous builds. The actual binary is 15 MB. Multiply across a half-dozen services on each host, and Docker was burning gigabytes storing nothing. ShipDeck lands the binary directly — one file, no layers, no cache to prune.
+**Docker eats disk space.** A single Go service under Docker: base image, build layers, cached intermediates — all accumulating in `/var/lib/docker/overlay2`. The actual binary is a few megabytes. In our fleet we saw that overhead routinely reach hundreds of megabytes per service. Multiply across a half-dozen services on each host, add BuildKit cache and stale images, and the gigabytes pile up fast. ShipDeck lands the binary directly — one file, no layers, no overlay, no cache to prune.
 
 **The Docker daemon is another moving part.** Every Docker deploy requires the daemon to be running, healthy, and configured the same way on every host. It consumes memory even when idle. A systemd unit needs only systemd — which is already running on every Linux host.