Home Server: Turning a 2014 Laptop into Home Infrastructure

A home server does not need to start with new hardware or a complicated architecture. This project began by reusing a 2014 Mac laptop that had been sitting unused for some time. The machine now runs Ubuntu Server 26.04 LTS and provides a small platform for home networking, monitoring and administration services.

Hardware and network

The server has four CPU cores, 7.16 GB of RAM and approximately 233 GB of storage. It connects to the home network over Wi-Fi and uses a fixed private address. The DIGI router provides Internet access and advertises the server as the DNS resolver through DHCP.

The most important design decision was keeping the system inside the local network. No router ports have been opened and no service has been published directly to the Internet. The current goal is not high availability. It is to run useful, controlled and documented services on hardware that is already available.

Deployed services

All services run in Docker containers.

Pi-hole: filtered DNS

Pi-hole is the main service. The router advertises Pi-hole as the DNS server for devices on the home network, so DNS requests pass through a shared filtering layer without requiring an application on every device.

The configuration uses Cloudflare as its upstream DNS provider and stores Pi-hole configuration persistently. The web interface uses local HTTPS with a self-signed certificate. Its password is handled as a Docker secret and kept outside the project notes.

The installation was validated with normal DNS queries and blocked advertising domains. This confirms that Pi-hole is working as the LAN DNS filter. The rollback and full restoration procedures still need to be tested.

Portainer: Docker administration

Portainer provides a web interface for inspecting and managing Docker containers and stacks. It is useful for daily operations and for checking service status without relying exclusively on the terminal.

Access is restricted to the local network. Before adding new network interfaces, such as Tailscale, the listening interfaces and firewall rules will need to be reviewed again.

Uptime Kuma: availability and alerts

Uptime Kuma checks the router, Internet connectivity, Pi-hole DNS, web panels, SSH and the Netdata API. The monitors run at regular intervals, and selected checks send alerts through Telegram.

The notification path was tested end to end. A controlled failure generated a DOWN alert, and restoring the target generated an UP notification. This makes it possible to distinguish several network and service failures.

Uptime Kuma is not limited to monitoring the home server itself. It can also monitor the availability of other projects, such as Nupzi. This allows me to track whether an application is responding correctly, detect outages and receive an alert when a service becomes unavailable.

There is an important limitation: Uptime Kuma runs on the same server it monitors. If the laptop, Docker, power supply or Kuma itself fails completely, it cannot send an alert. External monitoring is required to cover that failure mode.

Netdata: system metrics

Netdata adds local metrics for CPU, memory, disk, network and other system components. Its dashboard was validated from another device on the LAN and displayed more than 4,000 metrics together with local history.

Netdata will help investigate recent stability problems, but it does not replace SMART disk checks or independent monitoring. Persistence across the next server reboot also remains to be verified.

Security and current status

The firewall limits access to the local network. Passwords, tokens and private keys are not stored in the project. Local certificates are self-signed because the services are not exposed to the public Internet.

Connectivity incidents occurred on September 12–13 and again on September 15. Restarting the server restored access, but the cause is still unknown. It has not yet been confirmed whether the problem was related to DNS, networking, the operating system or the hardware.

Next steps

The priority is stabilisation before adding more services:

• Review logs, load, memory, swap and behaviour after a reboot.
• Inspect the hardware and verify disk SMART health.
• Investigate the freeze observed when connecting HDMI.
• Create backups and perform a real restoration test.
• Configure a dedicated SSH key.
• Add external monitoring for complete-host failures.
• Evaluate Tailscale for remote DNS access without opening router ports.
• Decide whether to keep the current hardware, migrate the services or retire it.

The project already has a functional foundation. The next stage is not about installing more applications. It is about proving that the services can be recovered, that the data is protected and that a hardware failure will not leave the entire network without diagnostics.