Guide
7 min read

Moving From Cloud to Homelab? Draw the Compute and Storage Boundaries First

Leaving rented cloud for self-hosted gear is exciting until you're staring at a NAS, a DAS, and a Proxmox box wondering what goes where. A decision tree for compute and storage boundaries before apps move home.

Moving From Cloud to Homelab? Draw the Compute and Storage Boundaries First

Leaving rented cloud for hardware you own is one of self-hosting's great satisfactions — right up until the boxes arrive and you're standing over a NAS, a DAS enclosure, and a Proxmox mini-server with no plan for what runs where. People who skip this step end up rebuilding a month later when the database they put on the NAS corrupts or the Proxmox box runs out of room. Draw the compute and storage boundaries before apps move home, and the migration is a one-time setup instead of a recurring redo.

Why the boundaries matter more at home than in the cloud

In the cloud, the provider hid these decisions — block storage "just worked," compute and storage were already separated. At home, you make those calls explicitly, and the wrong ones bite. The two boundaries that matter:

  • Compute boundary — what runs where (which VM, which container, which host).
  • Storage boundary — what data lives on fast local disk vs the bulk pool vs the network share.

Get these right and everything downstream is calm.

The storage boundary: fast state vs bulk data

The single most important rule, and the one cloud migrants most often miss:

  • App state (databases, configs, indexes) → fast local SSD/NVMe on the box that runs the app. Latency-sensitive and intolerant of the disk disappearing.
  • Bulk data (media, archives, backups) → the NAS or DAS pool. Throughput-oriented, tolerant of network latency.

Putting a database on a NAS share is the classic cloud-migrant mistake — it works until the NAS naps and the database corrupts, exactly the storage-split lesson and the USB-DAS guardrails.

The compute boundary: VMs, containers, and one owner per disk

On Proxmox, decide deliberately:

  • VM vs LXC per workload (lighter LXC for most services; VMs for isolation or a storage appliance).
  • One owner per physical disk — don't let Proxmox ZFS and a TrueNAS VM both claim the same drives. The full reasoning is in a sane Proxmox storage plan.

A quick decision tree

  • Database / app state? → fast SSD on the compute box. Never the NAS.
  • Media / large files? → NAS or DAS bulk pool.
  • Needs the GPU (media transcoding, AI)? → the box with the GPU, passed through persistently.
  • Public-facing and needs uptime? → consider keeping that one piece on a small cloud VPS, since home power/internet have outages.

Don't forget the boundary the cloud was handling: access

The cloud gave you a public IP. Home likely gives you CGNAT and no inbound port. Sort remote access as part of the migration, not after.

ServerCompass cloud-to-low-cost migration illustration Mapping the move in ServerCompass — deciding compute and storage boundaries before apps leave the cloud, so the homelab is built once.

Migration checklist

  • App state on fast SSD; bulk data on NAS/DAS — never databases on the NAS.
  • VM vs LXC chosen per workload; one owner per disk.
  • GPU workloads on the GPU box, passed through persistently.
  • Public/uptime-critical pieces considered for a small cloud VPS.
  • Remote access (CGNAT) planned as part of the move.

Takeaway

The cloud was quietly making your compute and storage boundaries for you. Bringing apps home means drawing them yourself — state on fast disk, bulk on the pool, one owner per disk, and a plan for access past CGNAT. Decide the boundaries first and the homelab gets built once, not rebuilt after the first corruption.

homelab
cloud-migration
proxmox
storage
architecture

From across the StoicSoft network

Hand-curated reads on the same topic from sister sites in the StoicSoft family.

Keep reading

Guide
7 min

Planning a First Proxmox Server That Bundles Media, Photos, Backups, and Logging

First-time Proxmox builds now try to do everything at once — Jellyfin, Immich, backups, and monitoring on one box. A planning order that keeps that ambition from collapsing under itself.

Guide
8 min

Proxmox and NAS rebuilds need storage ownership decisions before the apps move

Several fresh homelab posts are really asking the same preflight question: who owns storage when the server is rebuilt? One Proxmox user is reinstalling across three SSDs before hosting OPNsense, Vaultwarden, Omada, Pi-hole, VPN, and other services. Another…

Guide

Your First Proxmox VM Can Wait: Get DNS, DHCP, Console Access, and Storage Right First

Most first-time Proxmox pain has nothing to do with VMs. It is a host that cannot resolve names, an IP that moves on the next reboot, no way back in when the web UI is down, and VM disks dumped on the wrong storage. Fix those four layers before you create a single VM.

Guide
7 min

Running Your Router in a VM? Check These Failure Modes Before Apps Depend on It

Virtualizing OPNsense on the same Proxmox box that runs your apps is elegant until a host reboot takes the whole network — including your way back in — down with it. The failure modes to plan for.

Guide
7 min

Multi-Terabyte Media Libraries Need a Tiered Backup Policy, Not All-or-Nothing

You back up app state religiously and freeze on the photo and media library — too big to replicate, too precious to lose. A tiered policy: what gets full backup, what gets cold storage, what gets re-ripped.

Guide
6 min

Proxmox Migrations Need Confidence Checks for Host Crashes and Storage Latency

Moving VMs and containers between Proxmox hosts works in the demo and bites in production — a crash mid-migration, latency that corrupts, a cluster that won't quorum. The checks that de-risk it.