Skip to main content
MyITCyber
Under attack?←Back to home
← Insights·Infrastructure Security

Proxmox in Production: The Work That Starts After the Move

·3 min read
Dark cyan line-art diagram of a Proxmox production cluster. On the left, a cluster card shows three stacked nodes. In the center, two paths leave the cluster: an amber snapshot path that stays on the same storage, marked as not a backup, and a teal backup path that goes to a separate backup target and an offsite copy. On the right, an access card shows a locked management network with MFA. A bottom strip lists four equally weighted controls: MFA, management network, backup, and restore test.

Leaving VMware for Proxmox can be the right financial decision. It is not the finish line. After the last virtual machine lands, you own the hypervisor, the cluster, the backup, and the access path. That is where most of the real work starts.

The cost conversation is usually what starts a move from VMware to Proxmox.

That conversation is valid. We have written about it before. The license bill drops, the platform works, and the business gets a better balance between technology and budget.

Then the last virtual machine lands, and a different question appears.

Who owns the hypervisor now?

On VMware, a lot of operational gravity was already there. Roles, backup integrations, patch discipline, and a familiar way to lock down the management plane. Teams did not always love the price, but they knew the operating model.

Proxmox does not invent that model for you. It gives you a capable cluster. The rest is yours.

This is the part we see skipped.

  • The web UI is reachable from too many networks, sometimes from the internet.
  • Root, or one shared admin account, is how everyone logs in.
  • Snapshots on the same storage are treated as backup.
  • The cluster configuration has no restore plan of its own.
  • Nobody has rehearsed what happens when a node, a datastore, or the whole site is gone.

Production Proxmox needs the same seriousness as production VMware.

  • A dedicated management network. The UI and API are not user services.
  • Named admin accounts, MFA, and a break-glass path that is documented.
  • Backup of virtual machines that is separate from the cluster storage.
  • Backup of the cluster itself: configuration, users, storage mappings, and network.
  • A patch and subscription rhythm so nodes do not quietly drift.
  • A restore test with the people who would do the recovery, not only a green job.

None of this is unique to Proxmox. It is just easier to forget when the project is framed as a cost save.

The migration is a project. Production is a system you have to keep running.

If the cluster is cheaper and nobody can restore it, the organization did not actually save money.

Treat the hypervisor like the critical system it now is. Then Proxmox is not only a cheaper platform. It is a platform you can operate.

// related reading
API security with backend validation diagram. On the left, an untrusted client panel showing a browser UI with a hidden DELETE button, a disabled ROLE field, and the URL /api/tickets/42 with the 42 underlined as 'attacker changes this', plus four amber pills indicating client-side manipulation: changed ID, modified payload, direct API call, bypassed UI. Amber arrows representing manipulated requests flow into the right panel, a backend pipeline labeled THE REAL ENFORCER. The pipeline runs each request through six teal gates top to bottom: AUTH (is the user logged in?), AUTHORIZATION (can this user do this action?), OBJECT-LEVEL AUTHZ (can this user access this record?), INPUT VALIDATION (does this payload make sense?), RATE LIMIT (is this request too frequent?), LOG + MONITOR (should this be recorded?), exiting into an APPROVED REQUEST arrow, with a side branch from OBJECT-LEVEL AUTHZ to an amber 403 · DENIED pill, and a callout noting every request is treated as possibly manipulated. Below, a strip of seven equally weighted controls: backend-side validation, object-level authorization, input sanitization, rate limiting, clear error handling, logging plus monitoring, and abuse protection, with a small tag reading 'frontend helps · backend enforces'.
Infrastructure Security

API Security: Do Not Trust the Client

The frontend can hide buttons, disable fields, and guide the user through the right flow, but anything that comes from the client can be changed. Attackers swap IDs in URLs, edit payloads, call the API directly, and bypass the UI completely. Real security lives in the backend: authentication, authorization, object-level access checks, input validation, rate limits, and logging on every request, because every request is treated as possibly manipulated.

Read article
Certificate expiration risk diagram. On the left, a CERTIFICATES EVERYWHERE panel showing ten services that quietly depend on a valid certificate, website, API, VPN, load balancer, mail, internal services, Kubernetes ingress, monitoring, identity, and integrations, with two services (WEBSITE and IDENTITY) flagged in amber as EXPIRES SOON, and a footer pill reading 'all depend on a valid cert'. On the right, an amber-bordered WHEN A CERT EXPIRES panel listing the immediate impact: users cannot log in, APIs fail, browser security warnings appear, automations break, integrations stop, customers lose access, with a footer note 'and all it took was a missed date'. Below, a CERTIFICATE LIFECYCLE strip with seven equally weighted controls: inventory, ownership, expiration monitoring, alerts, renewal process, automation, and post-renewal testing.
Infrastructure Security

Certificate Expiration Is Still Taking Systems Down

An expired certificate is one of the simplest, most preventable outages, and it still keeps happening. The fix is not heroics on renewal day. It is treating certificates like production assets: a real inventory, a clear owner, monitored expirations, alerts, a renewal process, automation where possible, and post-renewal testing so the change does not break something downstream.

Read article
Back to all insights