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

Proxmox VE

  • Purpose: hypervisor for running virtual machines and containers.
  • Access: internal network only.

Tailscale and Nginx Proxy Manager

  • Purpose: manage network connectivity and reverse proxying for internal services.
  • Access: internal network and Tailscale VPN for remote access.
  • Current note: Tailscale replaced WireGuard due to limited access to router configuration, disallowing port forwarding and VPS hosting.

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. Setup to shutdown on 50% battery to avoid data loss. Auto restart on power restoration is enabled.
  • 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.