State: In use Role: Pi-hole DNS + Tailscale DNS/subnet-routing node Model: Raspberry Pi 3 Model B Rev 1.2 Operation: Always on Hostname:private / internal Administrative account: omitted from public copy Network: Private LAN SSH Alias:ssh <pi3-alias>
Hardware
Component
Specification
Model
Raspberry Pi 3 Model B Rev 1.2
Architecture
ARM
Primary Role
DNS / private-network infrastructure
Network
Ethernet
Operating Pattern
24/7 lightweight infrastructure
The Pi 3 is intentionally kept focused on lightweight networking responsibilities rather than application hosting.
SSH Access
SSH is configured for public-key authentication.
Password-based SSH access is disabled.
Normal Windows Login
From Windows PowerShell:
ssh <pi3-alias>
The Windows SSH alias should resolve to:
Host: <private Pi 3 host>
Administrative account: <omitted>
Key: <SSH_KEY_FILE>
Windows SSH config:
Host <pi3-alias>
HostName <private Pi 3 host>
User <admin-user>
IdentityFile <SSH_KEY_FILE>
IdentitiesOnly yes
Direct login without the alias:
ssh -i <SSH_KEY_FILE> <admin-user>@<private Pi 3 host>
Authorized Key Location
On the Pi 3:
<AUTHORIZED_KEYS_FILE>
The existing Windows public key is already authorized on the Pi 3.
Important SSH Notes
The correct Linux account is:
<private-hostname>
not:
<incorrect-account>
Using the wrong account results in:
Permission denied (publickey)
even when the SSH key itself is valid.
Host-Key Recovery
If the Pi is rebuilt or its SSH host keys legitimately change, Windows may display:
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
After verifying that the device really is the Pi 3, remove the stale Windows host-key entry with:
ssh-keygen -R <private Pi 3 host>
Then reconnect:
ssh <pi3-alias>
Accept the new fingerprint only when the change is expected.
Making private homelab services reachable remotely
The Pi 3 is part of the private remote-access design rather than exposing internal services directly to the public Internet.
Remote DNS Behavior
When a personal device such as the iPhone is connected through Tailscale and using the Pi 3 DNS configuration, internal hostnames can continue working while away from home.
Example:
iPhone on 5G
↓
Tailscale
↓
Pi 3 DNS
↓
↓
<private management host>
↓
NPM
↓
This allows the same friendly internal URLs to work both:
At home on Wi-Fi
Away from home through Tailscale
without publicly exposing the backend service.
Jellyfin DNS Behavior
The Pi 3 DNS setup allows the user's own Jellyfin traffic to take the direct/private route when appropriate.
At Home
iPhone on home Wi-Fi
↓
Pi 3 DNS
↓
<private Jellyfin host>
↓
VM100 / Jellyfin
Jellyfin activity confirmed a local iPhone address such as:
<private local client>
This demonstrated that the session was using the local LAN path rather than hairpinning through the public VPS.
Away From Home
With Tailscale enabled, the iPhone can use its private Tailscale path instead.
Observed example:
<private remote Tailscale client>
The network path and Jellyfin playback mode are separate concepts:
Direct network path
≠
Jellyfin Direct Play
A session can use the direct/private network route while Jellyfin still decides to transcode the media.
Relationship With Raspberry Pi 5
The two Raspberry Pis have different infrastructure roles.
Primary always-on Raspberry Pi node for website hosting, monitoring, private services, and homelab infrastructure.
Status
State: In use Role: Always-on infrastructure / Docker node Hostname:private / internal Administrative account: omitted from public copy Network: Private LAN SSH Alias: ssh <pi5-alias>
Hardware
Component
Specification
Model
Raspberry Pi 5
Memory
16 GB RAM
Primary Storage
1 TB NVMe
Operating System
Raspberry Pi OS / Debian-based Linux
Primary Workload
Docker services and infrastructure
Network
Gigabit Ethernet
The Pi 5 boots and runs its primary operating system from the 1 TB NVMe.
Current Role
The Raspberry Pi 5 is one of the primary always-on infrastructure nodes in the homelab.
State: Planned / Present-Soon Build Role: NAS + virtualization + application compute Operation: Intended for 24/7 use Platform: AMD AM5 Memory Type: Non-ECC for the current build
Hardware
Component
Planned Hardware
CPU
AMD Ryzen 9 9950X
Memory
64 GB DDR5 CL40, non-ECC
Motherboard
ASUS Pro WS B850M-ACE SE
Case
JONSBO N6 NAS Case
PSU
ASUS ROG Loki SFX-L 850W Platinum
GPU
Intel Arc B580
CPU Cooling
240 mm AIO
Case Fans
2× Noctua NF-A12x25 G2 PWM chromax.Black
NVMe #1
Samsung 9100 2 TB
NVMe #2
Samsung 9100 2 TB
HDD Storage
4× Seagate IronWolf Pro 8 TB
Hypervisor
Proxmox VE
Storage Platform
TrueNAS planned for bulk-storage management
Already Owned
Current core hardware already available for the build includes:
AMD Ryzen 9 9950X
64 GB DDR5 CL40 memory
An existing:
Samsung 970 EVO Plus 1 TB
was previously considered for the system but is intended to be replaced by the two Samsung 9100 2 TB NVMe drives for the main storage layout.
Storage Architecture
NVMe Tier
Two separate Samsung 9100 2 TB NVMe drives are planned.
They are not intended to be mirrored together.
NVMe #1
Primary roles:
Proxmox operating system
Critical services
Important VM/application storage
Fast infrastructure workloads
NVMe #2
Primary roles:
Fast application data
Databases
Metadata
Cache
Active game-server world files
Transcoding workspace
Frequently accessed working files
Conceptually:
Samsung 9100 2 TB #1
├── Proxmox
├── Critical services
└── Important application storage
Samsung 9100 2 TB #2
├── Databases
├── Metadata
├── Cache
├── Transcode workspace
├── Active game worlds
└── Fast working data
HDD Storage
Bulk storage is currently planned as:
4 × Seagate IronWolf Pro 8 TB
Drive characteristics:
NAS-class HDD
CMR
7200 RPM
Intended for 24/7 storage workloads
HDD Pool Layout
The four drives will be organized as two mirrored pairs.
Actual displayed usable space will be lower after:
TB vs TiB conversion
Filesystem overhead
ZFS metadata
Reserved/free-space considerations
Why Mirrors
The mirror-based layout was chosen for a balance of:
Redundancy
Good read performance
Straightforward drive replacement
Reasonable resiliency
Better random-I/O behavior than a single large parity layout
A single drive can fail within each mirror without immediately losing that mirror's data.
This does not replace backups.
Planned Data Placement
HDD Pool
Bulk/persistent data belongs primarily on the HDD storage pool.
Examples:
Immich photo originals
Jellyfin / Plex media libraries
Completed video recordings
Persistent game-server data
Archives
Local backups
Large media files
NVMe Fast Tier
Performance-sensitive data belongs on NVMe.
Examples:
Application databases
Metadata
Thumbnails
Transcode/cache data
Active game worlds
Frequently modified application data
Immich
The system is planned to eventually host Immich as a personal photo-management platform.
Primary goal:
Replace dependence on iCloud Photos with personally controlled storage.
Planned layout:
Immich originals
↓
HDD pool
Database
Thumbnails
Cache
↓
NVMe fast tier
At least approximately:
1 TB+
should be available for the initial photo library with room to grow.
Media Services
The NAS / compute system will eventually become the primary home for heavier media workloads.
Bulk media belongs on the HDD pool:
Movies
TV
Anime
Recordings
Other media
↓
HDD pool
Performance-sensitive application data remains on NVMe.
The Intel Arc B580 will provide a dedicated GPU resource for workloads that can benefit from hardware video acceleration and other supported compute tasks.
Intel Arc B580
The current GPU plan is:
Intel Arc B580
This replaces the earlier planned:
NVIDIA GeForce RTX 3060 Ti
The 3060 Ti should therefore be treated as an obsolete build-plan item for this machine.
Potential B580 roles include:
Hardware-accelerated media processing
Transcoding
GPU-assisted workloads
Future experimentation
Exact passthrough/container assignment can be decided when the system is built.
Virtualization Role
The system is intended to run:
Proxmox VE
and eventually take over many of the heavier workloads currently hosted by: