How to Set Up Your Own Proxmox VE Server

Proxmox VE is one of the most popular ways to run your own virtualisation platform on hardware you control. It is open source under the GNU AGPLv3, free to run in production with no feature gating or VM cap, and it gives you both KVM virtual machines and LXC containers from a single web interface. This tutorial takes a bare-metal server from a blank disk to a working host running one VM and one container.

Prerequisites

Before starting, make sure you have the following:

A bare-metal server with a 64-bit CPU that has hardware virtualisation extensions (Intel VT-x or AMD-V) enabled in BIOS/UEFI. (If you would rather skip the manual ISO install entirely, Proxmox VE is an available deployment image on Serverside — deployed to bare metal in under a minute, with a KVM console and ISO mount if you prefer to install it yourself.)
The Proxmox VE 9.2 installer ISO, proxmox-ve_9.2-1.iso (roughly 1.7 GB), from the official download page
A way to boot that ISO on the server: an IPMI/KVM console with virtual-media mount, or physical access with a USB drive
A public IP address, subnet mask, and gateway for the host, plus a DNS resolver
Basic comfort with the Linux command line and SSH

What we're building

We are setting up a single Proxmox VE node — one physical machine acting as a standalone hypervisor. On top of it we will run two workloads so you see both models Proxmox offers:

One KVM virtual machine (full hardware virtualisation — its own kernel, boots any OS)
One LXC container (a lightweight Linux system container that shares the host kernel)

Everything here works on a single box. Clustering, high availability, and Ceph come later and need at least three nodes — out of scope for a first host.

Step 1: Download the ISO and boot the installer

Download proxmox-ve_9.2-1.iso from the Proxmox download page. Proxmox VE 9.2 was released on 2026-05-21 and is based on Debian 13 "Trixie". Verify the checksum against the one published on the download page before you write it anywhere.

If your server has an IPMI/KVM console (iDRAC, iLO, IPMI, or a web KVM), mount the ISO as virtual media and set the server to boot from it once. On the console you should see the Proxmox boot menu:

Proxmox VE 9.2 (ISO 'proxmox-ve_9.2-1')

  Install Proxmox VE (Graphical)
  Install Proxmox VE (Terminal UI)
  Advanced Options

Choose Install Proxmox VE (Graphical) (or the Terminal UI variant if the KVM console renders graphics poorly). The installer then walks you through a handful of screens:

EULA — accept it.
Target harddisk — pick the disk (or disks) to install onto. Click Options to choose the filesystem. On a single disk, ext4 on LVM is the simple default. If you have two or more disks and want redundancy and snapshots, choose zfs and a RAID level — the installer offers RAID0, RAID1 (mirror), RAID10, RAIDZ-1, RAIDZ-2, and RAIDZ-3, with the available options depending on how many disks you select. A two-disk mirror (RAID1) is a sensible, resilient starting point.
Location and time zone — set your country, time zone, and keyboard layout.
Administration password and email — set a strong root password and a real email address for system notifications.
Network configuration — set the management hostname (an FQDN like pve1.example.com), the host IP address in CIDR form, the gateway, and a DNS server. These become your vmbr0 bridge settings on first boot.

A note on ZFS memory before you commit to it: ZFS uses an in-RAM cache called the ARC. A good rule of thumb is roughly 2 GiB of base RAM plus about 1 GiB of ARC per 1 TiB of pool storage. Since Proxmox VE 8.1, new installs cap the ARC at 10% of installed RAM by default (written to /etc/modprobe.d/zfs.conf), which you can adjust in the installer's Advanced Options. Budget that RAM on top of what your VMs need.

Confirm the summary and let it install. The server reboots into Proxmox VE when it finishes — unmount the virtual media so it boots from disk.

Step 2: First boot and log in

After the reboot, the console prints the URL for the web interface:

Welcome to the Proxmox Virtual Environment. Please use your web browser to
configure this server - connect to:

  https://192.0.2.10:8006/

pve1 login:

Open https://<your-server-ip>:8006 in a browser. The web UI is served by the pveproxy daemon over HTTPS on port 8006. You will get a self-signed certificate warning on a fresh install — accept it to continue. Log in with username root, the password you set during install, and the realm Linux PAM standard authentication (root@pam).

Now connect over SSH so you can run the command-line steps that follow:

ssh [email protected]

Confirm the version and running kernel with pveversion:

