Why run a server at home?

Your family photographs are on a disk in a building you have never seen. That is a reasonable deal, and the companies running those servers are better at it than you or I will be. But it has terms: the price can change, the product can be discontinued, and an automated system can lock the account with nobody to appeal to.

This book is about the other option: a small computer in your house that holds the things you care about, that you understand, and that keeps working when a company changes its mind.

What you are signing up for #

The cost, which most tutorials skip: maintenance is now your job. When the photo app stops syncing the evening before a holiday, you fix it. When a disk fills up, you fix it. Nobody installs the security updates on your behalf.

A home server without backups is one copy of your photographs. The cloud service you are replacing kept several, in several buildings, so that is a downgrade. The backups chapter comes before the chapter where you move real data in. Do not reorder them.

So why do it anyway?

The alternative to understanding your infrastructure is trusting it blindly. The skills transfer to almost everything else in software, a machine you built behaves predictably, and it is more satisfying than a monthly subscription.

Side readingChoosing hardwareWhat actually matters for a family server, what does not, and what an old laptop can and cannot do.

What we are going to build #

This is where we end up, though not in this order.

Replay

Reading that from the outside in: enrolled family devices reach the photo application and its login service over a private mesh, without an inbound router rule. Administrator devices get a separate SSH grant. Applications reach only the networks and mounted data they need; databases and files have no direct client route.

If some of those words mean nothing to you yet, that is expected. They are what the next chapters are for.

The whole stack, in one table #

Every piece of software this book installs, what it is for, and where it arrives. If you already know this territory, this is the fastest way to see which architecture the book committed to and decide whether you agree.

	What it is	Arrives in
Ubuntu Server	The operating system. Any current Debian-family release follows along.	Chapter 2
OpenSSH	Encrypted remote shell for administration.	Chapter 3
unattended-upgrades	Installs security patches on a timer, without rebooting on its own.	Chapter 3
UFW	A friendly front end for the kernel's packet filter. Deny by default.	Chapter 4
Ansible	Describes the host's configuration as a file you can reapply.	Chapter 5
Docker Engine	Runs the application services in containers; several later host tools remain native.	Chapter 6
Docker Compose	Describes a set of containers as a file.	Chapter 6
Immich	Photo and video library, with phone backup and search.	Chapter 7
PostgreSQL	The database under most of the applications here.	Chapter 7
Valkey	In-memory cache and job queue. The Redis fork.	Chapter 7
Traefik	Reverse proxy. One front door, routed by hostname.	Chapter 8
Traefik file provider	Routes reviewed hostnames without giving the proxy Docker API access.	Chapter 8
SOPS	Encrypts secrets so the configuration can live in git.	Chapter 9
age	The encryption SOPS uses here. One keypair, no ceremony.	Chapter 9
Tailscale	A private network only your own devices can join.	Chapter 10
restic	Encrypted, deduplicated backups to somewhere else.	Chapter 11
Tailscale Serve	Private HTTPS for enrolled family devices, with no inbound router rule.	Chapter 12
Authentik	Central login and multi-factor policy for supported applications.	Chapter 13
Prometheus	Collects metrics and evaluates alerting rules.	Chapter 14
Alertmanager	Turns firing alerts into email you actually receive.	Chapter 14
Grafana	Dashboards over the metrics and the logs.	Chapter 14
Loki	Stores logs so you can search across containers.	Chapter 14
Grafana Alloy	Ships container logs into Loki.	Chapter 14
node_exporter	Reports CPU, memory, disk and temperature from the host.	Chapter 14
blackbox_exporter	Probes the local TLS, proxy and application path.	Chapter 14

The Tailscale control plane coordinates identities and endpoints, and your chosen backup destination is another failure domain. The chapters state what depends on each outside service. The applications and household data stay on your machine; remote access and off-machine recovery still have external dependencies.

Side readingCompose, Swarm or KubernetesWhy this book uses Docker Compose on one machine, what the alternatives buy you, and the honest signs that you have outgrown it.

Four questions #

Every service you install asks the same four questions. Most tutorials answer them by accident. This book asks them deliberately.

Who can reach it? From which networks, on which port, through which piece of software. "Is it secure" is unanswerable; this version is not.

Who are you? Whether the service knows who is knocking, how it decided that, and what it lets each person do. A shared login is an answer to this question. A bad one.

