The hardware claim is broadly sound. A 2019-era PC with an SSD, a stable Ethernet connection, and 8GB of RAM has ample headroom for a small Docker host running lightweight web services. The condition omitted by the “any old PC” framing is software support: Windows 10 Home and Pro reached end of support on October 14, 2025. Microsoft’s lifecycle documentation says those editions no longer receive security updates, so repurposing an unpatched Windows 10 machine as an always-on server—especially one exposed beyond the home network—turns a recycling project into a security liability.
For most retired Windows PCs, a supported Linux distribution and Docker Compose make the cleanest base. Docker’s own documentation supports Engine installations across mainstream Debian, Ubuntu, Fedora, and RHEL-family releases, while Compose keeps each service’s configuration, persistent storage, and update procedure in a readable file. That is more useful for a beginner than installing every application directly on the host, because removing or rebuilding one container need not erase its data—provided the data lives in a deliberately configured volume or bind mount.
Start with services that cannot break the household network
How-To Geek’s list opens with Pi-hole, the DNS filtering service that blocks selected ad, tracking, and malicious domains before connected devices reach them. It is a compelling first project because it makes an immediate difference on devices where browser extensions are unavailable or ineffective, including many TVs, streaming boxes, and IoT products.
It is also the one project here most likely to cause a family-wide outage if it is treated casually. A Pi-hole host needs a static local IP address, and the router’s DHCP configuration must advertise that address as DNS to client devices. If the machine is shut down, its disk fails, or its container does not return after an update, devices configured to use it may lose name resolution even though the internet connection itself is fine.
Pi-hole’s Docker documentation reflects that system role: its standard configuration exposes both TCP and UDP port 53 for DNS, alongside the web interface, and preserves configuration under /etc/pihole. Its interface documentation also distinguishes between listening only to local subnets and broader exposure. A beginner should keep the DNS service restricted to the LAN, avoid forwarding port 53 from the router to the public internet, and record the existing router DNS settings before making any change.
The practical trial run is narrower than turning over every device at once. Point one test PC or a guest network at Pi-hole first, verify ordinary browsing, streaming, local printer discovery, and any work VPN access, then change the router’s DHCP DNS setting. Do not add a public DNS resolver as a “secondary” option on clients merely to retain internet access; clients may choose it and bypass filtering entirely.
DNS filtering also has a clear boundary. It can prevent a device from connecting to a known advertising or tracking domain, but it cannot reliably remove advertising served from the same domain as the content, nor can it inspect encrypted traffic without much more intrusive infrastructure. That makes Pi-hole useful network hygiene, not a universal ad blocker.
Vaultwarden demands production-grade habits
Vaultwarden is the outlier in this lineup because a mistake does not merely interrupt a dashboard or delay an RSS refresh. It can put a user’s password vault, attachments, and recovery path at risk. The project is a Rust implementation compatible with Bitwarden clients, so the official Bitwarden browser extensions and mobile or desktop apps can generally connect to it. That compatibility is valuable, but it does not make Vaultwarden a service operated, supported, or recovered by Bitwarden.
The Vaultwarden project’s own configuration template and hardening guidance make the requirements clear. A public deployment should use HTTPS, preferably through a reverse proxy; the web vault needs a secure context for browser cryptography. Its documentation also advises securing the administrator token with an Argon2 hash, disabling open registration after the first account exists, and disabling password hints on publicly accessible instances.
The bigger issue is backups. A container restart is routine; losing the database, encryption-related files, attachments, or the master password is a different class of failure. Docker volumes persist container data, but persistence on the same aging hard drive is not a backup. Vaultwarden’s own project guidance continues to treat the persistent data directory as essential even when an external database is used.
For a first self-hosting weekend, run Vaultwarden only on the local network and prove a restore before importing a real vault. Export an encrypted backup from the client, back up the server’s persistent Vaultwarden data to a separate device, and confirm that a second device can sign in after a test restore. If remote access is necessary, use a VPN-based approach rather than exposing the management interface or relying on a hastily assembled public reverse proxy.
That is not an argument against Vaultwarden. It is an argument for recognizing that a password manager is a production service from its first stored credential. The machine can be old; the operational standard cannot be.
Syncthing is synchronization, not a backup plan
Syncthing is a more forgiving project and arguably the best first service for Windows users who have a desktop, laptop, and phone with files that need to stay aligned. It exchanges data directly between approved devices, using device identities and encrypted connections instead of putting a third-party cloud account in the middle. An always-on PC can act as the reliable node that receives a change while another device is offline, then passes it along once that device reconnects.
How-To Geek correctly describes the practical benefit: a home server can provide continuity when two intermittently used machines are never online at the same time. Syncthing’s documentation also covers relays, versioning, and encrypted “untrusted” devices, which are useful options once the basic setup is working.
The important correction is that sync is not backup. If a document is deleted or corrupted on one trusted device, synchronization can propagate that change to the others. Enable folder versioning where appropriate, keep an independent backup copy, and share folders as receive-only on devices meant to act as archives. Those choices matter more than the host’s memory footprint.
For sensitive data stored on a node that should not see plaintext—for example, a rented server or a less-trusted machine—Syncthing documents an untrusted-device encryption mode. It hides file contents and much of the metadata from that device, although the project warns that the feature remains beta/testing and that some information, such as approximate file sizes and change activity, can still be exposed. An old PC inside the home does not need that complexity; ordinary trusted-device synchronization is the appropriate starting point.
FreshRSS teaches the value of owning a quiet service
FreshRSS is the least risky of the six projects and the closest thing here to a no-drama first deployment. The software gives users a web-based RSS reader without asking a recommendation system to decide which posts, videos, or updates deserve attention. It can aggregate traditional feeds and offer API access for compatible reader apps.
The project’s official prerequisites explicitly say its requirements are low enough for old computers, though a conventional installation still needs a web server, PHP, and a database choice. Its maintainers document Docker as the easiest supported installation route, which makes it a particularly good candidate for a Compose-based home server.
FreshRSS is useful because it teaches several core self-hosting lessons with limited downside: map persistent data, keep a local-only web interface, update an image, and restore a configuration backup. If it stops working, the consequence is missed reading—not a broken network or inaccessible passwords. That is the right failure mode for a novice.
It also has a less obvious value on a Windows-focused desk: it can replace the habit of opening dozens of tabs for Microsoft release-health notices, security advisories, developer blogs, and product news. RSS does not solve the problem of verifying information, but it restores chronological control over what enters the reader’s queue.
Uptime Kuma and Homepage belong after the first services work
Uptime Kuma and Homepage are support tools, not core infrastructure. Uptime Kuma can check HTTP, TCP, DNS, ping, container, and other endpoint types, then deliver alerts through email, Discord, Telegram, ntfy, and numerous other notification services. Its repository’s Docker example persists /app/data, a detail worth copying rather than assuming the monitoring history lives forever inside a container.
Its limitation is equally important: a local monitor running on the same old PC as every service cannot tell you that the PC itself has died. It can detect that Pi-hole’s web interface is down while the host remains running; it cannot send an alert after a power failure unless a separate external monitor or another device notices the absence. Use it for service checks first, then add an outside-in monitor only if remote availability actually matters.
Homepage earns its place once IP addresses and port numbers become hard to remember. The project documents YAML-based service definitions, Docker container statistics, optional automatic discovery through labels, and integrations with many self-hosted applications. It is a convenient front door, though it should not be mistaken for monitoring or access control.
A dashboard can also become an unnecessary exposure point if its links and integrations reveal administrative services. Keep Homepage on the LAN, store API keys outside shared configuration where possible, and avoid publishing it to the internet merely to make local bookmarks prettier.
The best use of an old PC is therefore incremental: install a supported host OS, give it a reserved IP address, deploy FreshRSS or Syncthing, learn persistent storage and backups, then add Pi-hole. Bring in Uptime Kuma after there is something worth monitoring, and Homepage after there are enough services to justify it. Vaultwarden should come only when its backup and recovery process is more trustworthy than the drawer where the old PC spent the last several years.