Skip to content
DnsLister Forum

Where domain hunters compare notes

Title: Planning my long-term homelab / NAS: old laptop now, storage + proper hardware later. Looking for feedback on the overall plan

Title: Building “Jarvis”: my long-term homelab / NAS plan. Old laptop today, full self-hosted ecosystem tomorrow. Looking for feedback before I buy hardware.

Hi everyone,

I’m building my first serious homelab project, which I call Jarvis.

The goal is not just to build a NAS or a media server. Long term, I want Jarvis to become my private home computing platform for:

  • media
  • remote development
  • files and documents
  • music and DJ workflows
  • gaming
  • photos
  • home automation
  • monitoring
  • backups
  • eventually my own unified Jarvis interface and assistant

I’m deliberately starting small with hardware I already own, because I want to understand what I actually use before spending a lot of money.

I’d love feedback on both the software architecture and, especially, how you would evolve the hardware.

Current hardware

Right now everything runs on an old:

HP ENVY x360

Specs:

  • Intel Core i7-8550U
  • 4 cores / 8 threads
  • Intel UHD integrated graphics
  • around 12 GB RAM
  • Samsung 256 GB NVMe
  • Gigabit Ethernet
  • Debian 13
  • hostname: nas-hub

This is obviously not the final machine.

The idea is to use this laptop as the first Jarvis node, learn Docker/Linux properly, validate all my workflows, and only then buy storage and better hardware.

Current base stack

Already installed and running:

  • Debian 13
  • SSH
  • Docker
  • Docker Compose
  • Portainer
  • Tailscale
  • Jellyfin
  • Gluetun
  • Proton VPN
  • qBittorrent
  • Prowlarr
  • Radarr
  • Sonarr

Docker Compose is intended to remain the real infrastructure source of truth.

Portainer is mainly there as a convenient admin UI.

1. Media Hub

This is the first big use case.

Already installed

  • Jellyfin
  • Gluetun
  • Proton VPN
  • qBittorrent
  • Prowlarr
  • Radarr
  • Sonarr

Planned

  • Bazarr
  • Seerr
  • TRaSH based quality profiles
  • automatic movie workflow
  • automatic series workflow
  • hardlinks
  • atomic moves
  • notifications
  • remote access through Tailscale

The target flow is basically:

Phone -> Seerr -> Radarr / Sonarr -> Prowlarr -> qBittorrent -> Gluetun -> Proton VPN -> downloads -> hardlink/import -> media library -> Bazarr -> Jellyfin -> TV 

Jellyfin already has access to Intel VA-API, although I still want to validate real hardware transcoding under load.

Optional later

These are not automatic installs. They are things I want to evaluate only if I actually encounter the relevant need:

  • Unpackerr
  • FlareSolverr
  • PixelProbe
  • Pinchflat
  • qBittorrent Search
  • JellyBridge or similar integrations
  • Pushover for notifications

I’m deliberately not installing every media-related container I find.

2. Homelab visibility

Once Media is working properly, I want a very small monitoring layer.

Planned:

  • Uptime Kuma
  • Dozzle
  • Homepage

Uptime Kuma answers:

“Does the service actually respond?”

Dozzle gives me easy access to Docker logs.

Homepage will act as a temporary “Jarvis V0” dashboard while I learn what information and shortcuts I really use.

I’m intentionally not starting with Grafana, Loki, Alloy, Prometheus, etc.

Maybe later, but not just because they look cool.

3. AI / Development Hub

This is probably one of my biggest reasons for building Jarvis.

I use Claude Code heavily and I would like to stop keeping my main PC powered on just because my development environment is there.

The goal is to eventually have:

Mac / work computer / phone -> private remote connection -> NAS development environment -> VS Code Claude Code Git tests commit push 

Planned

  • dedicated isolated Linux dev user
  • /srv/dev/projects
  • Git
  • Node
  • npm / pnpm
  • Python
  • tmux
  • VS Code Remote Tunnel
  • Claude Code

The dev user will intentionally have limited permissions.

It should not automatically have:

  • sudo
  • Docker socket access
  • NAS admin access
  • appdata access
  • media access
  • photo access
  • VPN administration

I want Claude Code to be useful without effectively giving an AI agent root access to my house.

Later, depending on usage

  • code-server
  • Gitea
  • targeted Syncthing for projects
  • Cloudflare Tunnel + Access
  • Trilium
  • Claude-Trilium sync
  • Guacamole

The real validation test for this Hub will be:

main PC powered off, complete a real development task remotely through the NAS, test it, commit it and push it.

4. Personal Cloud and Documents

