Why We Start the Server Edition Here
In the main edition (the desktop edition), we walked through replacing the PC you use every day with Debian. That was about making "the desk you sit at every day" run Debian. It has a screen, a mouse, a keyboard, and it runs only while you are touching it.
A server is different. A server is the backstage worker that keeps running while you are not touching it. It hands out files in the middle of the night, stores your photos, syncs your notes, keeps the app you wrote alive. Even when no one is watching the screen, it does not stop. That is the essence of a server, and the biggest difference from a desktop.
This server edition is open both to readers who have finished the main edition and to readers reading it in parallel. The only prerequisite is "you can type a single command at a Debian terminal." With that alone, you can enter a world where you run your own file sharing, your own photo server, your own note sync, and your own homemade apps — on your own machine.
Right at that entrance, let me declare this book's premises.
- The server lives in your home or on a VPS. An old PC or mini PC running in your house, or a VPS rented for a few hundred yen a month. Either way, the inside of the OS — root — is yours. Which one to start with is decided in Chapter 2.
- You manage your own data. It is not entrusted to someone else's cloud service — it lives in the databases on your own server (Chapter 7), and you back it up with your own hands (Chapter 10).
- No containers. Apps run as "directory + venv + systemd," isolated by permissions and systemd's sandbox (Chapter 8).
In other words, this is not a book of server generalities. It is a book about building your own infrastructure and taking the initiative over your data back into your own hands. Why choose these premises? Section 2 makes the case.
This is not a how-to chapter. It is a second prologue of sorts, settling three things: what a server is, why you would own one yourself, and how to read this server edition.
Section 1 — How a Server Differs from a Desktop
The Defining Feature: No Screen
A server, as a rule, has no GUI — no graphical desktop. No icons to click with a mouse, no windows. All there is is text lined up on a black screen.
If that strikes you as "inconvenient," shift your view by one notch. No screen means every operation becomes text. And text is the domain Claude handles best.
In the main edition's prologue, we wrote that "in the AI era, the cost of Linux's strengths dropped dramatically" — that you can learn how to read journalctl in seconds by asking Claude. On a server, this effect grows even stronger, because a server has no escape hatch of "vaguely clicking around in a GUI" to begin with. Everything resolves into text you can show Claude.
# Everything happening on a server can be pulled out as text
uname -a # kernel and architecture
cat /etc/os-release # distribution and version
systemctl status # overall state of running services
journalctl -xe # recent system logs
Paste this output straight into Claude, and Claude can read what is happening on your machine right now at the same precision you can. The "craft of telling your environment" you picked up in the desktop edition works fully here, on a server.
Remote Operation Is the Norm
A server is usually placed somewhere away from your hands — an old PC in another room, a mini PC in the closet, or a VPS on the far side of the internet. So operation is "remote" by default. From your Debian desktop at hand (or another PC), you enter the distant machine through a mechanism called SSH and type commands there.
# The basic form of entering a server from your local terminal (details in Chapter 4)
ssh username@server-address
Remote operation feels strange at first, but once you get used to it, it feels like nothing more than "adding one more screen." SSH setup is covered carefully in Chapter 4. For now, just grasp that "a server sits somewhere far off, and you enter it through text."
"Rebooting" Carries Weight
On a desktop, if something feels off, you reboot without a second thought. A server is different. When a server reboots, your file sharing, your photo server, and your homemade apps all stop for that duration. While it is just you using it, this is no big deal. But once family or coworkers start using it, a single reboot becomes "a service outage for everyone."
So in the server world, you come to constantly ask "can I fix this without stopping it?" and "when can I stop it with the smallest impact?" This is not a constraint — it is part of the fun of design.
One User, but the Moment You Publish, Your Counterpart Is the Whole World
There is one more decisive difference from a desktop. A desktop is, in essence, touched by you alone. A server, too, has only you as a user while it lives inside your home LAN.
But the moment you publish a server to the internet, those connecting to it become the whole world. Not only well-meaning visitors. Automated scanning programs around the globe hammer at exposed servers twenty-four hours a day. This is not a scare line; it is an observed fact. This "threat model" discussion is handled properly in Chapter 5. For this chapter, just take note that "publishing is a heavy decision and requires dedicated preparation."
Ask Claude ①: Take Stock of What You Want to Run on a Server
I am about to start a server on Debian. So far, the things I want to run or store on the server are: [e.g., storing family photos, work file sharing, my own note sync, a web app I built while studying... bullet them as they come to mind]
Please sort these into "things I will use alone, LAN-only," "things I may want to expose externally someday," and "high priority vs. low priority," and put them in a table. For each, add a rough estimate of the memory and disk space needed.
Putting "what you want to run" into words first makes it easier to decide where to put it (Chapter 2) and how to build it (Chapter 3 onward). Have Claude sort it, and candidates you had not even noticed line up in the table.
Section 2 — Why Your Own Server
Independence from Leaving It All to the Cloud
Photos go to a cloud photo service, files to some storage, notes to another company's sync service — before you know it, the data of your life is scattered across the servers of multiple other companies. Convenient, but in exchange you have handed over the initiative on "where your data is, who can see it, and how long you can use it."
The stance repeated in the main edition — "keep your distance from vendor lock-in," "eliminate black boxes" — deepens a notch on a server. Put data on your own server, and it sits on a machine where you hold root (at home, it is physically in your hands as well). If a service raises its price, changes its terms, or shuts down, your data remains under your control. That is data sovereignty.
Facing the Pile-up of Monthly Fees
Cloud services each look cheap on their own. But a few hundred yen for photos, a few hundred for storage, a few hundred for notes — pile them up and the yearly figure is not negligible. And most are structured as "pay forever, as long as you keep using it."
Your own server takes some effort and cost up front, but the pile-up afterward is small. The cost comparison is done concretely in Chapter 2. Here, just grasp the direction: you can replace a collection of small monthly fees with a one-time bout of learning and a modest electricity bill.
The Value as Learning
And do not forget the value as learning. Server administration is the backbone of IT. Websites, business systems, cloud services — almost all software running in the world, taken to its root, runs on top of a Linux server. Hands-on experience with how it works becomes a foundation no matter which other technical field you move into next.
Server administration used to be "a high-barrier thing, the province of experts." You had to read thick books, look up the meaning of error messages like a dictionary, and memorize the grammar of config files. Claude has collapsed that entry cost. Paste an error message and its meaning comes back; describe what you want to do and a config example comes back. Now, with the entrance torn down, is the perfect time to learn servers.
Ask Claude ②: Choose Candidates to Self-Host
The services I currently leave to cloud providers, on monthly fees or free tiers, are: [e.g., photo auto-backup = ___, file sync = ___, notes = ___, household budget = ___, with service name and monthly cost where you know them]
Out of these, please separate "things easy to self-host" from "things hard or not worth self-hosting" on a Debian server, with reasons. For the easy-to-self-host ones, also name representative software available on Debian.
You do not need to self-host everything. The smart move is to pick only what is worth it. By having Claude name the "hard / not worth it" side too, a comfortable scope comes into view.
Section 3 — How to Read the Server Edition
Carry the Main Edition's Craft Over Unchanged
If you read the main edition, you should hold two files on your desk: the my-system.md (a summary of your hardware and software) you made in Chapter 3, and the my-claude-profile.md (a profile conveying your situation and preferences to Claude) you made in Chapter 2.
In the server edition, we carry this craft over unchanged. For the server, make one new file, my-server.md.
# My Server (as of 2026-06-10)
## Role
- What to run: (what you sorted in Section 1 ①)
## Hardware
- Machine: (old PC / mini PC / Raspberry Pi / VPS, etc.)
- CPU / memory / disk:
## Network
- Location: (inside home LAN / VPS, etc.)
- Static IP / hostname:
## Publishing policy
- LAN-only for now / plan to publish eventually (nailed down in Chapters 5 and 9)
Hand this single sheet to Claude at every dialogue in each chapter. You save yourself from re-explaining the server's particulars every time.
Start with "a Machine You Can Afford to Break"
In the main edition we wrote, "do not hold both halfway — commit fully to one side." The server edition is a bit more relaxed. The right move is to start with a machine you can afford to break.
The reason is simple: before you load real data onto it, you can rebuild a server as many times as you like. In fact, your first machine should be a practice rig for "break it, wipe it, reinstall it" without hesitation. While you do the minimal install in Chapter 3 and run the basics through Chapters 4 to 8, you can flip this experimental machine over and over. Only once failure stops scaring you are you ready to load real data.
Fill the Ask-Claude Box at Each Chapter's End with Your Own Situation
Just like the main edition, this server edition is "a book printed only halfway." The "Ask Claude" box at each chapter's end is not reference material. Fill the [insert your situation here] spots with your own words and send it to Claude. The answer that comes back is that chapter's "conclusion for you."
The author shapes how to pose the question, you hand over your situation, and Claude translates it into a concrete answer — this three-way division of roles is unchanged in the server edition.
Ask Claude ③: Draft Your my-server.md
I am about to start a Debian server. My situation at hand is: [paste the my-system.md you made in the main edition if you have it; if not, bullet the type of machine you plan to use, its memory, disk, and location]
What I want to run is: [paste the table you sorted in Section 1 ①]
Based on this, please draft a
my-server.mdfor the server. For items not yet decided, write "undecided" and add the question I should think through to decide it.
With this single sheet, every consultation from Chapter 2 onward gets faster. It is the same routine as making my-system.md in the main edition. If that file is still on your desk, you can build on it.
Summary
What you did in this chapter:
- Sorted out how a server differs from a desktop (no screen, remote by default, the weight of a reboot, and that publishing makes your counterpart the whole world).
- Confirmed why you would own your own server (data sovereignty, the pile-up of fees, the value as learning).
- Decided how to read the server edition (carrying over the main edition's craft, starting from an experimental machine, how to fill the Ask-Claude boxes).
- Took stock, together with Claude, of what you want to run and which cloud things are candidates to self-host.
What you hold now:
- A table sorting "what you want to run on a server."
- A list of "candidates to self-host."
- A draft of
my-server.md(used alongside the main edition'smy-system.md/my-claude-profile.md).
In Chapter 2, we decide where to put that experimental machine. An old PC at home, a VPS on the far side of the net, or a major cloud — we draw a map along three axes of cost, responsibility, and network, and choose, together with Claude, the location that fits your situation.
The server sub-series can be navigated from Learning Debian with Claude — Server Edition. The main desktop series is at all chapters. Comments and discussion go to the Facebook group: AISeed — Biodiversity, Food, AI and Life.