truenas-stacks/docs/planning/PD_FUTURE_STATE_ARCHITECTURE.md

PD Future-State Architecture Plan

Status: proposed target state for the next major PD rebuild and Serenity retirement.

Goal

Turn PD into the long-term primary homelab platform while keeping enough separation for resilience and cybersecurity lab work.

This plan assumes:

• PD is rebuilt on the HL15 Beast ASRock platform
• Serenity is temporary and will be retired after its storage is adopted into PD
• John will add a second HDD ZFS pool using 5-6 new 20TB+ drives
• A few SSDs may be added for appdata, databases, scratch, and cache tiers
• Cybersecurity VMs may live on PD, but only inside a tightly segmented lab lane

Recommended platform model

Keep PD on bare-metal TrueNAS Scale

Recommended role:

• primary NAS
• primary production Docker/app host
• primary shared database host
• primary media host
• primary identity/control-plane host
• primary DNS source node
• primary AI host if the 4090 lands here
• limited, disciplined VM host for cybersecurity lab work

Do not treat PD as an unrestricted cyber range. Production remains the first-class role.

Hardware direction

Minimum build worth doing

• HL15 Beast ASRock build
• EPYC 7282
• 64GB RAM
• RM1000x if no 4090 is going in immediately

Preferred long-term build

• HL15 Beast ASRock build
• EPYC 7452
• 128GB RAM preferred if PD will carry production plus multiple security VMs
• HX1500i if PD is likely to receive the 4090

Why the base model is not recommended

The 7252 + 16GB base build is too small for the intended role once PD becomes:

• primary ZFS host
• primary app host
• primary DB host
• future ARR/qbit host after pool migration
• possible AI host
• bounded cybersecurity VM host

Storage model

HDD pools

PD should end up with at least two major HDD-backed data classes:

1. Imported Serenity capacity

• absorb the current Serenity storage role
• preserve large media/archive capacity

2. New HDD ZFS pool

• 5-6 x 20TB+ drives
• use for future bulk media, archives, backup targets, and growth

Exact vdev shape should be chosen when the final drive count is locked, but the high-level operating model should be:

• one bulk pool for high-capacity household data
• one or more fast SSD-backed tiers for apps, DBs, and VM-heavy workloads

SSD / NVMe role split

Use SSD/NVMe for:

• Docker root
• shared PostgreSQL / MariaDB / Redis data
• write-heavy appdata
• VM disks for cyber lab systems
• AI model cache
• transcode/temp/scratch

Use HDD pools for:

• media libraries
• document archives
• backups
• long-term storage
• lower-IO datasets

Host role layout

PD = production core

PD should eventually own:

• ZFS/NAS duties
• production Docker stack
• shared databases
• media stack
• household/productivity stack
• Authentik / identity stack
• monitoring/control plane
• primary Technitium node
• ARR/qbit stack after storage cutover
• AI primary if the 4090 lands here
• controlled cyber lab VMs

N.O.M.A.D. = secondary trusted platform

Keep NOMAD for:

• offline knowledge / Project NOMAD
• game servers
• backup Technitium resolver
• small bounded utility workloads

NOMAD should not become a second general-purpose production host.

Rocinante = optional AI specialist

If PD gets the 4090:

• Rocinante becomes optional
• can remain an overflow / experimental inference box
• can later be repurposed or retired

If PD does not get the 4090:

• Rocinante stays the heavy inference box
• PD remains the production/NAS core

Serenity = transition-only

Near-term:

• current storage owner
• current torrent locality host
• current reranker host
• backup Technitium node

End-state:

• storage role moved into PD
• remaining services drained or moved
• host retired

Service placement target

Keep on PD long-term

Infrastructure / control plane:

• Gitea
• Homepage
• Uptime Kuma
• Gotify
• RackPeek
• Traefik / Pangolin-side internal ingress
• Authentik
• shared PostgreSQL / MariaDB / Redis
• monitoring stack

Household / productivity:

• Paperless
• Immich
• Karakeep
• n8n
• KitchenOwl
• DoneTick
• Qui

Media / library:

