The real reason automated setup exists is not saving twenty minutes once — it is building the tenth server exactly like the first. This page shows the fleet method: one recipe, tiny per-machine differences, and a rollout order that keeps mistakes cheap.
Ask any technician who maintains hand-built servers about their fleet and you will hear the same story: every machine is a snowflake. Different update levels, different forgotten settings, different surprises during every repair. A recipe-driven fleet ends that. Every server is built from the same answers, so a fix learned on one machine applies to all, and a replacement server is an afternoon of unattended installing instead of a week of archaeology.
Divide every setting into two piles before you build anything. The identical pile is the recipe’s job; the changing pile is a small table you maintain by hand.
Never roll a recipe to ten machines untested. Build the first server, run the full verification checklist from the core guide, give it its role, and use it for real work for at least a few days. Every flaw you find now costs one edit to the recipe. The same flaw found after ten builds costs ten repairs.
When the test server reveals a problem, resist fixing just that server. Correct the answer file so the next build is right, then apply the same fix to the test machine by hand once, noting that you did. This discipline is the entire difference between a fleet and a pile of similar machines.
Build two or three more, verify them the same way, and only then finish the fleet. Keep the per-machine table updated as you go — hostname, address, role, build date, recipe version. That table, plus the recipe, is a complete map of your server estate on one page.
Six months later, when a server dies or a branch office opens, the fleet method turns a crisis into a routine: new hardware, same recipe, one line added to the table. New team members can build a correct server on their first day. And when something misbehaves, you can ask the most powerful question in system administration: is it different from the others, and if so, where?
The video builds one server automatically. This page is how that same twenty minutes of work becomes the standard for every server you will ever add.
▶️ Watch Full VideoNo. The recipe approach works across different hardware as long as the answers do not hard-code one machine’s specifics, like an exact disk device name that differs between models. Keep hardware-specific values in the per-machine table, not in the shared recipe.
Give it a recipe variant — a copy of the master with its differences, clearly named. Two or three named variants (web, file, branch) stay manageable. Ten unnamed one-off edits do not.
Three things: the recipe itself under version control, the per-machine table, and a one-line build note per machine (date, recipe version, anything unusual). With those, any competent technician can rebuild or repair any server you own.