Docker

I used to keep prod secrets in encrypted files checked into git. This meant every deploy required decryption, every env had its own schema, and one careless moment leaked everything. The cognitive load was constant. I moved to the pattern where only env var names live in version control. I commit a .env.example that lists what keys must exist, nothing more. All actual values come from the runtime environment. For local dev I use direnv to load from a .env file that git ignores. For production, Vercel handles injection directly in the UI. Running direnv allow in a project directory loads the .env automatically whenever you cd into it. The.env.example file stays lean: API_KEY=, DATABASE_URL=, AUTH_SECRET=. If someone forks the repo, they see the shape of what they need without seeing actual values. A leaked .env.example is just a checklist. This breaks down in teams that refuse to use direnv or need secrets in CI/CD systems that don't integrate cleanly. If your pipeline expects files instead of environment variables, you end up bolting on an extra layer anyway. But for anything touching Docker or serverless platforms, this approach removes a whole category of mistakes.

Before I adopted multi-stage builds, my Go service images were bloated. I'd compile everything inside the container, and then ship the entire build layer to production. The image sat around 800 megabytes because it contained the Go toolchain, git, and every build dependency. That meant every deployment pulled that extra weight, and every running container exposed toolchain binaries that had no business being in production. I restructured my Dockerfile to build in one stage and copy only the final binary into a fresh stage. The first stage does all the compilation work with all the heavy dependencies available. Then I use a `FROM scratch` or `FROM alpine:latest` for the final stage, and I `COPY --from=builder /app/service /service`. The resulting image drops to about 30 megabytes for a typical CLI tool or microservice. Here's the concrete shift: my build stage runs `RUN go build -o /app/service .` with the full Go installation present, but the runtime stage starts from scratch and only contains that single statically-compiled binary. No source code, no build cache, no compiler. The attack surface shrinks because there is literally nothing left to exploit except the binary itself. The caveat is that this approach works cleanly for statically-compiled binaries, which Go excels at, but falls apart if you need runtime dependencies or configuration files. If your service needs shared libraries or certificate bundles, you have to explicitly copy those into the final stage too, which adds back some size and complexity. It is not a universal solution for all container workflows. ```docker FROM golang:1.25-alpine AS builder WORKDIR /src COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 go build -o /bin/api ./cmd/api FROM alpine:3.24 RUN apk add --no-cache ca-certificates COPY --from=builder /bin/api /bin/api ENTRYPOINT ["/bin/api"] ```