Proxmox VE in Production — What Running It 24/7 for Over a Year Actually Teaches You

The moment an outage interrupts something you actually use every day, your homelab has stopped behaving like a toy.

That is the cleanest definition of production I know.

I have been running Proxmox VE 24/7 for over a year on my BMAX Pro 8. On paper, it is still a homelab box. In practice, Plex, Nextcloud, and Home Assistant all depend on it staying healthy. That changes the standard immediately. You stop caring about how quickly you can spin up a VM and start caring about how calmly you can recover when something breaks.

Most Proxmox posts online are about installation, upgrade paths, or first impressions. That is useful, and I have already covered the build side in my Proxmox homelab setup on a mini PC guide. What those posts usually skip is the boring middle: the long stable stretches, the one migration that runs far too long, the backup routine you should have tightened earlier, and the network blip that changes how you think about remote access.

After 400+ days, my opinion is simple: Proxmox is excellent, but it rewards boring operators and punishes optimistic ones.

Production in a homelab still means consequences

People get strangely hung up on the word production.

If you are not billing customers, they assume it does not count. I think that misses the point. If a service is part of your normal day, if downtime immediately becomes your problem, and if recovery matters more than screenshots, you are already there.

A home setup does not need a sales team behind it to deserve production habits. It only needs real consequences.

When Plex buffers, someone notices. When Nextcloud disappears, the missing files matter. When Home Assistant falls over, the problem stops being an interesting virtualization issue and starts being a broken part of the day. Those are the same kinds of day-to-day services I wrote about in my self-hosting toolkit, and they are exactly why I no longer treat uptime as a hobby metric.

That is why I no longer judge infrastructure by how clever it looks. I judge it by how easy it is to understand when I am tired. Fancy is cheap. Recoverable is expensive.

Lesson 1: Storage migrations are where confidence goes to die

A fresh Proxmox install makes storage look neat and tidy. Local disks here. VM disks there. Buttons in the web interface. Progress bars. It all feels manageable.

Then you do a real migration on a live box.

One of the clearest lessons from this past year came from moving a VM disk between local datastores on the mini PC. On paper it was a routine reshuffle. In practice it ran for hours, and while it ran, the whole box crawled. Plex playback stuttered. Nextcloud got sluggish. The migration was saturating the machine's own disk IO, and every other service was standing in the same queue.

That is the part people underestimate on a single-node homelab. A storage move is not a copy that happens quietly in the background — it is an IO-bound operation that competes directly with everything your services need. If the guest is busy dirtying memory while it moves, the tail end drags even longer. And if your Proxmox system disk is something cheap and slow, that one weakness drags the entire host down with it. A storage migration is not housekeeping once the system is busy. It is an operational event, and it belongs in a maintenance window.

This is where new homelab thinking usually goes wrong. You treat storage moves like rearranging folders on a laptop. Proxmox treats them like large, stateful operations touching the thing your services are standing on.

The teacher version is simple: moving a VM disk sounds like changing seats in a classroom. It is not. It is more like moving the entire classroom while the lesson is still running.

What changed for me after that long move?

• I stopped doing storage work casually.
• I started assuming every simple move would take longer than I wanted.
• I became much more suspicious of doing anything big during the hours when the services were actually in use.

That sounds obvious. It is obvious. The problem is that you only really believe it after one migration ruins your evening.

Lesson 2: Backups do not mature by themselves

For a while, backups in a homelab often exist as a good intention.

You know they matter. You mean to tighten them up. You tell yourself the current setup is fine for now.

It usually is not.

My backup strategy evolved from manual vzdump jobs to automated Proxmox Backup Server with retention policies. The real improvement was not the acronym. It was moving from "I should make a backup tonight" to scheduled, deduplicated backups that ran whether I was organised or not.

Manual backups feel responsible because they produce files. Manual anything has the same weakness: it depends on you being awake, consistent, and not distracted by ten other jobs. That works for a week. It does not work for a year.

