Keep Your Server Setup Recipe in Git Version Control

Name: Keep Your Server Setup Recipe in Git Version Control
Uploaded: 2026-01-01T08:00:00+00:00
Description: The answer file that built your server is a small file with enormous value. This page shows how technicians protect it: Git version control, a commit for every change, and the one iron rule about secrets that keeps the recipe safe to store.

The answer file that built your server is a small file with enormous value. This page shows how technicians protect it: Git version control, a commit for every change, and the one iron rule about secrets that keeps the recipe safe to store.

✍️ Technical Anshu🐧 Linux Server⏱️ 8 minute read

🎥 The video’s setup answers are worth protecting — this page is the filing system that never loses them

Six months from now you will ask a question like: “why does this server have that setting?” or “what did the recipe look like when we built the branch server?” Memory answers those questions badly. Git answers them exactly, because it keeps every version of the recipe with the date and your note about why it changed. The habit takes ten minutes to start and pays out for the life of the fleet.

Terminal — putting the recipe under version control (example)

$ cd ~/server-recipe $ git init $ git add . $ git commit -m "Recipe v1 - builds office-web" ... later, after an edit ... $ git commit -am "Add docker to starter software" $ git log --oneline (every version, listed)

Three commands start the habit. Your folder and messages will carry your own words — the pattern is what matters.

Step 1 — Create the Repository

Put the recipe files in one folder — the answer file, the per-machine table, your notes — and make that folder a Git repository.

cd ~/server-recipe then git init
git add . stages everything in the folder
git commit -m "Recipe v1 - first working build" records version one forever
If Git asks who you are, set it once with git config --global user.name and user.email

Step 2 — Commit Every Change With a Reason

From now on the rule is simple: no silent edits. Every change to the recipe gets a commit whose message says why, not what — the diff already shows what. “Add Docker to starter software because the apps server needs it” will still make sense in two years. “Update file” will not. Tag the versions you actually build machines from, for example git tag v3-office, so any server can be traced to the exact recipe that made it.

Step 3 — The Iron Rule: No Secrets in the Repository

A recipe usually contains things that must never be copied around: passwords, private keys, tokens. Git remembers everything forever, including things you later delete from the file — they stay in the history.

Store passwords and keys outside the recipe folder, in a password manager or an encrypted file
In the recipe, use placeholders that tell the builder where the real secret lives, never the secret itself
If this repository is ever pushed to an online Git service, this rule is the difference between a backup and a breach

What This Buys You on a Bad Day

Recipe broke a build? git log shows what changed since the last good version, and checking out that version takes a minute. Wondering whether a setting was deliberate? The commit message says why. New technician joining? The repository is the handover document.

🔴 The one unforgivable mistake: committing a real password or private key “and removing it later”. In Git, later removal does not erase history. If it ever happens, treat that secret as leaked: change the password, replace the key, and only then clean up.

🎥 Watch the Full Setup in the Video

Create the repository right after your first successful build from the video — version one deserves to be the known-good one.

▶️ Watch Full Video

❓ Common Questions (FAQ)

Do I need a GitHub account for this?

No. Git works entirely on your own machine or your own server. An online copy at a Git host is a convenient extra backup of the repository, but only after the no-secrets rule is firmly in place.

What files belong in the recipe repository?

The answer file or setup configuration, the per-machine table, build notes, and any small helper files the setup uses. Not the server’s data, not backups of the disk, and never credentials or private keys.

I edited the recipe and broke it. How do I get the old one back?

Run git log --oneline to see the versions, then git checkout the last good commit’s files — or simply view the old version of the file with git show. Nothing committed is ever really lost, which is the whole point.

This guide is based on the Technical Anshu video linked above • Stuck on a step? Ask in the video comments — answers come there 🙏