root@pve1:~# pveversion
pve-manager/9.2-1/2c8d7f3b (running kernel: 6.14.8-2-pve)

The pve-manager/9.2-1 token confirms you are on 9.2; the kernel token reflects whatever kernel is currently booted. Throughout this guide the host is called pve1 and lives at 192.0.2.10 — substitute your own hostname and addresses.

Please do not reuse the exact IPs, hostnames, or IDs shown here — use your own values.

Step 3: Configure repositories and update

A fresh install points APT at the enterprise repository, which needs a paid subscription key. Without one, apt update fails against it. Proxmox VE is free to run in production, but the free packages come from the no-subscription repository, which you have to enable yourself.

Proxmox VE 9 uses the modern deb822 .sources format under /etc/apt/sources.list.d/ — not the old one-line .list files. First, disable the enterprise repo by adding an Enabled: false line to it. Open /etc/apt/sources.list.d/pve-enterprise.sources and make it look like this:

Types: deb
URIs: https://enterprise.proxmox.com/debian/pve
Suites: trixie
Components: pve-enterprise
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
Enabled: false

Then create the no-subscription repository at /etc/apt/sources.list.d/proxmox.sources:

Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

Suites: trixie is correct because Proxmox VE 9 is built on Debian 13 "Trixie". Do not enable the enterprise and no-subscription repositories at the same time — pick one channel.

A word of caution straight from the Proxmox documentation about the no-subscription repo: "It can be used for testing and non-production use. It's not recommended to use this on production servers, as these packages are not always as heavily tested and validated." For a home lab or staging host it is the standard choice; for a production fleet, a per-socket subscription buys you the more heavily validated enterprise channel plus support.

Now refresh and upgrade:

root@pve1:~# apt update && apt full-upgrade -y
Hit:1 http://download.proxmox.com/debian/pve trixie InRelease
Hit:2 http://deb.debian.org/debian trixie InRelease
Hit:3 http://deb.debian.org/debian trixie-updates InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  proxmox-kernel-6.14 pve-manager qemu-server ...
...

If the kernel was upgraded, reboot to boot into it:

root@pve1:~# reboot

One expected side effect: because this host has no subscription key, the web UI shows a "No valid subscription" dialog each time you log in. That is normal on the no-subscription repository — it is a notice, not an error, and nothing is broken. We cover it again in Troubleshooting.

Step 4: Networking — understand vmbr0

Proxmox does not attach VMs directly to your physical NIC. Instead the installer creates a Linux bridge called vmbr0, enslaves the physical interface to it, and puts the host's own IP on the bridge. A bridge behaves like a virtual switch: the host, every VM, and every container plug into it and share the uplink. This is why you configured the host IP as part of vmbr0 during install.

Inspect the current interfaces:

root@pve1:~# ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
enp1s0           UP
vmbr0            UP             192.0.2.10/24

Notice the physical interface enp1s0 has no IP of its own — it is a bridge port — while vmbr0 carries the address. The config lives in /etc/network/interfaces:

root@pve1:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

iface enp1s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.0.2.10/24
        gateway 192.0.2.1
        bridge-ports enp1s0
        bridge-stp off
        bridge-fd 0

The bridge-ports enp1s0 line is what enslaves the physical NIC to the bridge. For a first single-node host you rarely need to change any of this — the default bridge already carries VM and container traffic straight out to your network.

If you do edit this file (for example to add a second bridge or a VLAN-aware bridge), apply the change without a reboot. Proxmox ships ifupdown2, which gives you ifreload:

root@pve1:~# ifreload -a

Step 5: Storage basics

Proxmox abstracts disks into named storages, each of which is allowed to hold certain content types. A default install gives you two, and it helps to know what each is for. Run pvesm status:

root@pve1:~# pvesm status
Name             Type     Status     Total    Used  Available    %
local             dir     active   100.00G  35.00G     65.00G  35.00%
local-lvm     lvmthin     active   500.00G 200.00G    300.00G  40.00%

The two defaults split by purpose:

local is a directory-backed store on the host filesystem. It holds ISO images, container templates, and backups (and snippets) — files, essentially. This is where you upload install ISOs and download container templates.
local-lvm is an LVM-thin store. It holds VM disk images and container root volumes — block storage. This is where the actual virtual disks live.

