Bare-metal home lab build for multi-account at scale

Running multi-account operations on cloud VPS gets expensive fast. once you’re managing 50+ accounts with dedicated browser profiles, rotating proxies, and persistent sessions, the monthly VPS bill starts eating your margin in a way that makes the whole operation hard to justify. i moved my core stack to bare-metal at home about two years ago and the unit economics changed completely.

this guide is for operators who are already running multi-account workflows, understand why account isolation matters, and want to stop paying recurring cloud compute costs for workloads they can own outright. if you’re just starting out and running fewer than ten accounts, a VPS setup is probably fine. but if you’re at the point where compute is a real cost line, bare-metal is worth the upfront spend.

by the end of this tutorial you’ll have a Proxmox-based hypervisor running segmented VMs per account cluster, with VLAN-isolated network paths and a proxy routing layer baked in. this is the foundation i use for running parallel browser sessions across multiple platforms without fingerprint or network bleed between accounts.

what you need

hardware - a mini PC or repurposed workstation with at least 8 cores and 32GB RAM. i use a refurbished Dell OptiPlex 7060 SFF (around SGD 350-450 on Carousell or eBay) as the hypervisor host. Intel NUC 12/13 generation machines also work well if you want lower power draw - a managed switch that supports 802.1Q VLAN tagging. i use a TP-Link TL-SG108E (around SGD 50-70). unmanaged switches will not work for this setup - at least one USB NIC or a dual-port NIC in the host for separating management traffic from guest traffic - a 500GB+ SSD for the hypervisor OS and VM storage. NVMe preferred

software and accounts - Proxmox VE (free, open source hypervisor) - Ubuntu Server 24.04 LTS for guest VMs - your existing antidetect browser licenses (Adspower, Multilogin, etc.) - a residential or mobile proxy pool, either self-scraped or purchased

estimated upfront cost: SGD 500-900 for the hardware depending on what you source. ongoing cost is electricity, roughly SGD 15-30/month depending on idle power draw and local rates.

skills required: comfortable with Linux CLI, basic networking concepts (IP subnets, VLANs), and running a browser profile manager at the command line.

step by step

step 1: install Proxmox VE on the host

download the Proxmox VE ISO from the official site and flash it to a USB drive with Rufus or dd.

dd if=proxmox-ve_8.x-1.iso of=/dev/sdX bs=4M status=progress

boot from the USB, follow the installer. set the management IP to something static on your home LAN, e.g. 192.168.1.10/24. after install, access the web UI at https://192.168.1.10:8006.

expected output: Proxmox dashboard loads. you’ll see a warning about no valid subscription, which you can dismiss. the free version has all features you need.

if it breaks: if the installer hangs at boot, disable secure boot in BIOS. if the web UI doesn’t load, check that your firewall isn’t blocking port 8006.

step 2: configure VLANs on the managed switch

log into your TP-Link (or equivalent) switch web UI. create one VLAN per account cluster. a reasonable starting structure:

VLAN 10: management (Proxmox host access only)
VLAN 20: account cluster A
VLAN 30: account cluster B
VLAN 40: proxy routing VM

tag the port connected to your Proxmox host as trunk (all VLANs). tag each downstream port with only the VLAN it needs. this is the core of your isolation, traffic from cluster A physically cannot reach cluster B at the switch layer.

if it breaks: if VMs can still ping each other across clusters after VLAN setup, confirm the Proxmox bridge is set to VLAN-aware mode (step 3) and that the switch port is truly tagged, not access-mode.

step 3: create a VLAN-aware Linux bridge in Proxmox

in the Proxmox web UI, go to your node, then “System > Network”. edit vmbr0 and check “VLAN aware”. apply the change and reload networking.

# on the Proxmox host via SSH
systemctl restart networking

now when you create a VM and assign it to vmbr0 with a VLAN tag of 20, it will only see traffic on VLAN 20. the Linux kernel VLAN implementation handles the tagging at the bridge level, so you don’t need anything special in the guest OS.

expected output: after restart, ip link show should show vmbr0 and sub-interfaces for each active VLAN tag once VMs are running.

if it breaks: if networking drops after the restart, access the host console directly (not SSH) and check /etc/network/interfaces for syntax errors.

step 4: create a base Ubuntu Server VM template

in Proxmox, upload the Ubuntu Server 24.04 ISO to local storage. create a new VM with: - 2 vCPUs, 4GB RAM for browser profile VMs - 40GB disk (thin-provisioned) - network: vmbr0, VLAN tag matching the cluster you’re building

install Ubuntu Server with minimal packages. then install your antidetect browser or browser automation tooling:

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl wget unzip xvfb
# install Adspower agent or your browser manager here

once the base VM is configured, convert it to a Proxmox template: right-click the VM in the UI and select “Convert to template”. from here you can clone it in seconds.

expected output: cloning the template creates a new VM in under 30 seconds with linked clone (shares the base disk, only writes diffs).

if it breaks: if clones fail to boot, confirm the template VM was fully shut down before converting.

step 5: deploy a proxy routing VM on VLAN 40

