Work / Terry: Home AI Lab / Guide
Build a home AI lab from a retired computer
A step-by-step guide, with the prompts to give your AI assistant. Last updated:
Part of Terry: Home AI Lab.
Scroll the guide and the layer for that step lifts. Click a layer to jump to its step.
You need an old computer, a USB stick, access to your router, a terminal, and an AI assistant. Prompts below are templates. Swap the [brackets] for your details, and never paste passwords, tokens or private keys into any of them.
Ground rule for every prompt: make the AI go one step at a time and explain before you run. Add this to the end of any prompt: “Give me one step, tell me what it will change, and wait for me to confirm before the next.”
Step 1 of 7 · The machine
Step 1: Pick the machine and give it one job
Check what you have before you wipe anything: model, year, RAM, disk size, and whether its operating system is end-of-life.
Prompt 1 of 11
I have a [model, year, RAM, disk]. It is stuck on [OS version]. Can it run Ubuntu Server LTS? What will likely break (Wi-Fi, fans, boot)? List three realistic jobs for it. Ask me questions before you answer.
Check: you can finish the sentence “this machine exists to ___”.
Step 2 of 7 · The OS
Step 2: Install Ubuntu Server, headless
The full walk-through is in Field Note 01, in Self-Hosting & Homelab Field Notes (on Substack). Short version: flash the ISO, boot holding Option, install OpenSSH, skip the extras, then expand the disk.
Prompt 2 of 11
Walk me through installing Ubuntu Server LTS on a [model] from a [my computer, e.g. Apple Silicon Mac]. Flag anything specific to this hardware, including the boot key, the Wi-Fi driver, and whether I should use Ethernet. If I'm flashing from a different CPU type than the target, tell me which downloads need to match which.
Check: the machine boots with no monitor attached, and df -h / shows the whole disk.
Step 3 of 7 · The network
Step 3: Make it reachable and keep it private
A DHCP reservation in your router so the address never moves. An SSH key instead of a password. A one-word alias. A private network like Tailscale if you want to reach it away from home.
Prompt 3 of 11
Explain, in plain terms, a DHCP reservation, an SSH key pair, and an `~/.ssh/config` alias. Then give me the exact commands to set up passwordless SSH from [my computer] to [server name]. After that, explain what Tailscale adds and what it exposes to the internet (I want the answer to be nothing).
Check: ssh server works from a fresh terminal with no password prompt.
Step 4 of 7 · The services
Step 4: Deploy one service with Docker Compose
Pick something small that publishes a docker-compose.yml. Do not run it yet. Have the AI read it first.
Prompt 4 of 11
Here is the docker-compose.yml for [project]. Don't run anything. Tell me which ports it binds, which volumes hold data I'd lose if the disk died, which environment variables are secrets, and every place it says `localhost` that must change to my server's address.
Prompt 5 of 11
Now give me the minimum commands to start it, check it answers over HTTP, and stop it cleanly.
Check: a plain HTTP request to the port returns a normal status before you call it done.
Step 5 of 7 · The ports
Step 5: Keep a port list and a secrets rule
The cheapest habit in the whole setup. A running note of what is bound where, so no new service ever guesses a port. Tokens live in your OS keychain and are read at call time, never saved in a file or typed into a command.
Prompt 6 of 11
Here are the services on my server and their ports: [list]. Build me a one-page table, then write a short pre-deploy check that picks a free port, refuses to reuse one, and tells me when it's done.
Prompt 7 of 11
I need to store an API token on my Mac and read it from a script without writing it to disk. Show me how with the macOS keychain, and show me the safe way to reference it in a command.
Step 6 of 7 · The runbook
Step 6: Turn what you just did into a runbook
This is the step that made Terry repeatable. Right after the first deploy, while the details are fresh, hand the AI your terminal history and ask for the process back.
Prompt 8 of 11
Here is my terminal history from deploying [service]. Turn it into a numbered runbook with these sections: prerequisites, steps, how to verify each step worked, and known mistakes. Mark every point where I made a judgment call, so I can decide whether it belongs in the rules.
Then do a second deploy of a different kind. A web app first, then a command-line tool or a desktop app. Whatever breaks, add it to the runbook that day.
Prompt 9 of 11
This step failed with [error text]. Explain why in one paragraph, give me the fix, and write the one-line entry I should add to my runbook's "known mistakes" so I never debug it again.
Check: a second person, or a second AI session with no memory of yours, could follow the runbook and get the same result.
Step 7 of 7 · The backups
Step 7: Set up backups before you need them
Write the restore steps first. A backup you have never restored is a hope.
Prompt 10 of 11
Review this backup script: [paste]. What is it copying that it shouldn't? What happens when the disk is 90% full? How would I find out it failed? Then write me the restore steps as if I'm doing them at 2 a.m. on a clean machine.
Prompt 11 of 11
Suggest a retention plan for a small home server: how many dated copies to keep, how to prune safely only after a new copy verifies, and how to get a second copy onto a different physical machine.
Check: you restored one file from a backup into a scratch folder, and it opened.
Questions worth asking your AI at every stage
- What is this going to change on my machine? Don’t run it yet.
- What would break if I did this twice?
- What am I storing in more than one place?
- How will I know this failed tomorrow, without checking?
- What did I just do that I’ll forget by next month? Write it down for me.
- Which of these steps involves a secret, and where should it live instead?
If you use an agent that can run commands
Start it read-only. Let it look, list and report before it is allowed to change anything. Give it a map of your machines with one canonical name each, so “the server” never means two things. Keep host config and secrets outside any code repository it can write to.
Known mistakes
This list grows. Each entry cost me real time once.
| What happened | Fix |
|---|---|
Pushing a shallow clone (--depth 1) to my git server fails with shallow update not allowed. | Run git fetch --unshallow, then push again. |
| A nightly backup copied a 100 GB media folder that was already stored twice elsewhere. The disk hit 71 percent. | Decide what each backup is for, exclude what is not data you made, and refuse to run under a free-space floor. |
| A backup warning sat unnoticed because nothing told me. | Show the last backup status as a banner when you log in over SSH. |
Where to next
- The story behind this guide: Field Note 02, in Self-Hosting & Homelab Field Notes (on Substack)
- The project, with its roadmap: Terry: Home AI Lab