Synopsis #
A maintainable home server is an arrangement of failure boundaries, not a list of packages. The host owns hardware, storage, networking, updates, and backups. Jails or virtual machines isolate workloads. Each service owns explicit data, ports, credentials, and a recovery procedure.
This planning guide establishes those boundaries before a media server, file share, DNS service, reverse proxy, monitoring stack, or other application is installed.
Start with requirements #
Record the workloads and classify each one:
| Question | Why it matters |
|---|---|
| Must the service be reachable from the Internet? | Public exposure changes firewall, authentication, update, and monitoring requirements. |
| Does it require Linux-only kernel facilities? | A FreeBSD jail and Linux binary compatibility do not supply cgroups or Linux namespaces. |
| Where is its durable data? | The answer defines dataset, backup, quota, and restore boundaries. |
| Can it be stopped for a snapshot? | Stateful applications may need consistency hooks. |
| What is the recovery-time requirement? | It determines whether configuration, datasets, or a whole VM must be replicated. |
| Which other service must it trust? | Hidden dependencies make isolated recovery fail. |
Discard workloads that cannot be maintained with available time, hardware, or recovery access.
Separate host and service responsibilities #
Keep the host small. It normally owns:
- FreeBSD base-system maintenance;
- pool and filesystem administration;
- bridges, routing, firewall, and time;
- jail or VM lifecycle;
- backup transport and monitoring.
Run application stacks in jails when they fit the FreeBSD kernel and need process, filesystem, and network separation. Use bhyve when a workload needs another kernel or a stronger machine-shaped boundary. Use jail or bhyve to select that boundary, then see Create a first jail with Bastille for one managed-jail starting point.
Give data an explicit home #
Design datasets or filesystems from lifecycle rather than application fashion. A useful service data boundary has:
- a documented mount point;
- owner and permission policy;
- quota or capacity alert;
- snapshot schedule;
- independent replication target;
- restore procedure.
Configuration and data may need different retention. Large reproducible media caches should not crowd out irreplaceable documents or database snapshots.
The filesystem and storage-layout guide separates availability from backup. The ZFS replication guide covers an independent remote copy.
Make exposure explicit #
For every listening socket, record:
- owning service and jail or VM;
- interface and address;
- transport and port;
- intended client network;
- firewall rule or reverse-proxy route;
- TLS and authentication boundary;
- log and health signal.
Do not expose an administrative interface merely because the application binds to all addresses by default. Prefer a private service network and publish only the required entry point.
Use Publish a network service safely as the shared lifecycle checklist before following an application-specific installation procedure.
Choose file sharing by clients #
NFS fits trusted UNIX-like clients and preserves familiar UID/GID semantics when identity is coordinated. SMB through Samba fits Windows, macOS, and mixed-client networks. Neither protocol should be exposed directly to the public Internet.
A file-sharing dataset should not also become an unrestricted application-data mount. Separate human shares from service-internal state so permissions and restore operations remain understandable.
Use Choose NFS or Samba for file sharing to make the client identity, authentication, and permission decision before exporting a dataset.
Define the maintenance calendar #
Schedule and monitor:
- supported-release and security-advisory review;
- base-system and package updates;
- jail or VM update windows;
- snapshots, replication, and retention;
- ZFS scrubs and pool-health checks;
- certificate renewal;
- restore exercises.
See Update, upgrade, or update packages? before automating commands with different maintenance scopes.
Preserve a recovery order #
A useful recovery document names the order in which the system returns:
- firmware, boot, and host network;
- storage pools and encryption;
- firewall, DNS, and time;
- jail or VM infrastructure;
- service configuration and secrets;
- durable application data;
- reverse proxy and public exposure;
- monitoring and backup schedules.
Test one service restoration without using the production dataset. A backup inventory alone does not prove that dependencies, ownership, and application state can be reconstructed.