Golden Images How I Stopped Manually Logging Into Every New Server

The problem

Every time I spun up a new server for a service, it worked but it wasn't actually ready. There was always one manual step left: log in, run through some interactive setup, get the application into a working state. Only after that could the server actually do its job.

For one server, that's a minor annoyance. For a fleet that's supposed to scale up and down on demand, it's a dealbreaker. You can't call something "automated provisioning" if a human still has to remote in and click through a setup wizard before it's usable.

The fix: capture the setup once, replay it everywhere

The pattern here is usually called a golden image and the idea is simple: instead of repeating a manual setup step on every new machine, do it once, capture the result of that setup, and have every future machine apply that captured state automatically during provisioning.

Concretely, I built a small tool that:

1. Connects to a machine that's already been through the manual setup and is in a known-good state.
2. Packages up just the state that setup actually produced not the whole machine, just the specific files/config that resulted from the manual steps.
3. Uploads that package to storage, versioned.

Then the provisioning script for every new machine downloads that package and applies it automatically as part of boot no human, no remote session, no wizard.

The mistake worth mentioning

My first version of this captured too much. Instead of packaging just the setup-derived state, it grabbed an entire application data folder which included the application's own installed binaries, not just the configuration that setup had produced.

That meant every new machine, when it applied the "golden" package, got its fresh application install silently overwritten with whatever binary version happened to be running on the machine I captured from. New servers ended up running an older version of the software than the one they'd just installed a regression that was confusing to trace, because nothing had "changed" from the provisioning script's point of view.

The fix was narrowing the capture to exactly the two or three subfolders that actually held setup-derived state, and leaving the application's own installation untouched. Smaller package, and it stopped fighting the install step instead of complementing it.

Why this is worth doing before you scale

The manual-setup step is easy to live with when you have one or two servers it's a one-time cost. It stops being easy to live with the moment you want:

• Autoscaling a new instance needs to be usable within seconds of being created, with zero human involvement.
• Disaster recovery if a machine dies, replacing it shouldn't require someone to remember and redo a manual setup checklist from memory.
• Consistency every machine that skips the manual step (or where someone does it slightly differently) is a machine that behaves subtly differently from the rest of the fleet.

A golden image turns "someone has to set this machine up" into "every machine sets itself up, identically, using the same captured state." It's the same principle as infrastructure-as-code, applied to the data a machine needs rather than just its configuration.

The general lesson

If any part of your provisioning process still requires a human to log in and do something interactive even something that "only takes two minutes" that's the step blocking real automation. Capture what that manual step actually produces, package just that, and make applying it part of the automated boot process.

And when you build the capture step: be precise about what you're capturing. It's tempting to grab "the whole folder" for simplicity, but bundling setup-derived state together with things that shouldn't be frozen (like application binaries) turns your automation tool into a tool that silently reintroduces old versions. Capture the smallest thing that actually represents "the setup happened," and nothing more.