Original, source-backed articles about running small systems, static sites, HTTP, DNS, TLS, and operations.
Posts are original articles written for this site. Each one is script-free, source-backed, and tied to the same operational reality the rest of the site records: how a small, static, publicly served system is built, secured, and kept honest.
Startup probes delay other probes until initialization succeeds
A startup probe gives a container a separate initialization contract. While that configured probe has not succeeded, Kubernetes does not execute the container’s liveness or readiness probes. This is stronger and more specific than ignoring some liveness failures during a grace period: those other checks have not begun. Once startup succeeds, ordinary ongoing health and readiness behavior takes over.
...
A Kubernetes Secret is an API object for confidential values that workloads need. It gives operators a dedicated object type, consumption paths, and access-control targets. It does not make data unreadable to every other actor. Design the boundary around who can retrieve the object, create consumers, inspect their output, and administer the nodes that run them.
...
ConfigMaps separate configuration from the image
A ConfigMap stores non-confidential configuration separately from an image. That lets a release change an environment-specific value without rebuilding the application artifact. The useful boundary is explicit: the image supplies code, while the workload definition identifies which configuration that code should consume. A release is therefore more than an image tag; its configuration reference is part of the behavior being deployed.
...
Kubernetes Deployments describe desired state
You describe the end state, not the steps. That idea underlies replicas, updates, and rollback: the cluster keeps working to match your description.
Spec beats imperative steps A Deployment is a statement of the end state, not a list of steps: how many replicas, which image, what update strategy, which labels. The operator publishes the what, and the controller, a reconcile loop, is responsible for the how. The distinction is resource ownership, not whether a shell command was used. kubectl run normally creates a standalone Pod; its kubelet can restart containers, but no ReplicaSet maintains a replacement population after that Pod disappears. A Deployment can itself be created with a command, yet its stored specification continues guiding controllers after the client exits. Interrupting the client does not reliably indicate whether the API accepted the request: inspect the stored object before retrying or diagnosing convergence.
...
A Compose project combines declarations with external inputs
Docker Compose turns service declarations into containers, networks, and storage attachments managed as a project. The file describes useful relationships: which image runs a service, how configuration reaches it, and which storage or network it uses. Reproducing a stack still depends on external inputs such as image availability, variable values, host capabilities, and existing data. A versioned file makes those inputs reviewable only when they are identified.
...
Copy dependency inputs before application code
Dockerfile order determines which earlier inputs an expensive build operation depends on. If application source is copied before dependency installation, changing that source can make the installation run again even when the dependency declaration is unchanged. Copying the dependency inputs first, installing them, and copying application code afterward creates a smaller dependency boundary that matches the work the installer actually needs.
...
Deleting a file in a later image layer does not erase its bytes
Container image layers describe filesystem changes applied in order. A layer can add or replace a file, or record that an earlier path should disappear from the merged filesystem. That final view is what a normal container process sees, but it is not the complete history of bytes distributed with the image. Inspecting only the running container can therefore miss data retained in earlier layers.
...
Reproducible builds connect source to artifacts
A reproducible build lets another party recreate specified artifacts byte for byte from the stated source, build instructions, and relevant environment. The promise must name its outputs: matching object files is insufficient when the shipped executable differs. Reproduction provides evidence connecting source and distribution, while source review, provenance, and signatures address other questions. Two identical malicious builds are still malicious, and a compromised toolchain can reproduce its own unwanted behavior.
...
