Tutorials

How I Turned a Raspberry Pi Laptop Into a Private Home Server

I had a Raspberry Pi learning kit gathering dust in a cupboard. It now runs four apps I use every day, and I can reach every one of them from my phone anywhere in the world — with nothing exposed to the internet, no cloud provider involved, and nothing bought.

This is the full walkthrough of how I built it: the steps in order, the three things that genuinely caught me out, and the one piece of standard advice I deliberately ignored. If you have an old Raspberry Pi in a drawer, this is a weekend of evenings well spent.

What you need before you start

• A Raspberry Pi 4 or 5. Mine is a CrowPi 2, which is a Pi 4 built into a laptop shell with a screen, keyboard and a sensor board — but any Pi works for everything except the sensor dashboard.
• A microSD card, 32GB or larger. Use a spare one: writing it erases whatever is on it.
• A USB card reader, if your PC has no card slot.
• An ethernet cable if you can reach the router. Wi-Fi works, but wired is steadier for something that needs to stay reachable.
• A Windows PC, and Raspberry Pi Imager, which is free.
• A free Tailscale account, for the phone access at the end. No card details, no domain, nothing to buy.

What you end up with

A machine on a shelf, lid closed, drawing a few watts, running four things: a control panel for the apps, a status page that tells me when something falls over, my own password manager, and a live dashboard of the sensors on the machine’s own board.

Each one is an icon on my phone home screen. I tap a tile and it opens, full screen, like any other app. That is the whole daily experience of it — I have barely typed a command at the thing since the week I set it up.

Why a Raspberry Pi rather than an old laptop

I considered wiping a laptop and I am glad I did not. The reasons matter if you are nervous about starting.

• Nothing gets destroyed. The whole system lives on a memory card. My old setup came out on its own card and went in a drawer, untouched. No BIOS to fight, no boot menu key to catch, no screen asking me to confirm erasing a disk.
• Every mistake is reversible. The worst thing I could do was ruin a memory card, and the fix is to write it again. That safety net is why I experimented instead of following instructions nervously.
• It costs pennies to run. A Pi draws a few watts. An old laptop is several times that. A machine meant to run permanently should be cheap to run permanently.

The trade-offs are real. A Pi 4 is slow compared with a desktop, so anything involving building software takes its time. A little software has no version for this kind of processor. And memory cards wear out when something writes to them constantly, which a server does — a USB SSD is the sensible upgrade eventually, though I have not needed it yet.

Step 1: Write the card, and fill in the settings screen

Install Raspberry Pi Imager on Windows. Choose your Pi model, then choose Raspberry Pi OS 64-bit — the full version, not Lite, so you have a desktop to look at if something goes wrong. The 64-bit part matters, because plenty of software has stopped shipping 32-bit builds.

Then the step that saves you the entire rest of the evening. Before writing, open the settings screen. Set the machine’s name, create your username and password, enter your Wi-Fi details, set your time zone, and switch SSH on.

Filling in that one screen is the difference between a server that arrives ready to talk to you, and an afternoon spent plugging a keyboard into a Pi and typing configuration by hand.

I left Raspberry Pi Connect switched off. It is a remote-desktop service that routes through Raspberry Pi’s own servers and wants an account, and connecting over my own network was enough.

Then click write and leave it alone. On a large card that takes ten to thirty minutes. Resist opening the drive in File Explorer while it runs.

Two things went wrong here, both my fault. Imager told me the device was no longer available, which means the card dropped out mid-write — closing Imager, reseating the reader and starting again fixed it. It also warned me a card might be write-protected. Check the little lock slider on the card adapter, but be aware this can also mean a card has worn out and flipped itself permanently read-only, which is the end of that card. And do not format cards in Windows first: Imager formats them correctly as part of writing.

Step 2: First boot, and connecting from Windows

Power off, swap the card in, plug in ethernet, power on. The first boot expands the card and reboots itself once, which looks alarmingly like a crash. It is not. Give it a few minutes.

What I saw on the screen was not much, and this is worth saying: a black screen on a Pi does not mean a dead Pi. My keyboard is wireless and needs its own power switch on and its receiver plugged in, so a keyboard that appears dead looks exactly like a machine that appears dead. The server underneath can be running perfectly.