Where does the data actually live? Which directory, on which disk, owned by which user, and what happens to it when you delete the container. The answer decides whether an upgrade is routine or a disaster.

How do you know it is alive? Whether you find out from a monitoring alert, or from your partner asking why the photos stopped uploading. Most home servers work the second way, and most home servers are quietly broken.

Have a play with the first question now. Nothing here touches your server; it is just a way of fixing the idea in place.

Look at the middle row. Your home wifi has a smart TV on it, a guest's phone, and whatever your neighbour's kid connected last summer. Being on it is not the same as being trusted, and that shapes half the decisions in this book.

What you need before the next chapter #

You do not need a provider account or a static IP address from your ISP. Chapter 8 asks for a registered domain you control before it creates certificates; if you want a purely private name instead, it explains the reserved home.arpa alternative.

How to read this book #

Every chapter has the same shape, and you can rely on it.

It opens with what you should be able to do by the end. Then the idea, explained before any command appears, because a command you do not understand teaches you nothing. Then the work, in small steps, each one saying what it changed and why that way rather than another. Boxes like this one hold the reasoning:

Why explain first and type second?Show me why

Because the failure mode of copy-paste tutorials is that they work. You end up with a running system and no model of it, which means the first time something breaks you have no idea where to look, and no way to tell a confident wrong answer from a correct one.

One more thing about how the book is written. It has to call your server something, so it uses placeholder names: a user called admin, a machine called homeserver, an address on your network. Those are almost certainly not yours.

So they are not fixed. Put your own in and every chapter rewrites itself around them, including the commands you copy and the prompts you paste into an assistant. An assistant told your network is 192.168.1.0/24 when it is not will send you chasing the wrong thing.

You can make the book use your names

• adminYour login name on the server
• homeserverYour server's hostname
• 192.168.1.20Your server's address

The book uses these placeholders. Put your own in and every page, command and prompt updates to match.

You do not have to do it now. Chapter 2 is where you find out what most of these actually are, and there is a link back to this page from every chapter that introduces a new one.

Chapters end with a checklist you can tick, which also drives the progress bar in the sidebar, and a short recap. Where a topic would have doubled a chapter's length, it has been moved out to side reading, linked from the point where you would want it.

Side readingGlossaryShort definitions of the words this book leans on, in the sense this book uses them.

How to use the prompts #

At the top of every chapter there is a button that copies a prompt to your clipboard. Paste it into a new session with whichever AI assistant you use. The prompt already contains where you are in the book, what you have built so far, what the current chapter is trying to achieve, and what state your server should be in. You do not have to explain any of that.

It also tells the assistant how to help: one diagnostic command at a time, an explanation of what each result would mean, the reasoning before the fix, and you doing the typing. The aim is to get you unstuck without skipping the understanding.

There are two kinds. The button in the header always gives you a prompt for whichever section you are currently reading. And at specific places where people reliably get stuck, there is a card like this one, with a sharper description of the situation:

I have read the first chapter and I am unsure whether to commit to this. I would like to talk through my situation: what hardware I have, what I actually want out of it, and whether the maintenance burden is worth it for me. Ask me questions rather than selling me on it, and tell me honestly if you think a managed service would suit me better.

Two warnings about this, from experience.

An assistant will sometimes be confidently, fluently wrong about your specific machine, because it cannot see your machine and it is very good at sounding certain. If its explanation does not match what you are seeing, trust what you are seeing, say so, and ask it what command would settle the disagreement.

And if you find yourself pasting a prompt at the first sign of friction, slow down. Read the error. Errors on Linux are usually more informative than they look.

Side readingWorking with an AI assistant without outsourcing your brainHow to use the prompts in this book, what they are trying to prevent, and what to do when the assistant is confidently wrong.

The rules we will follow #

Five habits, used throughout the book.

Change one thing at a time. Then check it. Two changes at once means two suspects when something breaks, and the interaction between them is a third.

Keep a second door open. Whenever you edit something that could cut off your own access, have a second terminal already connected and logged in. If the change locks the door, that session is still inside.

Write down what you did. Not for anyone else. For yourself, in eight months, wondering why that file has a strange setting in it.

Test the control, do not assume it. Try to get past your own firewall rule. Several chapters end by attacking the thing you just built.

No real data until the book says so. As above. Use test photos and throwaway accounts.