• Plex
• Tautulli
• Audiobookshelf
• Calibre-Web
• Seerr
• RomM
• GameVault
• Wizarr
• Shelfmark
• Notifiarr

AI / search:

• LiteLLM
• OpenWebUI
• Qdrant
• SearXNG
• Ollama light tier
• primary heavy inference too if the 4090 lands on PD
• reranker after Serenity is retired

Torrent/media ingestion after storage cutover:

• qBittorrent
• qbit_manage
• Gluetun
• unpackerr
• Sonarr / Sonarr-anime
• Radarr
• Lidarr
• Readarr / Readarr-epub
• Prowlarr
• Bazarr
• autobrr

Keep off PD long-term

NOMAD:

• Project NOMAD stack
• Pelican / Wings / game servers
• backup Technitium resolver

Optional elsewhere:

• heavy inference on Rocinante if PD does not get the 4090
• high-risk security experiments on a future dedicated lab node if the school/lab workload outgrows PD-hosted segmented VMs

Cybersecurity VM model on PD

This is acceptable on PD

• Windows Server / AD lab VMs
• Windows client VMs
• Linux practice VMs
• Wazuh / SIEM learning stack
• Kali or similar coursework boxes
• isolated vulnerable targets for coursework
• patch/test environments

This should remain tightly bounded

• scanning labs
• IDS/packet-capture experiments
• exploit practice
• intentionally vulnerable targets

These may run on PD only when:

• placed on a dedicated lab VLAN
• firewalled from production by default
• resource-limited
• treated as disposable

This should ideally not live on PD

• malware detonation
• unknown or sketchy offensive tooling
• random public PoCs with unclear trust
• anything that could meaningfully threaten production storage or family services

Network / VLAN recommendation for the lab lane

Create or preserve a dedicated lab/security lane with these rules:

• separate VLAN / subnet from production lanes
• default-deny from lab to production
• allow only explicit admin paths from trusted management devices
• allow outbound internet as needed for updates/labs
• allow tightly scoped DNS/NTP/logging paths
• keep identity trust boundaries explicit rather than automatic

Suggested policy posture:

• Lab -> PD production apps: deny by default
• Lab -> shared DNS: allow
• Lab -> internet: allow with logging
• Trusted admin devices -> lab: explicit allow
• Lab -> management interfaces: explicit deny unless specifically required

Phased roadmap

Phase 1: document and reduce Serenity sprawl now

• document current host roles and future-state design
• classify Serenity services into keep / move / retire
• move low-risk non-storage-tied apps off Serenity first

Phase 2: build upgraded PD

• install TrueNAS Scale on the new PD hardware
• stand up SSD tiers for apps/DBs/VMs
• add the new HDD pool
• validate networking, Docker, GPU, and backup posture

Phase 3: move production services into the new PD layout

• migrate any remaining general-purpose apps off Serenity
• relocate databases/appdata onto the intended SSD tier
• validate ingress, monitoring, and DNS roles

Phase 4: move the storage-dependent torrent/media automation stack

• after the storage move design is finalized, move qbit + ARR locality to PD
• keep path locality on the box that owns the disks
• then remove the old Serenity-locality requirement

Phase 5: move or redesign the remaining special cases

• move reranker onto PD if AI core lands there
• redesign backup DNS so Serenity is no longer required
• preserve at least one off-PD Technitium node on NOMAD

Phase 6: retire Serenity

• verify pool adoption is complete
• verify services are drained
• confirm backups and DNS redundancy still work
• power down and retire Serenity

Architecture principles

1. PD becomes the production center of gravity.
2. NOMAD stays a separate trusted failure domain.
3. Rocinante is optional and should justify its existence.
4. Serenity should be designed out of the future state.
5. The cybersecurity lab lane can share PD hardware, but not PD trust boundaries.
6. Production stability beats hypervisor sprawl.

Immediate implications for current cleanup work

For the current Serenity Docker review, the guiding rule is:

• remove obvious sprawl from Serenity now
• do not over-optimize the final placement around Serenity permanence
• remember that once PD directly owns the storage, the qbit/ARR locality argument flips to PD