03 — Server setup

TL;DR: Choose whether one server will run your applications and store their data, or whether you need separate machines. Check that the hardware fits those jobs, install the operating system, and test access and recovery before putting services into use.

This chapter walks you through installing Ubuntu Server, setting up your administrator account and SSH login, and testing local recovery. You do not need Linux or those accounts set up beforehand. First, choose each server's job and the disks the installer will use.

Decide what each server will do#

You can run applications and store their data on one server, or use a separate application server and storage server. You might eventually need several of either. Start by telling your AI operator which services you want, how many people will use them, how much data you have, and how long you could manage without each service.

One combined server means fewer machines to buy, power, and maintain. Restarting it also interrupts both applications and access to its files. Separate servers let you maintain application hardware while keeping shared files available, but applications then depend on the network connection to storage. Separating the machines does not by itself give you a backup or keep an application running when its server fails.

Ask your AI operator to compare those arrangements against your actual needs. Include memory, processor capacity, drive connections and space for growth, network speed, electricity use, and the noise and heat you can accommodate. Give each machine a name and record its intended job in your private GitHub repository.

You can buy new hardware or reuse equipment you already have. An older desktop may be entirely adequate, but age, power consumption, hardware condition, and compatibility all affect that decision. Have your AI operator assess it before you spend money on upgrades or entrust it with important data. New equipment needs testing too.

Prompt to paste:

Help me decide how many servers I need and what each should do. Review my
planned services, users, data volume, growth, budget, space, and tolerance for
outages. Assess any equipment I already have without assuming I must reuse it.
Compare a combined application/storage server with separate machines. Explain
what each arrangement costs me in hardware, power, maintenance, performance,
and service interruptions. Identify missing facts before recommending one.
Save the agreed layout and the reasons for it in our private GitHub repository.

What you'll set up#

You’ll install the operating system on each server, create your own login and a separate login for your AI operator, and connect from your admin computer. You’ll also set up updates and practice getting back in when the normal connection fails. As you work, save the installation choices and recovery instructions so you can use them again if a server needs rebuilding.

The installation steps here use Ubuntu Server LTS. Ask your AI operator to check the current supported release and compatibility with the hardware you chose. Repeat the applicable steps for each Linux server. If you choose a storage appliance with its own operating system, use its supported installation and recovery procedures; the same questions about updates, access, and recovery still apply.

Step 1 — Plan the operating-system and data disks#

Use a dedicated SSD for Ubuntu Server. Keep the drives that will hold household files and long-lived application data separate. The operating-system disk will use ext4; the data drives will use ZFS, configured in the storage chapter. These are different disks with different jobs.

For a modest setup, a 250–256 GB SSD is a useful starting size for the operating-system disk, not a minimum imposed by Ubuntu. Before buying or erasing anything, ask your AI operator to budget space for the OS, updates, logs, container images, and temporary files. Large container collections, local AI models, or build workloads can need much more; decide where those will live rather than letting them silently fill the OS disk.

Use the installer-required boot partitions and allocate the remaining space on this dedicated SSD to /, formatted as ext4. / is the root filesystem: the main space where Ubuntu installs its files. Do not carve out a small fixed root partition or leave half the SSD unallocated by accident. The AI operator should give you the actual partition sizes for your selected disk and installer before you confirm the layout.

Keep enough free space for updates and the temporary work you expect. Have your AI operator set log limits and capacity alerts as part of setup. The later application plan must explicitly identify where container images, databases, uploads, and large caches will go.

Prompt to paste before starting the installer:

Prepare my Ubuntu Server installation and partition plan for this machine.
Identify the OS disk by model, capacity, and serial number, and list
all data disks to disconnect. Budget OS space for updates, logs, container
images, and expected temporary work. Identify large models, caches, and
persistent application data that need another planned storage location.

For our default dedicated OS SSD, use the required boot partitions and one
ext4 root filesystem using the remaining space. Show the actual sizes in GiB,
mount points, and any proposed swap or encryption arrangement. Do not silently
accept LVM allocation that leaves root smaller than our plan. Explain any
necessary departure before installation. Walk me through the installed
release's storage screen and final erasure summary using this plan.

Connect the storage drives#

