Articles in this category. Show all categories
Commands that version every module of a stack on its own, build its image under a tag that means exactly one build, refuse to reuse a version or swallow a failed compile, and archive images by name and tag so versions never overwrite each other.
Two commands that keep three environments apart on one machine and one web server: one sets an environment's addresses and aligns every file that stores them, rendering nginx from templates and refusing on clashes; the other points the browser at one environment.
Three commands that take a tested release into production without overwriting what production owns: they promote configuration structure but keep its secrets and addresses, refuse to copy new secrets, and apply schema migrations the images carry.
Three commands that build a full copy of production for one release — configuration from the repository, images from the registry, data from the latest backup — restore it in order, run the release's migrations against that data, and remove it without a trace.
The procedure that gives a new project its whole infrastructure from generators, in the order the stacks depend on each other: log first, then storage and broker, then the gateway, then the application — with the public steps kept manual.
Templates come from real stacks, and copies quietly carry their data, keys, open databases and root-owned paths. My database, object storage and application generators leave the old data, keys and access behind, and read each application's facts from the application itself.
Every new project needs a gateway, sign-in, and a first administrator before its backend exists. One generator command now builds that stack, working on first boot, by handling the values that fail silently when set by hand and a rerun that would keep the old database.
Release Workflow: Development to Production is the procedure every change of mine follows from my laptop to production — which steps I automated, which I deliberately left to a person, why each step sits where it does, how I diagnose a failed release, and how I recover from it.
A 4 GB laptop GPU once sent every heavy job to a borrowed Colab runtime. Deciding per piece of work instead — by a measured number, by reliability, by a change of method — split one project across three places and deleted 9975 lines of machinery on the way home.
A borrowed Colab GPU ends every session by time limit or daily quota, often in the middle of hours of image generation. Picking up where it stopped meant treating each new runtime as a machine that knows nothing — and may not even be the same machine as yesterday's.
Get an email when a new article is published.