For a long time I wanted to run my own server, but I was wary of the cost and the complexity. Then I came across Proxmox VE — and looking back, I wonder why I didn't do it sooner. Proxmox is a free, open-source virtualization platform based on Debian: KVM for full-fledged VMs, LXC for lightweight containers, and a web interface that genuinely makes day-to-day work easier.
The nice thing is that you don't need an expensive server. I started with a used mini PC (a Dell OptiPlex Micro) with upgraded RAM and an NVMe SSD — quiet, power-efficient and more than enough for 10–15 containers plus a few VMs. With electricity prices the way they are here, a mini PC idling at 10–15 watts makes a huge difference compared to a rack server.
After installing, the first thing I did was disable the enterprise repository and set up the community repos, secure SSH login with keys and install Fail2ban. Then came the first services: Pi-hole as a network-wide ad blocker, Nginx Proxy Manager and Portainer. That order has proven itself — start small, don't spin up twenty containers at once.
My most important piece of advice, which I had to learn the hard way myself: set up backups before you install your first service. Follow the 3-2-1 rule — Proxmox's built-in snapshot backups make it almost too easy. And by the way, RAID is not a backup — that's something I had to come to understand too.
Just start. One container, one service, and you'll learn more about infrastructure than in any online course. And if you just want to try things out first, a cheap cloud server works fine for learning, too.
Source: Homelab Guide
According to a report from IT之家, QNAP's four-bay NAS, the Qu405-N150-8G, is now on sale at JD.com. It comes with 8GB of memory and a standard two-year warranty. The unit alone is priced at 2599 yuan, and a bundle with a 4TB Seagate IronWolf hard drive costs 3599 yuan.
The design is simple. The chassis measures 165 mm x 168 mm x 217 mm and weighs 2.15 kg. The processor is an Intel N150 with 4 cores and 4 threads. The company says it can handle 4K video transcoding and run virtual machines and Docker containers, which is a big selling point for people who like tinkering with home servers. The 8GB of SODIMM DDR4 that ships with it can be upgraded to 16GB.
Storage comes from four 3.5-inch or 2.5-inch SATA drive bays. Inside, there are also two M.2 2280 NVMe PCIe Gen 3 x1 slots, which can be used for caching or for storing the system and container data. The ports include two 2.5GbE network ports, two USB-A 3.2 Gen 2 ports, one USB-C 3.2 Gen 2 port and one HDMI 2.1 port.
In my view, the pairing of dual 2.5G networking with an N150 has become a common configuration for entry-level home NAS units over the past couple of years. It can run Docker without drawing much power, and the price is fairly reasonable. However, the article only lists specifications and includes no real-world testing, so if you are considering buying one, it is worth checking reviews for noise, power consumption and software experience first.
Source: IT之家
Synology has announced its new neo+ series for Germany, made up of the DS725neo+, DS925neo+, DS1525neo+ and DS1825neo+. ComputerBase describes them as cheaper variants of the Plus models, where only the memory configuration has changed.
According to the report, the "neo" stands for "Non-ECC option". These devices use commercially available memory without ECC, and always only 4 GB of it. The DS725+ and DS925+ come with 4 GB of ECC RAM, while the DS1525+ and DS1825+ have 8 GB of ECC RAM, so the neo+ variants have less. Otherwise, equipment, features and expandability match the Plus models, and DSM with its apps is identical too.
In the manufacturer's recommended retail price, the difference is around 200 euros: the DS725neo+ is listed at 549 euros net, the DS725+ at 748 euros net. In retail, though, the gap is not as clear: the DS725+ is currently available from 663 euros, the DS725neo+ from 629 euros. The memory can later be easily upgraded to ECC RAM.
Synology cites the current situation on the memory market, namely the significant price increases that have also hit the Plus models, as the reason.
For the home server segment I find this an interesting trade-off. Anyone who mainly uses a NAS for backups, media and a few containers will probably get by with 4 GB without ECC. Anyone who values data integrity should look closely at what they get for the surcharge.
Source: ComputerBase
Hardware.com.br has featured a homelab that stands out for its small size. A Reddit user posted on r/HomeServer a small 10-inch rack with a firewall, three mini PCs, a NAS and all the network infrastructure needed to run dozens of services at home.
The processing is handled by three mini PCs, each with an 8-core, 16-thread processor and 32 GB of RAM, adding up to 24 cores, 48 threads and 96 GB for virtualization. It uses Proxmox to create virtual machines and LXC containers. The workloads include a VM for Jellyfin, the so-called arr stack running in Docker, another Docker host with Portainer, Pi-hole and dashboards such as Homer and Homepage, plus game servers such as Terraria and Core Keeper.
Storage sits in an HP ProLiant MicroServer with four 4 TB hard drives in ZFS RAIDZ1, which lets you keep accessing the data even if one disk fails. That gives 16 TB raw, with less usable space because of the parity. The network is controlled by a Fortinet FortiGate, which takes care of routing, VLANs and SSL VPN, and an APC Back-UPS 850 uninterruptible power supply protects against power cuts.
In my opinion, the most interesting part is outside the house: the owner keeps two Debian VPSs in external data centers, connected to the homelab by a WireGuard network in a hub-and-spoke configuration. They act as the public layer of the infrastructure, with Traefik serving as the reverse proxy.
It is a good example that a homelab does not need a giant rack: with planning, small boxes and good organization, you can run a lot in little space.
Source: Hardware.com.br
If one server runs more than one project, sooner or later you hit ports 80 and 443, which only one process can listen on. A Habr article from the Selectel blog shows, step by step, how to solve this with Nginx Proxy Manager.
The author first explains the problem: privileged ports, the rule of one listener per port, CORS issues when frontend and backend are split across ports, and the lack of HTTPS. A reverse proxy solves this as an intermediary, routing traffic by domain and path. An extra benefit is that the firewall only needs ports 22, 80 and 443 open.
The test setup is a simple VDS with 2 vCPUs, 2 GB RAM and 40 GB NVMe, running Ubuntu 24.04 and Docker from the official repository. The network is created with docker network create proxy, and the jc21/nginx-proxy-manager container is started with volumes for data and certificates. I liked that the admin panel on port 81 is bound only to 127.0.0.1 and accessed through an SSH tunnel.
Next, a proxy host is configured: the Forward Hostname is the container name, and the SSL certificate is attached on the SSL tab. traefik/whoami is used for testing. The case where the application runs directly on the host is covered separately: the Docker network's gateway address is obtained with docker network inspect, and the firewall is set so the app cannot be reached bypassing the proxy.
There are some drawbacks too. The examples mix different domains, and the image uses the latest tag, so reproducibility may suffer over time. Still, it is a good starting point for anyone who wants to run several services at home or on a VDS without hand-editing nginx configs.
Source: Habr (Selectel blog)
This week's Self-Host Weekly from selfh.st covers a mix of news that homelab people will want to know about. I like this kind of roundup because it saves a lot of feed reading.
The main story is a messy one: a new suite of open source Adobe alternatives was called out as a rip-off of existing projects, most notably the community favorite Photopea, whose developer was among the first to raise the alarm. The two projects at the center, PhotoSuite and PhotoCraft, appear to be connected, and the timeline is hard to follow. The weekly's advice is to steer clear until they prove they are more than derivative work.
Smaller items worth noting: Let's Encrypt announced that it will shorten the lifetime of free SSL certificates from 90 to 64 days in February 2027, which makes reliable automated renewal even more important for anyone running a reverse proxy at home. Nabu Casa is renaming Home Assistant Cloud to Home Assistant Link, because of the negative connotation the word cloud now carries. The encrypted secret-sharing project Hemmelig has been archived on GitHub, and the NVIDIA Shield TV, a seven-year-old streaming box popular with the homelab crowd, got a $100 price increase blamed on AI-driven hardware inflation.
The author also launched the 2026 Self-Host User Survey, with 45 possible questions covering hardware, software, operating systems, demographics and AI. Last year's survey drew just over 4,000 responses and this year's already had 2,000 within two days. It stays open until October 31, with results due in early November.
Personally I find the certificate change the most practical item: if your renewal setup was a bit fragile, now is a good time to test it.
Source: selfh.st
RedesZone answers a question that many people who build a home server end up asking: does a NAS need to be restarted from time to time, or can it be left running all the time?
The short answer is yes, it can stay on 24 hours a day. A NAS is designed to run continuously, it uses storage drives built for that purpose, and it is used for backups, freeing up space on other devices, or sharing large files. Of course it consumes power, just like a router or a security camera. But those devices are designed to use very little energy when idle. Even after months of continuous use, there is no mandatory reason to restart it, apart from saving energy or simply not needing it.
There are situations where a restart is worth it. After updating the operating system, the firmware or certain packages, even if the device doesn't ask for it. When there are software problems, such as an app that stops working, a slow service, a web interface that misbehaves, or errors in some section. After a hardware change, and after any major change in how it operates. Sometimes a process has got stuck or a program didn't close properly, and a restart brings everything back to normal.
I think it is sensible advice without any drama. For a home lab, the practical rule is to let the NAS keep working and restart it deliberately, after an update or when something behaves strangely, rather than out of habit.
Source: RedesZone
When you run open source apps on a home server, you often need to send email for things like sign-ups and password resets. Sending mail directly from home, however, means setting up an SMTP server and configuring a sending domain, which takes more effort than you might expect. This article, which I found on Qiita, solves the problem by simply accepting the trade-off with Mailpit and Discord.
Mailpit was originally a tool for testing outgoing mail. It works as an SMTP server and comes with a test API. If you configure a webhook, it can also call an external application as soon as a message arrives. The article uses this feature to build a setup that posts the contents of incoming mail to Discord.
The setup is just two containers, Mailpit and a webhook-handler, run with Docker Compose. The webhook-handler is a small Python app written in FastAPI. It receives webhooks from Mailpit, formats the sender and recipient, and forwards them to a Discord webhook. The notification can also include a link to the Mailpit web UI, so you can check the message when you need to. Settings such as the webhook URL are kept in a separate .env file.
Even without sending any mail to the outside world, being able to tell right away that a password reset email has arrived looks handy. For anyone running several apps in a homelab, gathering all mail in one place should make management much easier. The post is from August 2026.
Source: Qiita
A small story, but worth a thought for anyone who manages their own home network. According to GenK, an X user called @NomadsGalaxy was checking the Wi-Fi for his parents and found that a Keurig coffee machine had generated about 1 TB of uploads and nearly 10 GB of downloads in just 10 days.
He noticed it while looking at the UniFi network system at his parents' home. The unusual volume overloaded one Wi-Fi access point. Instead of investigating the cause, he unplugged the machine and bought his parents a different product. According to the article, most of the traffic seemed to stay inside the local network rather than going out to the Internet, so there is no evidence yet that the machine sent the family's data to outside servers. The most likely cause is a software bug or a communication fault on the network, and a restart may have fixed it.
The article also points to the bigger picture of the smart home: the more networked devices you have, the greater the chance of faults, security holes or service outages. IoT devices can become an entry point for attacks if the manufacturer does not update their software regularly, and some products lose most of their features when the company shuts down its servers.
For me, the practical lesson is to have a tool that shows traffic per device on the home network, and to consider putting IoT devices on a separate network. Without numbers, it is very hard to notice what a coffee machine is doing.
Source: GenK
Anyone who runs a home network or a small homelab knows the .lan suffix well: it shows up in router panels, internal DNS servers and the addresses we use to reach devices without a registered domain. IlSoftware.it reports that an application submitted to ICANN could turn it into an Internet domain accessible worldwide.
The request for the .lan TLD was filed by Coffee Danger, a US company, and it is still in Pre-Evaluation Processing. This means the domain is not approved and cannot yet be used to register public addresses. The application is part of the new round of top-level domain assignments started by ICANN in 2026, which involves hundreds of companies: among the applicants are Google with .browser, OpenAI with .openai and .chatgpt, Meta with .facebook, and the Italian company Aruba with domains such as .pec, .vps, .lab, .roma and .ciao. All applications remain subject to evaluation.
The delicate point is that .lan is not a name like any other. Many technicians have used it for a long time, for example nas.lan, router.lan or camera.lan. If a name considered internal enters the public DNS, the risk is malfunctions, DNS queries leaving the network, and communications that could reach destinations other than the intended ones.
As someone who is fond of home networks, I find the news a good reminder: for internal names it is better to use suffixes designed for that purpose rather than relying on de facto conventions. For now there is no decision, but it is worth keeping an eye on.
Source: IlSoftware.it
Korben revisits a Cloudflare command that many developers already use: cloudflared tunnel --url. It publishes a server running on your machine at a trycloudflare.com address, with no account, no domain name, and above all no port to open on your router. For someone hosting services at home, it is a simple way to show a project to someone for a quick test.
The newest addition is the --allowed-mail option. Until now, anyone with the link could connect to the service. Now access can be limited to a few email addresses you specify, with a one-time code sent through Cloudflare Access.
The tutorial starts with a small local web server on port 8080, serving a test page via Python. cloudflared is the open source connector that opens an outbound connection to the Cloudflare network. On a Mac, installation goes through Homebrew. On Debian or Ubuntu, you need Cloudflare's official repository, whose signing key recently changed, so the author advises using the current commands rather than those in older tutorials.
One point stood out to me: if you have AI agents work with this tool, Cloudflare recommends a PreToolUse hook that blocks any command lacking --allowed-mail, so that an agent does not expose a public tunnel by mistake.
For a homelab, this is a lightweight alternative to opening ports or running a VPN, as long as you remember that a public tunnel is still an exposure to the Internet, even a temporary one.
Source: Korben
