back

Homelab Server

Overview of current status, services, and hardware of my homelab.

Current Status Snapshot

This page tracks the current operating baseline for my homelab. The goal is to keep it useful for routine maintenance and future upgrades, not just as a project summary.

  • Host model: repurposed old laptops running multiple self-hosted services.
  • Workload style: container-first with Docker, managed through Portainer.
  • Access model: LAN-only services with WireGuard for remote administration.
  • Priority services: media, files, passwords, and document archival.
  • Current risk profile: limited redundancy and partial backup coverage.
  • Improvement focus: stronger backup validation, clearer monitoring, and network hardening.

Services

Docker and Portainer

  • Purpose: run and manage the service stack consistently.
  • Access: Portainer UI on internal network only.
  • Persistence: named volumes and bind mounts for service data.
  • Current note: standardizing compose files and environment variable management is still in progress.

WireGuard

  • Purpose: secure remote access into the homelab without exposing admin interfaces publicly.
  • Access: VPN endpoint with trusted client peers.
  • Persistence: peer keys and configuration files stored with server config backups.
  • Current note: tightening peer lifecycle management and documenting key rotation intervals.

Jellyfin

  • Purpose: personal media server for local and remote streaming.
  • Access: internal network directly, remote access through VPN.
  • Persistence: media library on bulk storage and metadata on service volume.
  • Current note: library organization and metadata consistency still need cleanup.

Nextcloud

  • Purpose: private file sync and sharing across devices.
  • Access: internal URL and VPN path for remote usage.
  • Persistence: user data and database volumes on persistent storage.
  • Current note: improving update cadence and validating restore steps after major upgrades.

Vaultwarden

  • Purpose: lightweight password manager hosting for personal use.
  • Access: restricted to trusted network paths and VPN clients.
  • Persistence: encrypted vault database in persistent volume.
  • Current note: backup frequency is acceptable, but restore testing needs to be scheduled regularly.

Paperless-ngx

  • Purpose: document ingestion, OCR, and searchable archival.
  • Access: internal service endpoint.
  • Persistence: consume directory, originals, and index data on persistent storage.
  • Current note: ingestion workflow is functional, but tagging conventions need standardization.

Hardware

Compute

  • Main nodes: repurposed old laptops handling homelab containers.
  • Rationale: built-in batteries act as simple power backup during short outages.
  • Constraint: limited upgradeability and mixed hardware capabilities across devices.

Storage

  • Tiering: faster storage for container state and slower/larger storage for media and archives.
  • Critical data: passwords, documents, and cloud files are prioritized for backup.
  • Constraint: redundancy and off-site strategy are still being improved.

Network and Power

  • Network role: LAN only for normal access, with VPN as the only remote entry path.
  • Power posture: laptop batteries provide baseline backup without dedicated UPS hardware.
  • Constraint: network segmentation and alerting are still maturing.

Network and Security Basics

  • Exposure model: avoid direct public exposure of admin interfaces.
  • Remote administration: WireGuard is the only remote path.
  • Update policy: patch host OS and container images on a regular cadence.
  • Secrets handling: environment files and service secrets are tracked and kept out of public repos.
  • Hardening direction: reduce open ports, isolate service communication where possible, and document firewall rules.

Backups and Monitoring

Backup Baseline

  • Covered data: service configs, databases, and high-value user data.
  • Destinations: local backup target plus staged path for off-host copies.
  • Current gap: restore drills are not frequent enough to fully trust recovery time targets.

Monitoring Baseline

  • Health checks: service-level checks and container restart policies are in place.
  • Visibility: basic host and service observation exists but alerting depth is limited.
  • Current gap: need centralized metrics and actionable alert thresholds.

Roadmap

When I Have Time

  • Keep service definitions and configs more consistent as things evolve.
  • Improve backup confidence with occasional restore testing.
  • Add light monitoring and alerts where they add clear value.

Longer-Term Ideas

  • Add redundancy for critical data and services when hardware budget allows.
  • Revisit architecture for cleaner separation between core and optional services.
  • Document dependencies and recovery steps to make maintenance easier.