For this guide's basic server, connect drives to the motherboard's SATA ports or NVMe slots. Do not use a RAID card, and leave any BIOS-provided RAID disabled. These features combine drives before Linux sees them; the storage software we use needs to manage the individual drives itself.

Do not use USB-attached drives for the server's primary storage. A USB enclosure adds a connection and controller that can disconnect, mishandle drive information, or complicate recovery. An unplugged USB disk can still be useful as a separate backup. The storage chapter explains these choices and how to expand beyond the motherboard's drive connections.

Why ext4 for Ubuntu and ZFS for data#

ZFS can run the operating system too. It offers OS snapshots and checksums, so using it there is a reasonable choice when those benefits justify the setup. This guide chooses ext4 for the OS because it follows Ubuntu Server's ordinary installation and recovery path. With ZFS on the OS disk, the boot process must also load and mount ZFS before Ubuntu can start. That requires a compatible installation and recovery procedure for the selected release. See the separate OpenZFS Ubuntu installation guides.

For your household files and application data, ZFS's checksums, snapshots, and repair from redundant copies are worth using. Keeping those drives separate lets you reinstall Ubuntu without formatting your data. ext4 is not being presented as better than ZFS at protecting that data.

Also decide whether to encrypt the OS disk before installing. Encryption can protect its contents if the machine is stolen, but may require you to unlock it after a restart. Have your AI operator explain the unlock and recovery steps for the setup you choose. Save recovery keys in your password manager and a protected offline copy, outside the server.

Step 2 — Disconnect or protect every data disk before installation#

The installer will erase the disk you select. Before starting, identify that disk by its model and serial number, not just a changing name such as /dev/sdb.

If the machine already contains files or an operating system, look through anything you want to keep before installing over it. Copy it to a separate device, check for copy errors, and open representative files from the copy. Have your AI operator compare the source and destination using counts, sizes, and checksums where appropriate. If this would leave just one copy of important data, make another before erasing the original.

If data drives are already installed, photograph and label their connections. Power down and disconnect them, leaving only the intended operating-system disk connected. Verify it again in the installer's final summary. If you cannot distinguish the disks confidently, stop and resolve that first.

Your AI operator can help identify devices and verify copies. You decide which files may be discarded and physically confirm the installation target. Follow the current Ubuntu installation guide for the screens.

Step 3 — Test the hardware#

Test each machine before storing important data on it, whether it is new, bought secondhand, or repurposed from another job. Ask your AI operator to prepare memory, drive-health, temperature, and sustained-load checks suited to the equipment. Use non-destructive checks for any disk that still contains data.

Investigate memory errors, unexplained resets, overheating, and unreliable disk connections. A clean SMART report helps you assess the drive, but cannot predict every failure. Save the original reports in your setup archive so you can compare later results.

Check whether the motherboard needs a manufacturer-supported firmware update. Do it while the machine is nearby and before applications depend on it. Record changed firmware settings, including what the computer should do when power returns.

Step 4 — Install Ubuntu Server#

Download the installer from Ubuntu and use its image-verification instructions. Ask your AI operator to walk you through verifying the download rather than assuming the file is genuine because it has the right name.

Start the Ubuntu Server installer, use the wired connection, and select only the confirmed operating-system disk. Create your own administrator account when the installer asks for your name, username, and password. Use a unique password and save it in your password manager and protected offline recovery copy. This is the account you will use at the server's keyboard when remote access is unavailable; keep it separate from the AI operator's account. Choose a stable machine name, such as node1, that will still make sense if its applications change. Install the SSH server if you plan to manage it from your admin computer, but skip optional application bundles for now.

Remove the installer after setup and confirm that the machine boots from its SSD. Ask your AI operator to save the installed release, boot settings, disk identity, network address, package sources, and any startup errors in ops/inventory/. Keep sensitive hardware mappings in your private records if you don't want them sent to the AI provider.

Step 5 — Learn how to inspect the host#

You don't need to memorize Linux commands. You do need to recognize what your AI operator has actually checked.

Linux uses systemd to start and supervise many services. “Active” describes what is running now; “enabled” describes startup behavior. Neither alone proves an application works. Logs from before the last restart can help explain a failure, so ask your AI operator to confirm those logs are being saved.

Step 6 — Set up security updates and practice a restart#

Ubuntu Server normally includes unattended-upgrades, the program that installs security updates automatically. Verify it on your server rather than assuming the installer took care of everything. Its settings control both updates and whether they may restart the computer.

