Twenty Years of Self-Hosting: Why u/jc-21 Keeps a Small Homelab

A useful home lab has a rhythm. The household services work, the owner knows where the important data lives, and an experiment can wait until the people using the network have finished their day. That is the kind of progress we wanted to hear about when inviting the community to share its Self-Hosting Day stories.

In u/jc-21’s contribution, roughly twenty years of experimentation lead back to a deliberately small Linux-based setup. The commenter describes a FriendlyWrt router, a Raspberry Pi 5 for daily services including AdGuard and Nginx Proxy Manager, and a NAS for heavier or less ARM-friendly workloads such as Plex. Small machines and networking equipment sit on a UPS. The author also identifies as Nginx Proxy Manager’s creator, linking a personal need for simpler access to an open-source project.

The Architecture Upgrade Is a Clearer Division of Responsibilities

From ZimaSpace’s perspective, the transferable idea is the separation of responsibilities. A daily-service core needs a different maintenance routine from a machine used for storage experiments or demanding applications. Once those roles are visible, hardware decisions become easier to explain: what must remain available, what needs more capacity, and what can be restarted without interrupting someone else’s work?

Begin with dependencies rather than the list of containers. An application may be running correctly while its users cannot reach it because a name no longer resolves or the chosen access path is unavailable. Write a short map from a user action to the services that support it. That map can be a page of notes. Its value comes from explaining the system accurately enough that maintenance stops being a guessing exercise.

A Practical Planning Map for a Small Home Lab

Put the Daily Core on a Predictable Maintenance Schedule

A small always-on tier becomes useful when its behavior is predictable. Give each essential service a named owner, a known configuration location and a way to confirm that it is actually doing its job. For a DNS service, that means checking a representative lookup from a client. For a household application, it means opening the application through the route people normally use. A healthy process indicator is only one part of that check.

Keep changes modest enough to reverse. Record the current application version and preserve the configuration before an update. Choose a maintenance window that fits the people using the system, then check the ordinary client experience afterward. These are operating habits a small installation can adopt without creating an elaborate management platform. The useful measure is how confidently the owner can explain and recover a change.

A Reverse Proxy Deserves Its Own Place in the Service Map

Nginx Proxy Manager’s official project documentation describes a graphical approach to proxy hosts and certificate management. That makes it a useful illustration of a service whose configuration connects several other applications. Keep a record of which hostname leads to which destination, where the application itself stores data and which account controls access.

A convenient proxy interface does not remove the need to understand the application behind it. Review each route as a complete path: client, name, proxy, destination and application account. Decide deliberately which routes belong on the local network or through a private remote-access path. If an application moves to another machine, update that map and test the saved address from a real client before declaring the migration finished.

Plan Power and Recovery Around the Services People Notice

An outage plan should explain what remains useful when one part of the system stops. Identify the devices needed to keep that path working, including relevant networking equipment, rather than counting only the server. If using a UPS, measure the actual connected load and test the intended shutdown behavior. Runtime depends on the battery, load and configuration; it should be established for the installation rather than assumed from a device’s size.

Keep recovery instructions available somewhere other than the service they explain. A network diagram stored only behind a failed login service is awkward at precisely the wrong moment. Retain an accessible copy of important notes, a documented route to the backup and a procedure for bringing the system back in a sensible order. This makes an ordinary household interruption easier to handle without converting every failure into an evening of rediscovery.

Where ZimaCube 2 Fits When the Data Layer Grows

For readers adopting a similar division of work, a ZimaCube 2 personal cloud NAS can provide the shared data layer alongside an existing daily-service machine. This is our hardware-planning suggestion: the community contribution describes a different installation. Put retained media, project files and application records in clearly managed locations, and decide which clients and services need access to each area.

ZimaCube 2’s drive bays and M.2 expansion options give a growing collection room to be planned around different storage roles. Size the configuration for the data retained, the services actually running and the independent backup you intend to maintain. Moving data to a larger enclosure does not require moving every household service at the same time. A staged handoff keeps the current system understandable while the storage role develops.

Make the Next Upgrade a Handoff You Can Explain

Choose one collection or application record for a pilot migration. Preserve its current location, copy it to the proposed destination and verify access through the intended client. Document any path or account changes, then restore a sample from the backup into a separate location. A completed transfer is more convincing when another person can find the same information and understand which copy is authoritative.

Leave the system with a short handoff note: daily services, shared storage, recovery copy and the changes still being tested. For a deeper virtualization example, our ZimaBoard 2 Proxmox community build shows another way to organize a growing lab. The goal is the same kind of clarity: a system that remains useful while its owner keeps learning.

FAQ

How do I decide which services belong on the always-on machine?

Start with what the household notices when it stops working. In this setup, DNS filtering and the reverse proxy support everyday access, so their update schedule deserves particular care. List the devices and services each one depends on, then check whether restarting another machine would interrupt that path. Put experiments where you can restart them without taking those daily services with them.

Should I move every service to a new NAS at once?

A smaller first move is easier to check. Choose one file collection or application, copy its data and configuration, and verify access from the devices that normally use it. Record changed paths and permissions. Keep the original installation available until the new location and its recovery copy have been checked, then move the next workload if there is a reason to do so.

What should I record for each reverse-proxy host?

Record the public or local hostname, the destination address and port, the application it serves and the location of its saved configuration. Note how users are meant to sign in and whether access should be local or remote. After moving an application, test its usual address from an ordinary client rather than checking only the proxy dashboard.

How much UPS runtime does a small homelab need?

Choose the runtime around the action you want to complete: riding through a brief interruption or shutting equipment down cleanly. Measure the load of the devices you intend to keep powered, including the networking equipment needed to reach them. Test the shutdown procedure under controlled conditions and review the result as the connected equipment or battery condition changes.

Where would ZimaCube 2 fit in a setup like this?

It could take on shared storage and selected applications while the existing small machine continues handling daily services. Decide which files need to move, which clients need access and where the independent backup will live. There is no need to combine every role on one device if the current division of work is serving the household well.

Conclusion

After years of self-hosting, u/jc-21 has kept the lab focused on a few useful roles: a router, a small machine for daily services and a NAS for storage and heavier workloads. That arrangement gives each device a purpose and makes it easier to see what a proposed upgrade would actually improve.

Before adding another machine, write down the service dependencies, save the important configurations and check that the recovery instructions are accessible during an outage. If shared storage is the part that needs to grow, ZimaCube 2 can take that role while the rest of the lab continues working. Move one workload, verify it and build from there.