It did not matter, because I never needed the keyboard — that is what switching SSH on was for. From PowerShell on my PC I connected to the Pi by name, typed the password I had set in Imager, and I was in.

The thing that confused me longest: one window, two computers. The window is on Windows, but while the connection is open, what you type runs on the Pi. The prompt tells you which. A prompt with the machine’s name and a dollar sign means the Pi, and that is where Linux commands belong. A prompt starting “PS C:\” means Windows, and the only thing that belongs there is the command to connect. Also, when you type the password, nothing appears on screen — no dots, no stars. That is deliberate, not a broken keyboard. I typed mine three times before I believed it.

Step 3: Docker, and a panel to see through it

Update the system first, which on a Pi is a solid ten minutes of watching text scroll. Then install Docker.

Docker is less intimidating than it sounds. Each app runs in its own sealed box. The boxes cannot interfere with each other or with the machine underneath, so a badly behaved app cannot take the server down with it, and removing something leaves no mess behind. For a first server that containment is the most useful property it has, because it makes experimenting safe.

On top of that I installed Portainer, a web page that shows what Docker is doing: every app listed, with buttons to restart it, stop it, or read its logs when it misbehaves. That panel is my entire day-to-day interface to the machine.

This is where I nearly gave up. Portainer’s first-run page asks you to create an admin user, and the Create button was greyed out with no explanation. Recent versions print a one-time setup token into the container’s own logs at startup, and the form will not submit without it. Nothing on the page says so. Once I pulled the token out of the logs it went through immediately.

When a button is greyed out and nothing explains why, read the logs. That single habit unblocked me more than anything else in this build.

Two related traps: restarting the container issues a fresh token and invalidates the old one, and a brand-new install locks itself if you leave it unclaimed for a few minutes. Create that admin user promptly, and set a proper password rather than leaving whatever you used to get in.

Your browser will also warn that the connection is not private. That is expected on a home network — the Pi signed its own certificate and no authority vouches for it. Clicking through is fine here.

After logging in I saw exactly one app running: Portainer itself. The server managing itself and nothing else. A slightly comic first screen, but the right one.

Step 4: Give it an address that does not move

A server whose address changes is a server you cannot find. The tidy fix is telling your router to always hand the same number to that machine, which needs a router login. I did it on the Pi instead, which leaves the router untouched.

The risk is that a typo cuts off the very connection you are using to make the change. I hedged by leaving Wi-Fi on automatic, so there was a second route in if I broke the first. I picked a low number, well below the range my router hands out automatically, to avoid a collision later. And I noted the router’s own address before starting and left it alone — that is not the thing being changed.

After a reboot the Pi came back on the new address with the panel already running, because it is set to restart itself with the machine. That was the first moment it felt like a server rather than a project.

Step 5: Reach it from your phone, without opening your router

I expected this to be the hard part. It was the easiest thing in the build.

The traditional approach is to open a port on your router and point it at the machine. I did not want that: it means a service on my home network is exposed to the entire internet and probed constantly, and getting it wrong has real consequences.

Instead I used Tailscale, which builds a small private network out of your own devices wherever they physically are. Install it on the Pi, sign in, then install the phone app and sign in with the same account. That is genuinely it. My phone now reaches the Pi as though it were sat at home, over mobile data, from anywhere — and nothing is open to anyone else.

The first time I loaded my own server on 4G with home Wi-Fi switched off, I understood why people get enthusiastic about this hobby.

Every failure I hit here was the address, never the tunnel. If the phone says the connection was refused, the usual cause is leaving the port number off the end, or typing http where the panel needs https. If the app shows your devices connected to each other, the network is fine and the problem is what you typed. I also left the advanced options alone — there are settings to route your whole phone’s traffic through your house or reach every device on the home network, and I needed neither to reach my own apps.

Step 6: What to actually put on it

Four things, in a deliberate order.

A status page first. Uptime Kuma watches the server and the other apps and tells me when something is down. Small, useful and almost impossible to break, which makes it the ideal first install: it proves the whole pattern works while carrying no risk.