What PBS changed was the shape of the problem. Instead of wondering whether I had remembered to capture a fresh state, I had a backup system with a schedule, retention, and an actual operational rhythm behind it. The policy is boring on purpose: a daily job at 2 AM, retention set to keep seven daily, four weekly, and six monthly snapshots, so I always have a recent restore point without the datastore growing forever. If you want the vendor view, the Proxmox Backup Server documentation is worth bookmarking because it makes the retention and datastore model much clearer than trial and error ever will.

One habit matters more than the schedule itself: a weekly verify job, so PBS actually checks the backups are readable rather than just present. I will be honest about the one I do not keep — I have never sat down and tested a full restore. I have never needed to, which is either luck or a quiet risk I keep meaning to close, because a backup you have never restored is a hope, not a backup. One rule I do follow without exception: the backups do not live on the same physical disk as the VMs. If that disk dies, I do not want it taking the backups with it.

Once the box started carrying important services, I stopped thinking about backups as insurance and started thinking about them as part of the service itself. If the restore path is weak, the service is weak. That is it.

This is also where Proxmox teaches the same lesson every good sysadmin eventually learns: boring automation beats heroic memory.

Lesson 3: The network is the part you forget until it bites

Every long-running setup has one moment that changes how you think about it.

For me it was a brief network blip that, for a few minutes, cut me off from the box entirely. Nothing was on fire. The services kept running locally. But the reverse proxy in front of everything, the tunnel I use to reach it from outside the house, and my remote management were all suddenly unreachable at once. On a single-node homelab, that is the quiet risk nobody warns you about: the network path to your box is a single point, and when it wobbles, you lose the ability to see or fix anything precisely when you most want to.

The network is not a side topic. It is the topic.

I teach computer science, and this is the bit textbooks often flatten too much. On paper, a network is a tidy diagram with arrows. In practice, it is the one dependency sitting underneath every other dependency. When it drops, the dashboard that would tell you what is wrong is on the far side of the thing that is wrong.

That blip made me much less casual about the phrase "just a brief network issue." Brief for whom? The link that recovers on its own in thirty seconds, or you, standing in a coffee shop unable to reach a single service until it does? It also made me plan for it: a way in that does not depend on the one path that just failed, and notes stored somewhere other than the machine I am trying to reach.

The practical rules I would write down on day one

This is the section I wish more Proxmox posts included.

Not philosophy. Operating rules.

If I were setting up the same box again with the same requirement that these services need to stay dependable, I would write down this checklist on day one:

• A real maintenance window for any storage move, not "whenever I get time tonight."
• A PBS backup job on a schedule with a written retention policy — mine keeps seven daily, four weekly, and six monthly.
• Backups on a different physical disk from the VMs, so one dead drive cannot take both.
• A restore-test habit — the one I still owe myself — because successful backups do not prove successful recovery.
• Alerts that reach me before I stumble into a problem: disk usage crossing 80%, failed backup jobs, and offline services.
• A second way to reach the box that does not depend on the one network path that just failed.
• Clear notes stored outside the Proxmox host, so recovery steps do not disappear with the machine you are trying to recover.
• A power plan: UPS and a graceful shutdown, or at least a decision made on purpose instead of by accident.

None of that is glamorous. That is exactly why it matters.

The romantic version of self-hosting is building the thing. The grown-up version is keeping it boring six months later.

What 400 days actually teaches you

Running Proxmox for a weekend tells you whether the install worked.

Running it 24/7 for over a year tells you whether your habits work.

Proxmox itself has been solid. The harder lessons came from operations: storage work takes longer than you think, backup maturity does not happen by accident, the network path to your box deserves more respect than the dashboard encourages, and small shortcuts become large problems once the box matters.

So yes, you can run Proxmox VE in production.

The better question is whether you are ready to run it like boring, dependable infrastructure. That is the standard that matters.