So the rule of thumb is: ISOs and templates go on local; VM disks and container rootfs go on local-lvm. If you installed on ZFS instead of LVM, the second store is typically local-zfs (a zfspool store) rather than local-lvm, and it plays the same role — the block store for VM and container disks.

Step 6: Create your first VM

Now the payoff. We will build a KVM virtual machine from the command line so you can see exactly what each flag does. First, upload or download an install ISO for your guest OS onto the local storage — either through the web UI (local → ISO Images → Upload) or by dropping the file into /var/lib/vz/template/iso/ on the host. For this example we assume debian-13.5.0-amd64-netinst.iso is present on local.

Create the VM with qm create. This defines VM ID 100, two cores, 4 GiB of RAM, a modern virtio-scsi controller with a 32 GiB disk on local-lvm, and a virtio NIC bridged onto vmbr0:

root@pve1:~# qm create 100 --name web01 --cores 2 --memory 4096 \
  --scsihw virtio-scsi-single --scsi0 local-lvm:32 \
  --net0 virtio,bridge=vmbr0 --ostype l26

Attach the install ISO as a virtual CD-ROM and set the VM to boot from it:

root@pve1:~# qm set 100 --ide2 local:iso/debian-13.5.0-amd64-netinst.iso,media=cdrom \
  --boot order='ide2;scsi0'
update VM 100: -boot order=ide2;scsi0 -ide2 local:iso/debian-13.5.0-amd64-netinst.iso,media=cdrom

Start it:

root@pve1:~# qm start 100

qm start prints nothing on success. Confirm the VM is running with qm list:

root@pve1:~# qm list
      VMID NAME    STATUS   MEM(MB)  BOOTDISK(GB)  PID
       100 web01   running     4096         32.00  12345

Open the VM's Console in the web UI (noVNC) to finish the guest OS installation as you would on any physical machine. Because a KVM VM boots its own kernel, you can install any operating system here — another Linux, Windows, BSD, anything.

Step 7: Create your first LXC container

A container is the lighter-weight option. Instead of booting its own kernel, an LXC container shares the host's kernel and runs an isolated Linux userspace on top. It boots in a second or two, uses a fraction of the RAM, and packs far more densely onto the same box — the trade-off being that it must be Linux and is less isolated than a full VM. For a dozen small Linux services, containers let you run many more per host than VMs would.

Start by refreshing the template catalog and listing what is available:

root@pve1:~# pveam update
update successful

root@pve1:~# pveam available --section system
system          debian-12-standard_12.7-1_amd64.tar.zst
system          debian-13-standard_13.1-2_amd64.tar.zst
system          ubuntu-24.04-standard_24.04-2_amd64.tar.zst
...

Download a template to the local storage. Template point-revisions change over time, so check the list above for the current filename — here we use the Debian 13 standard template (e.g. debian-13-standard_13.1-2_amd64.tar.zst):

root@pve1:~# pveam download local debian-13-standard_13.1-2_amd64.tar.zst
downloading ...
download finished: local:vztmpl/debian-13-standard_13.1-2_amd64.tar.zst

Create the container with pct create. This is container ID 200, from that template, with a hostname, two cores, 2 GiB of RAM, an 8 GiB root volume on local-lvm, and a DHCP NIC bridged onto vmbr0:

root@pve1:~# pct create 200 local:vztmpl/debian-13-standard_13.1-2_amd64.tar.zst \
  --hostname ct01 --cores 2 --memory 2048 \
  --rootfs local-lvm:8 --net0 name=eth0,bridge=vmbr0,ip=dhcp

Start it and confirm:

root@pve1:~# pct start 200

root@pve1:~# pct list
VMID   Status     Lock  Name
200    running          ct01

Drop straight into a root shell inside the running container to configure it:

root@pve1:~# pct enter 200
root@ct01:~#

Type exit to return to the host. Notice how much lighter this was than the VM in Step 6 — a smaller memory footprint, an instant start, and no OS install to sit through. That density is the reason to reach for LXC when the workload is Linux and you do not need a separate kernel.

Step 8: Basic hardening

A hypervisor management plane on a public IP is a high-value target. Three changes get you most of the way on a single node.

1. SSH key-only authentication. Copy your public key to the host, then disable password login. Edit /etc/ssh/sshd_config:

root@pve1:~# sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
root@pve1:~# systemctl restart ssh