Have your AI operator prepare the setup below for your installed Ubuntu release. Run the resulting procedure from your administrator account on the server. It should save the existing settings first and tell you what changed.

Prompt to paste:

Walk me through enabling and verifying automatic Ubuntu security updates.
Inspect the installed release, unattended-upgrades package, APT configuration,
and apt-daily / apt-daily-upgrade timers. Install the package if absent.
Set daily package-list refresh and unattended upgrades (both APT::Periodic
values to "1"). Verify allowed origins include this release's security
updates. Keep Unattended-Upgrade::Automatic-Reboot set to "false".

Prepare one administrator procedure that saves the previous settings, applies
only the needed changes, checks effective configuration, and runs
unattended-upgrade -v --dry-run. Explain its results. Verify the next scheduled
run and inspect actual run logs; a simulation alone is not proof of execution.
Save the configuration and results in our private GitHub repository.

The main settings are in /etc/apt/apt.conf.d/; run logs are in /var/log/unattended-upgrades/. Ask your AI operator to show the last real run and next scheduled run. A successful check may find nothing to install. Separately check how applications from other software sources get updates. Ubuntu's automatic-update guide documents the settings and test command.

Decide when to restart#

Installing an update does not always activate it. Some changes take effect when an application restarts; others need the whole server to restart. Automatic updates can restart individual services even when automatic server reboots are disabled.

While you are building the server, do the first restart when you are beside it and nothing important depends on it. Later, choose a regular maintenance time that fits your household, and have your AI operator report pending reboots and failed updates through your monitoring. If a security issue needs a faster restart, have it explain that explicitly.

Ubuntu can indicate a pending reboot with /var/run/reboot-required. Ask your AI operator to check that indicator, explain the relevant update, and tell you what will be interrupted. Before restarting, finish any active backup or data-copy work and have your local keyboard/display or tested PiKVM connection ready.

Once you are ready, run sudo reboot in your server administrator session. The connection will close. Watch the server restart, log in again, and ask your AI operator to verify the expected software is running and check for startup errors. If it does not return, use the local console or PiKVM to see where startup stopped. Keep the working recovery instructions and any previous configuration needed to recover in your offline copy.

Repeat this for each server. When applications are added, extend the check to opening them and performing a normal user action after restart.

Step 7 — Test human SSH before disabling password login#

From your admin computer, have your AI operator walk you through creating an SSH key in your own account and protecting it with a passphrase. Store the passphrase in your password manager. Then install only the public half in your server account; the private half stays on your admin computer, with a protected recovery copy. The AI operator should provide the commands and explain which computer to run them on. Check the server's host-key fingerprint against the local console so you know you're connecting to the intended machine.

Keep the working connection open. Open a second connection using your key and confirm it succeeds. Only then change SSH to reject password-based remote login and direct root login. Test a new allowed connection and a rejected password login before closing the old one. Your local console password should still work for recovery.

Prompt to paste:

Prepare a lockout-safe SSH setup for my Linux server. Inspect its installed
OpenSSH version and complete effective configuration. Keep my existing
session open and require a second successful key login before disabling
remote passwords, keyboard-interactive authentication, and direct root login.

Use a separate limited account/key for your AI operator. Restrict its allowed
source and forwarding. Don't copy my private key. Check all configuration
includes with sshd -t and inspect sshd -T before reloading. Verify a new
allowed login, denied password/root logins, and local-console recovery.
Save the old configuration and the recovery steps. Don't open a router
port for SSH. Give me one complete NEXT ACTION for anything I must run.

Step 8 — Give your AI operator its own account#

Next, create the login your AI operator will use on this server. Keep it separate from your administrator login so you can control its access and revoke it without losing your own way in.

Ask your AI operator to prepare a single setup procedure for you to run from your administrator account. It should create a standard account, give it a working folder, and install its own public SSH key. Create that key in the AI operator's account on your admin computer; keep the private key there. Do not reuse your personal SSH key.

Tell the AI operator which tasks it needs to perform now, such as checking service status and preparing configuration files. Have it explain the permissions needed for those tasks. A standard account can change its own files, but should not be able to change system settings or read your private files. Test that distinction after creating it.

