Multi-Node & Private Infrastructure Architecture

Why infrastructure separation matters

Production VPS platforms commonly separate public-facing services from backend hypervisor infrastructure. This reduces attack surface, improves operational control and allows infrastructure to scale more cleanly over time.

• Separate customer-facing ingress from backend nodes
• Reduce direct exposure of hypervisor infrastructure
• Centralise provisioning and lifecycle automation
• Support operational growth across multiple locations
• Improve infrastructure security boundaries

Public ingress vs backend nodes

Many providers operate VMNexor using dedicated frontend systems for customer access while keeping Proxmox hypervisors on private or restricted backend networks.

• Frontend systems may handle HTTPS, APIs and customer traffic
• Backend Proxmox nodes may remain private
• Infrastructure communication can occur over secure private networking
• Customer access can remain isolated from hypervisor management interfaces

Private networking approaches

VMNexor does not require a specific networking technology. Providers may use whichever infrastructure model matches their operational environment.

• Private VLANs
• WireGuard overlays
• GRE or VXLAN networking
• Private datacenter networking
• Dedicated management networks
• Hybrid multi-location routing

Multi-location deployments

VMNexor is designed around infrastructure-aware provisioning workflows suitable for geographically distributed Proxmox environments.

• Provision services to specific locations
• Separate templates by region or node group
• Apply infrastructure-specific provisioning rules
• Scale beyond single-node deployments
• Support regional infrastructure expansion

Shared storage considerations

Providers operating multiple Proxmox nodes commonly standardise template and provisioning workflows across shared storage or replicated environments.

• Shared template repositories
• Centralised ISO management
• Cluster-aware provisioning workflows
• Consistent template availability
• Validation of storage accessibility before provisioning

Console relay routing

VMNexor uses relay-based console workflows to avoid exposing raw Proxmox console interfaces directly to customers.

• Authenticated customer console sessions
• Controlled console routing
• Short-lived access handling
• Controlled console access workflows
• Reduced exposure of backend infrastructure

Proxmox API communication

VMNexor communicates with Proxmox infrastructure using API-driven automation workflows designed around provider-controlled infrastructure management.

• Scoped API authentication
• Infrastructure-aware provisioning actions
• Lifecycle automation
• Template management
• Infrastructure validation workflows

Security boundaries

Infrastructure separation should be combined with operational security controls and production validation procedures.

• Restrict Proxmox management exposure
• Protect API credentials
• Separate customer and infrastructure networks
• Validate relay security configuration
• Review firewall and routing rules regularly

Recommended deployment patterns

VMNexor can be adapted to multiple provider environments ranging from small deployments to larger multi-node infrastructure layouts.

• Single frontend with private backend nodes
• Multi-location Proxmox clusters
• Dedicated provisioning environments
• Separated management infrastructure
• Infrastructure scaling through additional node groups

Production validation checklist

• Provisioning works across all intended nodes
• Console access works through relay infrastructure
• Templates exist on expected storage
• API communication works from VMNexor to all nodes
• Firewall policies match infrastructure design
• Customer traffic remains separated from backend infrastructure