Hardware and base installation: a Mini PC as a local server
- The foundation: a Mini PC and Debian 13
- Prerequisites
- 1. Install a minimal system
- 2. Update and create an administrator
- 3. Configure SSH keys before disabling passwords
- 4. Limit inbound access
- 5. Enable security updates
- 6. Lock root only after testing
- Troubleshooting
- Sources and technical documentation
The foundation: a Mini PC and Debian 13
A small x86 Mini PC is usually sufficient for Nginx, PHP-FPM, and several Python services. More important than a generic core count are a supported CPU, enough memory, a replaceable SSD, Gigabit Ethernet, and adequate cooling. Eight gigabytes of RAM is a practical starting point; 16 GB leaves room for databases or containers.
Measure the actual system if power cost matters. Maximum adapter ratings do not describe idle consumption with a particular CPU, SSD, RAM configuration, and BIOS.
Affiliate disclosure: the following link opens an Amazon search. php99.de may receive a commission from a qualifying purchase; the buyer's price does not change.
Search for Mini PCs on Amazon Germany
Prerequisites
- Debian 13 netinst image and a USB drive
- wired network access
- a second computer for SSH
- local console access as a fallback
- a backup if the Mini PC already contains data
Debian 13 “Trixie” is the current stable release in August 2026. Debian 12 became oldstable on 11 July 2026 and receives LTS support until 30 June 2028. A new installation should therefore use Debian 13.
1. Install a minimal system
Select only SSH server and standard system utilities in the installer. A desktop is unnecessary. Use a short hostname and reserve the server's address in DHCP rather than hard-coding network details blindly.
2. Update and create an administrator
As root:
apt update
apt full-upgrade -y
apt install -y sudo openssh-server unattended-upgrades apt-listchanges nftables
adduser max
usermod -aG sudo max
Log in as max and verify sudo -v before restricting root access.
3. Configure SSH keys before disabling passwords
On the client:
ssh-keygen -t ed25519 -a 64 -C "lanserver-admin"
ssh-copy-id max@SERVER-IP
ssh max@SERVER-IP
ed25519 is the algorithm name; it is not a placeholder for a number. Keep the current session open and test a second login. Then create /etc/ssh/sshd_config.d/10-lanserver.conf:
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
sshd -t
systemctl reload ssh
Moving SSH to another port does not replace keys or a firewall. Port 22 is reasonable for a LAN-only server.
4. Limit inbound access
The firewall must preserve the current SSH path. A UFW example for a known LAN is:
apt install -y ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow from 192.168.188.0/24 to any port 22 proto tcp
ufw enable
ufw status verbose
Replace the subnet with the real one. Open ports 80 and 443 only when a web service actually needs them. A LAN server does not require router port forwarding.
5. Enable security updates
dpkg-reconfigure unattended-upgrades
systemctl status unattended-upgrades.service
Automatic updates still need supervision; some updates require a restart. Logs are stored under /var/log/unattended-upgrades/.
6. Lock root only after testing
passwd -l root
This may be redundant if the installer already created a locked root account. What matters is a tested administrative login and a local recovery path.
Troubleshooting
- Use
ip addressandip routefor network problems. - Check
systemctl status sshandjournalctl -u sshfor SSH failures. - Run
sshd -tbefore every reload. - Use
ss -lntupto see listening services. - Change firewall rules only while console recovery remains available.