The goal here is to start replacing fragmented cloud storage and build a proper personal digital vault.

Planned

  • SMB
  • Syncthing
  • Syncthing versioning
  • Paperless-ngx

SMB for normal network shares.

Syncthing for selected synchronization between machines.

Paperless-ngx for:

  • invoices
  • warranties
  • contracts
  • administrative documents
  • scanned documents
  • PDFs

Optional later

  • Paperless-GPT
  • Karakeep
  • MicroBin

I want to keep a clear distinction between:

  • file sharing
  • synchronization
  • versioning
  • backup

because they are not the same thing.

5. Music / DJ Hub

I also produce electronic music and DJ.

Jarvis will eventually become my main music vault without automatically touching my active Engine DJ database.

Planned storage structure includes things like:

music/ incoming/ dj-master/ archive/ edits/ acapellas/ samples/ productions/ engine-backups/ 

New music would go through an incoming workflow before becoming part of the DJ master library.

Planned:

  • central music library
  • production project storage
  • exports
  • stems
  • masters
  • samples
  • Engine DJ backups
  • selected Syncthing workflows

The important rule is that Jarvis must not automatically rewrite the active Engine DJ database.

The expected workflow remains:

NAS -> computer -> Engine DJ -> USB / SD -> SC LIVE 4 

Candidate

  • Navidrome

I like the idea of self-hosted music streaming, but Navidrome is still something to evaluate rather than a guaranteed install.

6. Gaming Hub

I want Jarvis to become a gaming vault too.

Planned

  • game saves
  • save synchronization
  • save versioning
  • restore previous saves
  • ROM library
  • RomM
  • mods archive
  • screenshots
  • video captures

The first useful feature will probably be game saves through Syncthing with versioning.

The important test will be deliberately modifying or corrupting a test save and successfully restoring an older version.

RomM would handle my legally owned retro library with metadata and a web interface.

I also want structured mod archives by game/version.

Later

Private game servers, but only when there is an actual game I want to host.

I do not want to host five servers I never use.

Not currently planned

LanCache.

It requires a lot of storage and I haven’t demonstrated that it would actually be useful for me.

7. My own Jarvis Control Center

Eventually I want to build my own frontend.

Not just another grid of Docker containers.

The goal is to have one interface for:

  • Media
  • Development
  • Cloud
  • Music
  • Gaming
  • Home
  • System

For example:

JARVIS MEDIA Jellyfin Seerr DEV VS Code Gitea CLOUD Syncthing Paperless SYSTEM CPU RAM Temperature Storage VPN Service health 

But normal daily usage and administration should be separated.

Normal mode could expose:

  • Media
  • Files
  • Dev
  • Music
  • Gaming

Advanced/admin mode could expose:

  • Portainer
  • logs
  • Uptime Kuma
  • storage
  • restart actions
  • shutdown
  • diagnostics

Jarvis should also be able to display useful states like:

  • Proton VPN connected
  • qBittorrent protected
  • service offline
  • storage almost full
  • backup failed
  • SMART warning
  • temperature problem

Dangerous actions should require confirmation.

The frontend will never get direct access to /var/run/docker.sock.

I would build a limited backend API instead.

I also want it to eventually be installable as a PWA on my phone.

The end goal is that I naturally open Jarvis instead of remembering 15 different URLs.

8. Future storage hardware

This is where I expect to spend real money.

I am deliberately postponing the purchase until I have actual usage numbers.

My current likely direction is:

Laptop -> USB -> multi-bay DAS -> HDDs 

A 4-bay DAS is currently one of the strongest candidates, but it is not decided yet.

Before buying drives I want to understand my actual growth in:

  • movies
  • series
  • development projects
  • gaming
  • music
  • documents
  • future photos

When I buy HDDs I plan to compare:

  • price per TB
  • CMR
  • capacity
  • warranty
  • noise
  • power consumption
  • new vs refurbished

I also want to verify the DAS itself for:

  • USB stability
  • SMART passthrough
  • noise
  • power management
  • capacity limits
  • future expansion

Filesystem / storage design

Still deliberately undecided.

Main candidates:

  • ZFS
  • mergerFS + SnapRAID

I want to decide only after I know:

  • number of drives
  • DAS behaviour
  • available RAM
  • type of data
  • expansion requirements
  • USB behaviour

The internal laptop SSD would likely remain for:

  • Debian
  • Docker
  • appdata

Large HDD storage would contain:

  • media
  • photos
  • music
  • gaming
  • archives
  • other heavy data

One reason I’m trying to keep container paths clean is so that moving the physical storage later doesn’t require completely reconfiguring every application.

