Skip to content

Sunnydale — Homelab Infrastructure

Self-hosted infrastructure environment focused on security, modularity, and reproducibility.


Overview

Sunnydale is a self-hosted homelab environment built to:

  • Host internal services securely
  • Provide controlled remote access
  • Experiment with infrastructure design and deployment workflows
  • Act as a foundation for future expansion (Sunnydale v2 / clustering)

Design Principles

  • Stateless OS, persistent data separation
  • Container-first architecture (Docker)
  • Network segmentation and least-privilege access
  • LAN/VPN-only exposure (no public surface)
  • Reproducible deployments via Compose
  • Structured filesystem (/srv)

System Information

Component Value
Host Raspberry Pi 4 (8GB)
OS Ubuntu Server 24.04 LTS
Hostname sunnydale
Local Domain .sds
LAN IP 192.168.0.20

Network Architecture

Subnets

Network Range Purpose
LAN 192.168.0.0/24 Local devices
VPN (WireGuard) 10.8.0.0/24 Remote access
Docker 10.20.0.0/16 Container networking

Diagrams

Network Diagram


Security Model

  • SSH key-only authentication (root disabled)
  • UFW firewall with subnet-based allow rules
  • Fail2Ban enabled
  • Services restricted to LAN/VPN access only
  • Reverse proxy access control (Nginx)
  • Regular updates via unattended-upgrades

Core Services

DNS

  • Pi-hole v6
  • DNSSEC enabled
  • Upstream: Quad9 (filtered ECS)

VPN

  • WireGuard
  • Subnet routing enabled
  • Peer-based access (laptop, mobile)

Reverse Proxy

  • Nginx (Docker)
  • Internal routing via .sds domains

File Sync

  • Syncthing
  • Proxied via Nginx (sync.sds)

Container Architecture

  • Docker CE + Compose v2
  • Centralised under /srv/services/
  • Networks:
  • sds_proxy (external routing)
  • sds_inet (internal services)

Structure

/srv/  
├── services/  
│   ├── appdata/  
│   ├── logs/  
│   ├── stacks/  
│   └── secrets/  
├── host/  
├── scripts/  
└── notes/

Automation & Operations

  • Custom startup sequencing for containers
  • Ensures reverse proxy availability before services
  • Delayed reload strategy to avoid race conditions
  • Structured logging (/srv/services/logs)
  • Manual + planned backup strategy

Firewall (UFW Summary)

  • Default deny incoming / allow outgoing
  • SSH restricted to LAN + VPN
  • HTTP/HTTPS restricted to LAN + VPN + Docker subnet
  • DNS restricted by subnet
  • Service-specific rules (Syncthing, etc.)

Monitoring & Observability (Planned)

  • Uptime monitoring (Uptime Kuma → alternatives under review)
  • Future integration with Grafana stack

Known Limitations

  • No full HTTPS automation (planned via step-ca)
  • ARM constraints (performance / compatibility)
  • Manual orchestration in some areas

Sunnydale v2 (Planned Migration)

  • Move to x86 server architecture
  • Replace Pi-hole with AdGuard
  • Implement internal PKI (step-ca)
  • Expand service stack:
  • Nextcloud (cloud.sds)
  • Searxng (library.sds)
  • Evaluate K3s for clustering

Key Learnings

  • Importance of service startup ordering in container environments
  • Practical network segmentation for homelabs
  • DNS as a core dependency for internal infrastructure
  • Trade-offs between simplicity vs automation
  • Value of structured documentation for reproducibility

  • [[Sunnydale – Phase 1]]
  • [[Sunnydale – Phase 2]]
  • [[Sunnydale – Phase 3]]
  • [[Networking – Masterlist]]
  • [[Docker – Templates]]

Tags

homelab docker networking linux self-hosting cybersecurity