this VM acts as the gateway for each cluster’s outbound traffic. i run a lightweight Debian VM here with tinyproxy or 3proxy configured to forward to your upstream residential proxy pool.

sudo apt install -y 3proxy

configure /etc/3proxy/3proxy.cfg to accept connections from the cluster VLAN (e.g. 192.168.20.0/24) and forward them to your upstream proxy. set each cluster to use a different upstream proxy sub-pool so account clusters never share an exit IP.

the proxy routing VM sits on two VLANs: VLAN 40 (its own management) and the cluster VLAN it serves. set static routes so cluster VMs default-route through this VM.

if it breaks: if cluster VMs can’t reach the internet, check ip route on both the proxy VM and the cluster VMs. confirm IP forwarding is enabled on the proxy VM: sysctl net.ipv4.ip_forward should return 1.

step 6: clone and configure browser profile VMs per account

for each batch of accounts, clone the template VM from step 4, assign it to the correct cluster VLAN, and configure it to route through the cluster’s proxy VM.

# set proxy env vars in ~/.bashrc on each VM
export http_proxy="http://192.168.20.254:3128"
export https_proxy="http://192.168.20.254:3128"

launch your antidetect browser profiles from here. each VM gets its own IP (from the VLAN subnet), its own browser fingerprint set, and its own proxy chain. accounts in VLAN 20 are completely isolated from accounts in VLAN 30 at the network, compute, and storage layer.

for teams running airdrop farming workflows, the antidetect browser review roundup at antidetectreview.org has useful comparisons of which browser managers handle VM-based deployments well vs. which ones assume a Windows GUI environment.

if it breaks: if browser profiles fail to launch headlessly, install xvfb and prefix your launch command with xvfb-run -a.

step 7: set up snapshots and backup rotation

before you populate accounts, snapshot each base VM. in Proxmox:

# via CLI on Proxmox host
qm snapshot <vmid> clean-base --description "pre-account snapshot"

set up Proxmox Backup Server (PBS) or a simple rsync job to push VM disk images to a NAS or external drive nightly. losing a populated account VM without a backup is painful.

if it breaks: if snapshots fail with “lock” errors, a previous operation left the VM in a locked state. run qm unlock <vmid> to clear it.

step 8: harden and document

disable SSH password auth on all VMs, use key-based access only. lock down the Proxmox web UI to management VLAN only via the built-in firewall. document your VLAN-to-cluster mapping in a simple spreadsheet, things get confusing fast at 50+ VMs.

if it breaks: if you lose SSH access after hardening, use the Proxmox console (noVNC in the web UI) to fix /etc/ssh/sshd_config.

common pitfalls

skipping VLAN isolation early. operators often start with a flat network and plan to add VLANs later. adding VLANs retroactively means reconfiguring running VMs and re-IP-ing subnets. do it right from VM 1.

undersizing RAM. browser profiles are memory-hungry. four Chrome-based profiles per VM at 4GB RAM is tight. if you’re seeing swap activity, add RAM to the host before adding more VMs.

using a single proxy pool for all clusters. if your proxy provider rotates IPs and two clusters share the same pool, you’ll eventually get IP overlap between account groups. segment proxy sub-users or sub-pools by VLAN.

no snapshot discipline. bare-metal means no cloud-snapshot button. operators who skip snapshots lose hours of work when a platform bans an account cluster and they need to roll back to a clean state.

ignoring power and thermals. a mini PC running 8 VMs at 80% CPU will throttle if airflow is bad. i learned this the hard way when a SFF PC in a closed cabinet caused thermal shutdowns. keep hardware in open air or in a proper rack shelf.

scaling this

10x (50 accounts, ~10 VMs): the setup above handles this easily on a single host. you’ll want a second SSD for VM storage to avoid IO contention.

100x (500 accounts, ~50-100 VMs): one host won’t cut it. add a second or third node to your Proxmox cluster. Proxmox supports clustering natively, VMs can live-migrate between nodes. at this point, a proper 1U rack server (Dell R430/R630, around SGD 800-1500 refurbished) is worth it over mini PCs, the density per dollar is better. your proxy budget also increases significantly; at this scale look at proxyscraping.org for options on self-building vs. buying residential pools.

1000x (5000+ accounts): you’re now running a small data center. you need IPAM (IP address management), automated VM provisioning via Proxmox API or Terraform, centralized logging, and dedicated ops time. the home lab architecture holds, but you need automation around every manual step above. Proxmox’s REST API exposes full VM lifecycle management, cloning, snapshotting, network config, which is what you’ll script against.

the network architecture also changes at 1000x. VLANs on a single managed switch top out around 4094 VLANs, and you’ll hit practical limits earlier. look at VXLANs for overlay networks across multiple physical switches.

where to go next

how to set up residential proxy rotation for multi-account, covering proxy sub-user segmentation and rotation strategies that pair with this lab build
antidetect browser profile setup and automation, which goes deeper on headless and semi-headless browser configurations in Linux VM environments
browse the full tutorial index at /blog/ for the rest of the stack-setup series

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-05-22.