Your first Ubuntu home server

1. Use a computer you can experiment with

A home server is a computer that runs services for you. It could be an older desktop or a mini PC. You do not need a rack of equipment to start.

Choose a machine you can leave running when you want its services available. Check its power use, fan noise and available storage. Copy anything important off it before changing the operating system: an installation can erase the disk you select.

For Homelab Launchpad’s core setup, plan around a 64-bit Intel or AMD PC, two CPU cores, 2–4 GB of RAM and at least 10 GB of free disk space, plus space for backups. Those are planning estimates, not guaranteed minimums. ARM devices such as Raspberry Pi are outside this kit’s supported scope.

If you are still learning, practice in a disposable virtual machine first. Keep it separate from services or files you already depend on.

2. Get Ubuntu and Docker ready

The kit targets Ubuntu 24.04 or 26.04 LTS. Ubuntu is the operating system. Docker runs the individual applications in containers, and Docker Compose describes how those containers fit together.

Use the official Ubuntu Server installation guide, then the Docker Engine instructions for Ubuntu. Follow their current prerequisites rather than pasting commands from an old forum post. The kit needs Docker Engine 28+ and Compose v2+, along with the other tools listed in its requirements.

Keep the first setup small: a dashboard with useful links and a monitor for one service. Add media servers, storage services or local AI later, one at a time. Those jobs have their own hardware and maintenance needs.

3. Know where you are connecting

A server without a screen is still manageable from a laptop. SSH lets you use its terminal remotely. An SSH tunnel can also carry a connection from your laptop to a web application listening privately on the server.

Homelab Launchpad’s web ports listen on the server itself by default. Its guide explains the tunnel. If a page will not load, first check that you are on the intended computer, the SSH connection is open and the application is running. Opening router ports is not a fix for a missing tunnel.

A dashboard is a page of links. Adding a link does not install the service behind it or make that service private. Start with services you have deliberately set up.

4. Test an alert before relying on it

A green status badge tells you a check is passing now. You also need to know what happens when the application stops.

Create one monitor in Uptime Kuma. If you want email alerts, enter your own provider’s SMTP settings and send a test message. Then stop only a disposable test application, confirm the monitor detects the outage, and start it again. Check that the recovery message arrives too.

If the whole PC turns off, a monitor running on that same PC cannot notify you. Monitoring a whole-server outage needs a monitor on another device. The kit’s service-outage exercise does not replace that.

The kit’s email exercise was checked with a local test inbox. Delivery through your own email provider still needs testing. A local success does not prove that messages will reach your normal inbox.

5. Practice recovery while nothing is at stake

A backup stored only on the server can disappear with the server’s disk. Make a backup, copy the complete snapshot to private storage on another device, and verify the copied files.

Next, restore it on a separate disposable Docker host or VM. Check that the account, configuration and monitor history you expected are present. Another folder on the same Docker host is not an isolated test environment.

The kit includes manual backup and restore tools. It does not schedule backups, encrypt them or provide cloud storage. Treat snapshots as private because they can contain credentials and application data. Choose a regular backup routine you will actually follow, and make a fresh backup before a significant change.

Before you call it finished

• You can reconnect from your laptop after closing the terminal.
• You understand which applications are running and how to check their status.
• You have seen a test service go down and recover.
• Your alert reaches the destination you chose.
• A complete backup exists off the server, and you have practiced restoring it.

Once those basics work, add one application at a time. Keep a short note of what changed. Troubleshooting is easier when you know what was working before.