Then something I wrote myself. I built a dashboard for the Pi’s sensor board — temperature, light, motion — and put it on the machine as a phone app. This was the important step.

Installing someone else’s app teaches you which buttons to press. Getting something you wrote onto the server and onto your phone is what makes every app afterwards feel routine.

One catch if you have a CrowPi and install plain Raspberry Pi OS as I did: none of the manufacturer’s sensor software is preinstalled, and you will be working the wiring details out from their documentation. If that defeats you, the fallback is a dashboard of the Pi’s own health — processor load, temperature, memory — which needs no special hardware, then add real sensors one at a time.

Then a password manager. Vaultwarden, once the pattern was thoroughly boring. This is the one that gets daily use, and it is the one I would not have installed first — I wanted confidence in the machine before trusting it with something I would genuinely miss.

I deliberately did not attempt the heavy things people put on home servers: transcoding 4K video, camera AI, running language models, a fully loaded personal cloud. A Pi 4 is the wrong hardware for all of them, and finding that out by struggling would have soured the project.

Step 7: The step that made me actually use it

For a while I had a server with apps on it that I was barely using, because opening anything meant remembering an address and a port number. Small friction, but enough.

What fixed it was putting every app on my phone home screen as its own icon. Chrome on Android can install a web page as an app: it gets a proper icon and opens full screen with no browser bar. I did it for all of them, not just the one I had written.

Now my server looks like four ordinary apps on my phone. That sounds cosmetic and it is not — it is the difference between a home lab you administer and a home lab you use.

Two practical notes. The install prompt needs a properly trusted secure connection, so the self-signed certificate the Pi generates for its own panel is not enough on its own; Tailscale can issue a real certificate for a name on its own domain, which satisfies it. And do the install step in Chrome specifically, because other browsers handle it differently or not at all.

Learn from my oversight: once everything launches from tiles, those tiles quietly become the only record of where anything lives. If my phone were reset, the icons would go and nothing would remember which app was on which port. I now keep a printed sheet of the addresses next to the machine.

Backups, and the advice I ignored

The memory card is the weak point in a Pi server, so once there was anything on there I would miss, I set up backups. Mine copy the application folders across the network onto my laptop. A USB drive plugged into the Pi is simpler, but I prefer the copy living somewhere other than the machine that might be the thing that fails.

Then the more interesting half: what I chose not to do.

Nearly every home lab guide tells you to add a reverse proxy, so each app gets a readable name instead of a port number, with proper padlocks in the browser. It is genuinely good advice — if you type addresses. I launch everything from tiles and never type an address at all, so it would have solved a problem I do not have. I left it out.

I mention it because the instinct when following guides is to complete the list, and the list is written for a generic reader rather than for you. Adding infrastructure you do not need is not neutral: it is one more thing to maintain, break, and forget the details of. If port numbers start irritating me, I will add it then.

What I would tell someone about to start

• Fill in the settings screen before writing the card. It removes almost all the fiddly work that follows.
• A black screen is not a dead machine. Check the keyboard has power before concluding anything is wrong.
• An invisible password is normal. Type it and press enter.
• When a button is greyed out with no explanation, read the logs.
• Leave yourself a second way in before changing anything to do with networking.
• Put your own work on it early. The pattern only clicks once you have carried something you made all the way through to your phone.
• Make the phone tiles. Otherwise you have built something you admire rather than something you use.
• Stop when it does what you wanted — not when the guide runs out of sections.

What surprised me most is how little of this was technical. The commands came from documentation and worked. My evenings went on small confusions — which computer am I typing at, why is that button grey, why does the screen look dead — none of which appear in any instructions, because they are too obvious to the person writing them.

That is really why I wrote it up. The steps are easy to find. The stumbles are not.

The machine sits on a shelf with the lid closed, drawing a few watts, running four apps I can reach from anywhere and nobody else can reach at all. Total cost was nothing beyond hardware I already owned and had given up on. It is the same shape as the intimidating setups people post photographs of — a machine that stays on, a panel to manage the apps, and a private route in from my pocket. The scale is smaller and the parts are cheaper, and it turns out the shape is the part that matters.