Restrict this login to connections from your admin computer using the access path you actually configured. Ask the AI operator to check the source address the server sees before setting that restriction; a guessed address could block the login. If future work needs another connection path, add and test it deliberately.

For unattended checks, the key lets the AI operator connect without asking you to type the server account's password each time. That does not make it an administrator. Some tasks will still need a clearly explained administrator action from you; the guide will walk you through those when they arise.

The first admission test#

Have your AI operator check that its normal login and workspace work. Then verify that administrator commands, protected files, raw-disk writes, Docker control, and prohibited SSH forwarding are denied. Have it show how each check works before you run the procedure, using disposable files or permission inspection where an actual write could damage data.

Remove its authorized key briefly and confirm that a new login fails while your own account still works. Put it back after the test. This tells you how to revoke access later without changing your login.

Step 9 — Apply a host firewall without locking out recovery#

The router doesn't necessarily restrict connections between devices inside the house. Add a server firewall that admits only the management connections you need at this stage.

Have your AI operator prepare rules for your admin computer's known address and the direct recovery connection described next. Keep a local console available during the change. Test a permitted connection and a connection that should be denied. Any automatic return to the previous rules should be explained and agreed before running the procedure.

Ubuntu documents its UFW firewall in the server firewall guide. Later, Docker will need separate attention: published container ports may not follow the firewall path you expect. The services chapter tests that from another device.

Step 10 — Build the direct-Ethernet recovery path now#

A direct cable lets your admin computer reach the server when the router, switch, Wi-Fi, or DNS is unavailable. It only works if the adapters, addresses, login, and firewall rule have been set up beforehand.

Hardware to label and reserve#

Keep a tested Ethernet cable and the Mac adapter it needs. Label the server port you will use. A second server network port is convenient; a single-port server can also use a carefully configured secondary address, with its normal cable moved during recovery.

Address plan#

Ask your AI operator to choose two private addresses that don't overlap your home network or VPN. Write them on the recovery card: one for your admin computer, one for the server. This cable connection should have no default gateway or DNS server; its job is only to connect those two devices.

Server configuration#

Have your AI operator generate the configuration for the actual network hardware. It should preserve ordinary networking, add the recovery address, and allow SSH only from the intended admin computer recovery address. The settings differ between a dedicated port and a secondary address on an existing port.

Prompt to paste:

Prepare a direct-Ethernet recovery connection between my admin computer (a Mac mini) and this Linux server.
Inspect both interfaces, existing subnets, VPN routes, and firewall rules.
Choose non-overlapping private addresses. Preserve normal LAN networking;
use no gateway, DNS, or default route on the rescue connection.

Match the server NIC by its verified identity. If using a second NIC, allow
SSH only from your admin computer's rescue address on that NIC. With one NIC, match both
the Mac source and the server's secondary destination address. Explain the
cable/adapter arrangement and Mac settings to me.

For Netplan, validate the complete candidate with netplan generate. Explain
and obtain agreement for any netplan try timeout/reversion before applying.
Keep an independent login available and verify the actual addresses and
routes after either confirmation or timeout. Test normal access, rescue
access after reboot, and a source that should be denied. Save a recovery card.

Mac configuration#

Your AI operator should give you the Ethernet adapter's settings for your macOS version: manual address and mask, with router and DNS left blank. Name the connection something recognizable, such as “Homelab Rescue.” Don't change Wi-Fi's settings to configure the cable.

Test the direct connection#

While the server is still empty, disconnect its normal network cable and turn off your admin computer's Wi-Fi for the test. Connect the labeled recovery cable and sign in to the server at its recovery address. Reboot the server and reconnect the same way.

Restore normal cabling and Wi-Fi afterward. Ask your AI operator to confirm that the recovery connection hasn't taken over your admin computer's normal internet route. Write down any adapter or cable step you had to look up.

Optional: reach the server's screen with PiKVM#

If the server will not boot or SSH stops working, a direct Ethernet cable may not help. You need to see what is on its screen and use its keyboard. At home, you can connect a monitor and keyboard. For access from elsewhere, consider PiKVM, a small device that provides those controls through a browser. KVM stands for keyboard, video, and mouse.

PiKVM connects to the server's video output and a USB port. You can watch startup messages, enter the firmware settings, or work through an operating-system installation without Linux or SSH already running. Optional wiring to a compatible motherboard also lets you operate its power and reset buttons. Check your server's connections and the chosen PiKVM model before buying; power control is a separate connection, not something HDMI and USB provide. The PiKVM setup guide shows the connections.

