How I set up a new machine (and the nine days I did not plan for)
# How I set up a new machine (and the nine days I did not plan for)
Four hours and ten minutes from a blank Windows install to a finished video coming out of my pipeline. Nine days to find everything I had forgotten.
Same project, two numbers. The first is the share of my working life that exists in writing. The second is the share that lived only as sediment on a machine I no longer had.
I run one Windows workstation and four Linux boxes at home on a private overlay network. Every server can be rebuilt from a file, and I have brought one back from a dead disk in under two hours that way. The workstation had no such file. In six years it never occurred to me to write one, because the servers felt operational and the workstation felt personal.
That distinction does not exist, and it cost me nine days.
The order, and why the popular one is wrong
Most people rebuild browser first, because a browser and a chat client feel like being back at work inside ten minutes. You are then reading email on a machine that cannot do your job.
The order I use is shell, credentials, runtimes, things that sync. Everything after those four can be installed around you while you are already working.
Shell first, because every remaining step is typed at a prompt. The terminal, the profile that configures it, the ssh key, the ssh config, and the PATH. Most of the mystery errors on day one are a tool that installed perfectly into a directory nothing is searching.
The file people lose is the ssh config, not the key. Everybody protects the key. The config holds the host aliases, the ports and the per host identities. It makes four servers answer to short names instead of addresses you look up each time, it sits beside the key, and almost nobody backs it up. Mine had accreted by hand over five years, had never been committed anywhere, and took an evening of guessing at ports.
The credential store is the piece people improvise
Second is the vault, because almost nothing downstream works without it. A private repository needs a token. A server needs a key with a passphrase. Every api my automation touches needs a secret, and none of those secrets live in the repository, for reasons I spent a whole video on.
Three steps. Client, one interactive authentication, then the unattended unlock so scheduled jobs can read secrets at three in the morning with nobody in the room. The third gets skipped, and a week later every scheduled job is failing quietly because it cannot unlock anything without a human typing a password. I can describe that precisely because I caused it twice.
Windows adds a second version of it, where a scheduled task runs as a different account from the one you are sitting in and finds an empty store.
I did not come out of this clean. Two api keys were sitting in a plain text environment file on the old machine, keys I had meant to move into the vault for a year. I found them because they did not survive the move and something broke. Discovering a key by watching a job fail is the worst available route to it, and that exception existed on exactly one machine: the one I thought of as mine.
Runtimes, and the version you never wrote down
Third are the languages and tools. Python, a couple of command line media tools, the graphics drivers, and whatever the render pipeline links against.
Versions get pinned and recorded. The same automation on two Python versions is two automations, and you learn which one you have when a script that behaved for a year raises something you have never seen. Virtual environments live in one fixed directory outside every repository, a rule I reached the dull way, by keeping them inside project folders until a backup job started syncing gigabytes of packages nightly.
The media tools carry a quieter trap. They ship with build flags, so two installs of the same version number can behave differently, and the failure arrives weeks later as an unsupported format on a file type you rarely touch. Local models sit in this step too, and the first one is a fifteen minute job now.
The scripts that exist nowhere
Small local scripts. Aliases. The four line thing you wrote at midnight eight months ago that renames files a particular way, and the function that connects you to whichever server is complaining, by name.
None of it is in a repository. It is in a shell profile, or a directory called tools on one disk, or in your hands as a command you type without remembering that you wrote it.
I counted afterwards. Thirty one aliases and shell functions. Nine mattered enough that I rebuilt them. Four had been written down anywhere I could find.
One of the nine was load bearing in a way I had forgotten completely. A wrapper that set three environment variables before calling a render script. Without it the script ran, finished, reported success, and produced files at the wrong bitrate. Two videos shipped that way before I noticed.
This is where you find out your workflow was never portable. It was a machine with habits worn into it, and you had been calling that a workflow.
What the nine days actually held
Scheduled jobs, about a dozen, whose only inventory was the scheduler on the old machine. I rebuilt the list from a screenshot I happened to have taken months earlier for an unrelated reason, which is luck, not a system.
Browser state, which ate more hours than any technical step. Sessions, two factor apps paired to specific devices, extensions carrying local configuration that exists nowhere else.
Hard coded paths. Every place a script named an exact folder on an exact drive instead of asking where things live. I knew they existed. I did not know there were forty.
My media library sits on separate drives, with links pointing at them from the paths the code expects. Get the letters wrong and everything runs, reports success, and writes into a directory nobody opens. A day of renders, no crash, no alert.
The more interesting column is what I decided not to reinstall. A screen recorder I was paying a subscription for. A note taking app I had not opened since the previous year, and a database client I used once. Nothing depended on any of them. A migration is the only honest audit of unused tooling I have ever run, because on a working machine an unused tool costs nothing you can see.
Install from a list
Install from a list, top to bottom. Not from memory, and not by scrolling the old machine's applications folder working out what each thing was for. On the servers that list is a script. On the workstation it is a plain text file, one package manager command per line, with a comment naming what depends on it. Having it in any form is most of the value.
The list lives in the same repository as the code that needs it. Not a notes app, not a document in cloud storage. The repository, because that is the first thing you clone on a new machine, and a list you have to remember to find is a list you will not find. I keep my automation configs under version control for the same reason, and have written about that separately.
The last rule needs real discipline. When you install something new, it goes on the list that day. The system fails on the thing you installed in a hurry eight months ago and never recorded, and that thing is reliably the one that turns out to be load bearing.
If it takes a week, you do not have a workflow
You have a machine.
I mean that about myself first. A workflow is a sequence of steps that can be moved somewhere else and still run. When they only execute in one place because of accumulated state you cannot enumerate, what you own is a single point of failure with good habits wrapped around it.
The test is short and unpleasant. How long from a machine arriving this morning to you earning money on it. If the honest answer is a week, the machine has been doing work you thought you were doing.
The backup that would not have got me back to work
I had a backup running the entire time. Encrypted, offsite, nightly, and I had restored files out of it to check.
What I had never tested was restoring an environment out of it. The backup covered my documents and my code. It missed the shell profile, the ssh config, the scheduler, and the application data directories where much of a Windows machine's configuration lives. So I owned a backup that would have survived a fire and would not have had me working by Monday. Those are two different products, and I had been paying for one while believing I had the other.
A rehearsal for the day it dies
You will do this again. Possibly by choice, on an upgrade. Possibly at eleven at night, when a disk stops answering and somebody is waiting on you. Those two versions have identical steps. The second has none of the time.
So a voluntary migration is a drill for the involuntary one. I time it, and I write down every point where I had to stop and think, because that is a point where a list was missing.
I wrote the install list to make the next migration faster. What it produced was an inventory: the only complete description of what my business runs on, every dependency in one file, in the order it has to arrive. Before that I had a rough idea, and a rough idea is exactly what turns four hours into nine days.
Get new guides and videos first — join the Telegram channel.