9. Backups

Long term I want proper backup separation.

For important data:

  • documents
  • photos
  • projects
  • music productions
  • configs
  • critical DJ data

I want:

  • primary NAS copy
  • independent secondary storage
  • off-site copy for selected data

Backblaze B2 is currently part of the plan for some irreplaceable data.

The long-term goal is a real 3-2-1 strategy for important files.

I do not plan to upload dozens of terabytes of replaceable movies to B2.

And I’m treating RAID/parity and backup as two completely different things.

10. Photo Cloud

Once proper HDD storage and backup exist:

  • Immich

Planned workflow:

Android phone -> NAS -> Immich 

Important design rule:

Immich will not be the only place the original photos exist.

I want separate backups for:

  • original photos
  • Immich database
  • configuration

And the Photo Cloud will not be considered finished until I successfully perform a restore test.

Later

  • Immich Drop

11. Smart Home and Home Network

Planned eventually:

  • Home Assistant
  • Pi-hole

I want Home Assistant to start from the devices I actually own, not from an imaginary fully automated house.

My current apartment has some limitations:

  • manual crank shutters
  • collective heating

So shutter automation would require a real retrofit/motorisation project.

Heating control would probably be limited to smart thermostatic valves if the radiators allow it.

Pi-hole is planned as local DNS filtering for part of the advertising/tracking traffic on the home network.

I’m also interested in future local vision experiments, but not as part of the first Home Assistant deployment.

Energy monitoring

I also want to measure actual power consumption.

A Tapo P110 or similar device is planned to compare things like:

  • main PC vs NAS
  • NAS idle
  • streaming
  • transcoding
  • development workloads

I’m interested in knowing whether the “always-on low-power server” idea actually saves meaningful energy in my real usage.

12. Mature Homelab phase

Once the useful services exist, I want to stop adding random software and focus on reliability.

Planned:

  • expanded Uptime Kuma monitoring
  • Dozzle
  • Healthchecks for scheduled jobs
  • log rotation
  • controlled updates
  • appdata backups
  • disaster recovery documentation
  • actual restoration drills
  • Wake-on-LAN
  • clean shutdown
  • power consumption tracking
  • security audits
  • documentation

For updates, I prefer:

backup -> update -> test -> rollback if needed 

rather than blind automatic Watchtower updates.

For disaster recovery, my target is eventually something like:

SSD dies -> install Debian -> install Docker -> restore Compose -> restore appdata -> mount storage -> docker compose up -> Jarvis returns 

And I want to actually test restoring at least one application.

13. Jarvis V2

Only much later, when the current machine is no longer enough:

  • new server hardware
  • possibly separate compute and storage
  • GPU
  • local AI
  • Ollama
  • Open WebUI
  • voice assistant
  • advanced local vision
  • multiple nodes
  • possible high availability
  • advanced reverse proxy
  • more advanced monitoring

I’m intentionally not trying to run big local LLMs on the i7-8550U laptop.

Hardware evolution

So the likely hardware evolution is something like:

Today

HP ENVY x360 i7-8550U ~12 GB RAM 256 GB NVMe 

Next major purchase

multi-bay DAS + large HDDs + independent backup storage 

Later, only if justified

dedicated server / compute hardware + possibly GPU + potential separation of storage and compute 

I’m trying very hard not to buy hardware before the software and usage justify it.

What I’d love feedback on

This is where I’d really appreciate advice from people who have already built something similar.

  1. Would you keep using this laptop until it becomes a real limitation, or would you replace it earlier?
  2. Would you trust a good multi-bay USB DAS for this project, or would you move directly to a machine with native SATA / HBA support?
  3. For this eventual software stack, how much RAM would you realistically target?
  4. Would you keep everything on one machine initially, or are there parts you would definitely separate?
  5. Does separating future compute from storage make sense for this kind of home setup?
  6. ZFS vs mergerFS + SnapRAID for mostly media + personal data + photos: what would you lean toward and why?
  7. Anything important missing from the software stack?
  8. Anything on this list that sounds useful in theory but that you found pointless in practice?
  9. Would you change the order in which I’m building this?
  10. What hardware purchase would you make first if you were in my position?

I know the plan is ambitious, but I’m not trying to install everything tomorrow.

The main rule of the project is:

Build one part, understand it, test it, actually use it, fix the problems, then move on.

I want Jarvis to grow over several years rather than turn into 70 containers after one weekend.

Curious to hear what you’d change before I start spending serious money.

Source: r/homelab · by /u/Skuniz

Leave a Reply

Your email address will not be published. Required fields are marked *