Count your admin computer as well as every server when planning console access. With a Mac mini and one server, choose either a PiKVM for each computer or one PiKVM connected to a compatible KVM switch. With more than two computers total, use one PiKVM with a switch rather than buying a separate PiKVM for every machine.

A switched setup lets you choose which computer's screen and keyboard you are using. Label each port with the machine's name. The official PiKVM Switch supports one active video/keyboard connection at a time, so separate units are useful if you need simultaneous consoles. Choose compatible hardware: the official switch supports the V4 Plus, but not the V4 Mini. See the PiKVM Switch guide for supported models and cabling.

Connect the Mac mini's video output and USB for console access too. Do not assume the optional PC motherboard power/reset wiring applies to the Mac; document and test its power-on and encrypted-startup recovery separately.

Power PiKVM and any KVM switch independently of the computers they control, and include them and their network connection in the UPS plan. For access away from home, use the private VPN described in the next chapter; PiKVM can run Tailscale itself, so access need not pass through a failed server or admin computer. It still needs working power and networking. Change its default credentials, keep them in your password manager, and keep console and power control out of your AI operator's routine account.

Test every connected computer while you are beside it: select its labeled port, watch a restart, and confirm you can type at its startup or login screen. Test again from cellular data through the VPN. If you installed power-control wiring, verify its behavior during an agreed maintenance period. Record the working connection and login procedure in your recovery instructions. This is an optional improvement; you can complete the guide with a local monitor and keyboard.

Step 11 — Set mount and service dependencies before adding services#

On Linux, a storage filesystem is attached to a directory such as /srv/media. If that filesystem is absent, the ordinary directory may still exist. An application can then write to the server's operating-system disk instead of the intended storage. This specific trap concerns Linux mount paths; it is not a description of how Finder or Windows presents a disconnected network share.

Ask your AI operator to make applications check the actual storage source before starting, and stop rather than write somewhere else if the required storage is missing. A folder existing is not enough. You will test this with a disposable application before using valuable data.

Prompt to paste when the storage is added:

For each service that needs storage, verify the expected mount source,
filesystem type, and identity before allowing startup. Declare its mount and
startup dependencies using the installed systemd/Compose features. Use Compose
long bind syntax with create_host_path: false where applicable; that alone is
not proof that the intended filesystem is mounted.

Test a missing mount and a failed read/write check on disposable data. The
application must not start writing to the underlying local directory. Don't
solve mount ordering by widening permissions or disabling NFS root squashing.

Step 12 — Record the intended configuration in Git#

Ask your AI operator to save the installation choices, network setup, account restrictions, update policy, and recovery instructions in your ops folder. Save original hardware reports separately if they contain details you've chosen not to share with the provider.

Have your AI operator commit and push these records to your private GitHub repository after each task. Include configuration, equipment changes, decisions, and test results. Keep an offline working copy for recovery. Git tracks these text versions; databases and household files still need their own backups, and credentials need a separate protected recovery copy.

Step 13 — Give your AI operator one complete phase of work#

Once you've agreed on this setup, let your AI operator finish its authorized inspections and preparation. Your part should be the decisions, physical connections, secret entry, and clearly explained administrator actions.

Ask it to group the work into a complete procedure with checks, not a stream of unexplained commands. If a result differs from the plan, it should stop and explain what changed before asking you to do more.

Common mistakes#

Don't erase a disk identified only as “the empty one,” disable password login before testing your key, or configure networking over your only working connection. Don't grant Docker or administrator access simply because it makes an inspection easier. Each shortcut creates a recovery problem that is harder to solve after real data and services arrive.

Final test#

Before adding applications or connecting data disks, restart from a fully powered-off state. Test your local console login, SSH from your admin computer, and the direct cable. Check that your AI operator's access restrictions still hold. Confirm that updates, time synchronization, logs, and normal networking work after reboot.

Have a fresh AI operator session read the saved notes and describe how to reinstall the operating-system disk without touching the data disks. Resolve any missing information now. Repeat these checks for every server in your plan. Next, set up the network and backup power. The storage chapter covers connecting drives, recording their identities, and choosing how to store and share data.