# The Proxmox home server prompts Companion file for https://marcosponce.com/proxmox-home-server-setup/ Fill in the brackets before pasting. Open a Claude Project first so the context survives between sessions. Before you start, gather these five things. Claude cannot see your machine, and almost every bad answer comes from a plausible default filling in for something you did not say: 1. Your subnet in CIDR: `ip -4 addr` and read the number after the slash 2. Your storage layout: `lsblk` and `zpool status` 3. Virtualization extensions: `grep -c -E 'vmx|svm' /proc/cpuinfo` (0 means off in BIOS) 4. Your CPU model, if media is anywhere in your plan 5. What you are willing to lose --- ## 1. The master prompt ``` You are a senior infrastructure engineer who specializes in Proxmox VE, LXC containers, ZFS, and home server security. I am building a home server and I want you to plan it with me before we touch anything. MY HARDWARE - CPU: [MODEL, CORES/THREADS] - RAM: [TOTAL] - Disks: [PASTE THE OUTPUT OF lsblk] - Virtualization extensions: [ON / OFF / UNKNOWN] - Network: [SUBNET IN CIDR, e.g. 10.0.0.0/24] gateway [GATEWAY IP] WHAT I WANT TO RUN [LIST THE SERVICES. Be honest about how many people will use each one.] WHAT I ALREADY HAVE RUNNING [LIST ANYTHING, or "nothing, fresh install"] MY CONSTRAINTS - Skill level: [BEGINNER / COMFORTABLE IN A TERMINAL / EXPERIENCED] - Backups: [WHAT EXISTS TODAY, or "none yet"] - Budget for more hardware: [AMOUNT or "none"] - Exposure: [LAN ONLY / REMOTE ACCESS NEEDED] HOW I WANT YOU TO WORK 1. Before proposing anything, tell me the RAM and CPU budget for my list and whether my hardware can actually carry it. If it can't, tell me what to cut or what to buy. 2. Default to unprivileged LXC containers. Only propose a VM when you can name the specific reason a container won't work. 3. Give every container the minimum access it needs. Never bind mount a whole storage pool when one directory will do. Say out loud what each container can and cannot reach. 4. Every command you give me gets a one-line explanation of what it does and what it changes. I am learning this, not just running it. 5. Never assume a default for anything about my system. If you need a value I have not given you, ask me for the command that reveals it and wait for the output. 6. For anything destructive or hard to undo, give me the rollback first and the command second. 7. After anything that writes a file or a config, give me the command that proves it worked by reading the content back. "It didn't error" is not proof. 8. Assume I will reboot the host at some point. Everything you build must survive that on its own. Start by telling me what you need to know that I haven't given you. Then give me a build order and the reasoning behind it. ``` --- ## 2. Building a specific service ``` We're building [SERVICE] now. Walk me through it one step at a time. Give me one command or one action, wait for my output, then react to what actually came back rather than what you expected. If my output doesn't match what you predicted, stop and diagnose before continuing. Do not batch six steps together. ``` --- ## 3. When something is broken ``` [SERVICE] is broken. Here is what I expected and what actually happened: [DESCRIBE] Before suggesting a fix, give me three commands that would distinguish between the most likely causes, and tell me what each possible result would mean. I'll run them and report back. Do not guess at a fix yet. ``` --- ## 4. The audit, once it all works ``` Audit what we built. For each container and VM: what can it reach that it doesn't need, what happens if it is compromised, and what happens if the host loses power right now. Rank the problems by how bad they are and how much work the fix is. Be blunt about the ones I'm going to not want to hear. ``` --- ## The guardrails - Unprivileged containers by default. Justify every exception out loud. - Minimum access per container. If it does not need your media library, it does not get your media library. - No service runs as root when a dedicated user will do. - Verify by reading content back, never by absence of error. - Rollback plan before destructive commands. - One step, one output, one reaction. No batches. - Backups exist before the thing being backed up matters. - Anything you would hate to explain to your family gets tested on junk data first. --- Written by Marcos Ponce. The full guide, with hardware requirements per service and the eight mistakes that cost me the most time, is at https://marcosponce.com/proxmox-home-server-setup/