Confirm you can still log in with your key in a second terminal before you close your current session, so you do not lock yourself out. Leave root login by key enabled — Proxmox drives some tasks over SSH as root — but with passwords off, brute-forcing the account is no longer possible.

2. Enable the Proxmox firewall. Proxmox has a built-in firewall (pve-firewall, nftables/iptables-based) configurable at the datacenter, node, and VM/CT levels. It is off by default. Enable it at the datacenter level and on the node. In the web UI: Datacenter → Firewall → Options → Firewall: Yes, then pve1 → Firewall → Options → Firewall: Yes. When enabled, the host firewall blocks inbound traffic by default except the web GUI (8006) and SSH (22) from the local network — so make sure your management rules are in place before you turn it on remotely.

3. Restrict the web UI (port 8006) to admin IPs. The documented approach is an IPSet named management holding your allowed admin IP addresses; the built-in management rules then honour it. In Datacenter → Firewall → IPSet, create an IPSet called management and add your office or VPN IPs. Alternatively, bind the web UI to a single address by setting LISTEN_IP in /etc/default/pveproxy and restarting pveproxy:

root@pve1:~# systemctl restart pveproxy

If your host sits behind a network edge that already filters traffic — for example the always-on firewall and DDoS mitigation in front of a Serverside dedicated server — that is defence in depth on top of these host-level controls, not a replacement for them.

Verification

Run through this checklist to confirm the host is healthy and both workloads are up:

root@pve1:~# pveversion
pve-manager/9.2-1/2c8d7f3b (running kernel: 6.14.8-2-pve)

root@pve1:~# pvesm status
Name             Type     Status     Total    Used  Available    %
local             dir     active   100.00G  35.00G     65.00G  35.00%
local-lvm     lvmthin     active   500.00G 200.00G    300.00G  40.00%

root@pve1:~# qm list
      VMID NAME    STATUS   MEM(MB)  BOOTDISK(GB)  PID
       100 web01   running     4096         32.00  12345

root@pve1:~# pct list
VMID   Status     Lock  Name
200    running          ct01

Then browse to https://192.0.2.10:8006, log in, and confirm you can see web01 and ct01 in the server view with green (running) status. Open a shell in the container or a console on the VM and ping out to confirm networking through vmbr0 works. If all four commands and the web UI agree, you have a working Proxmox VE host.

Troubleshooting

"No valid subscription" dialog on login. Expected on the no-subscription repository. It is a notice, not a fault — nothing is disabled. It disappears if you buy and install a per-socket subscription key.
apt update fails with a 401 against enterprise.proxmox.com. You did not disable the enterprise repository. Add Enabled: false to /etc/apt/sources.list.d/pve-enterprise.sources (Step 3), make sure proxmox.sources with pve-no-subscription exists, then re-run apt update.
A VM or container has no network. Check that its NIC is bridged to the right bridge (--net0 ...,bridge=vmbr0) and that vmbr0 actually enslaves your live physical NIC (bridge-ports in /etc/network/interfaces). If the Proxmox firewall is on, confirm it is not blocking the guest's traffic at the datacenter, node, or VM/CT level.
pveam available or pveam download finds nothing. Run pveam update first to refresh the template catalog, then re-list. Template point-revisions also change — copy the exact filename from pveam available --section system rather than typing an old one.
Cannot reach https://<ip>:8006. Usually a firewall problem: either your admin IP is not in the management IPSet, or LISTEN_IP in /etc/default/pveproxy is bound to an address you are not connecting from. Get in over the IPMI/KVM console, widen the rule, and restart pveproxy.

Conclusion

You now have a working single-node Proxmox VE 9.2 host: installed from the ISO, pointed at the no-subscription repository and fully updated, with its bridge networking and storage understood, one KVM VM and one LXC container running, and basic hardening in place. From here you can grow — add more VMs and containers, set up Proxmox Backup Server for deduplicated backups, or add two more nodes to form a cluster with quorum and high availability.

If you would rather skip the manual ISO install altogether, Proxmox VE is available as a ready deployment image on Serverside — deployed in a couple of clicks to EPYC bare metal in under a minute, with always-on DDoS protection in front of the management plane and a KVM console if you ever do want to boot your own ISO.

And if you are still deciding whether Proxmox VE is the right hypervisor for you at all — versus VMware ESXi, XCP-ng, or Hyper-V — start with our bare-metal hypervisor guide, which walks the trade-offs before you commit a box to any one of them.