8 First Things to Do After Installing Proxmox VE (2026)

A fresh Proxmox VE install boots, the web UI loads, and the first thing it shows is a popup about not having a valid subscription. Then apt update fails. Then you wonder if anything else is misconfigured before creating the first VM.

Most of what needs to happen after installing Proxmox isn’t dramatic. It’s a checklist of small fixes that turn a fresh host into one ready for actual VM workloads. The order matters: some steps depend on others (repos before updates, updates before package installs, firewall before exposing the host).

This guide walks through the 8 first things to do after installing Proxmox VE 9.1, in the order they should be done. Each step addresses a specific gap between the fresh installer state and a host ready for real workloads. Plan 30-45 minutes start to finish. For the install itself, see our Proxmox VE 9.1 installation guide.

Why this order matters

The 8 steps below build on each other. Repos must work before any updates can run. Updates must finish before new packages install correctly. Email alerts need a working host before SMTP relay testing makes sense. The firewall must be configured carefully or the web UI becomes unreachable.

Skipping ahead usually creates work later: a fresh install with the wrong repo set will fail every apt run, and chasing those errors takes longer than fixing the repo first. Operators who’ve done this several times tend to follow the same sequence because deviations cost more time than they save.

Who this checklist is for

This is for homelab and small-business Proxmox VE installs where the host runs in a private network or behind a router. The intended reader just finished the installer and sees the Datacenter view with the subscription popup.

Out of scope: enterprise multi-node clusters with paid subscriptions (you have the enterprise repo already), public-facing Proxmox hosts (need different firewall and TLS setup), automated provisioning via Ansible / Terraform (different config approach entirely).

For hardware context, see our mini PC for Proxmox guide. For broader platform comparison, see Proxmox vs ESXi Free 2026.

Step 1: Switch to the no-subscription repository

The first thing the web UI shows is “You do not have a valid subscription for this server.” This is informational — Proxmox runs without a subscription. The popup exists because the default repository configuration points to the enterprise repository, which requires paid credentials. The Proxmox wiki documents both repository options in detail.

Homelab users usually switch to the no-subscription repository immediately after installing Proxmox because the enterprise repository requires a paid subscription. Production environments may prefer the enterprise repo for more conservative update validation — package updates land there later, after additional testing.

For most homelab installs, switch to no-subscription. Open the web UI shell on the node, or SSH in:

Comment out the line by adding # at the start:

Save with Ctrl+O, exit with Ctrl+X.

Now add the no-subscription repository:

Paste this single line:

Save and exit. The same applies to the Ceph repository if Ceph isn’t being used. Comment out /etc/apt/sources.list.d/ceph.list to prevent apt errors.

Step 2: Suppress the subscription nag popup

The popup itself doesn’t change repository state, just hides the reminder. Skip this step if you’d rather keep the reminder visible.

The fix patches a single JavaScript file in the proxmox-widget-toolkit package. The patch needs to be reapplied after every Proxmox VE update that touches this package, so most homelab operators keep the one-liner handy.

Run on the host:

Refresh the web UI. The popup should be gone.

If a future update brings it back, run the same command. The .bak file is the original; keep it for reference.

Step 3: Run the first system update

With repositories fixed, run a full update:

full-upgrade is what Proxmox documentation recommends instead of upgrade. The difference: full-upgrade allows package removals when needed to resolve dependencies. On a fresh install with a clean state, upgrade would also work, but full-upgrade matches the official guidance.

Watch the output for kernel updates. If a new kernel package installs, a reboot is needed before the new kernel becomes active. Reboot when convenient:

After the reboot, verify the kernel:

Should show the newer kernel version. Old kernel files remain on disk for rollback. Proxmox keeps the last few in case the new kernel has problems. For ongoing update strategy (when to update, how to test, kernel rollback), see our Proxmox update guide.

Step 4: Verify time synchronization

Verify time sync early — wrong time silently breaks too many downstream services. Proxmox uses chronyd for time sync. On a fresh install it’s enabled by default, but some BIOS configurations or network setups break it silently. Wrong system time causes problems with certificates, log timestamps, and (for clusters) quorum.

Check chrony status:

Look at the “System time” line. It should show a small offset (microseconds or milliseconds). If it shows seconds or minutes off, time sync is broken.

Check which time servers are being used:

If the list is empty or all sources show “?” status, the configured NTP servers aren’t reachable. Edit /etc/chrony/chrony.conf and add reliable pool servers:

Restart chronyd:

Verify with chronyc sources again.

Step 5: Configure email alerts

Email alerts is an item operators routinely skip and regret later. The email address set during install is what Proxmox uses for system notifications: failed backups, disk health warnings, package update notifications, certificate expiration. By default Proxmox sends these via the local mail transport agent (postfix on Debian), which on a fresh install isn’t configured to actually deliver mail.

Homelab users usually configure postfix to relay through an external SMTP server (Gmail, Mailgun, ProtonMail bridge) because external SMTP relays are free or cheap and avoid running mail infrastructure.

For Gmail relay (requires an app password from the Google account):

Edit /etc/postfix/main.cf to point at the Gmail relay and enable SASL auth (Postfix documentation has the exact directives: relayhost, smtp_use_tls, smtp_sasl_auth_enable). Store the SMTP credentials in /etc/postfix/sasl_passwd, then:

Test by sending yourself a message:

If the message arrives, alerts work. If it doesn’t, check journalctl -u postfix for errors.

Step 6: Set basic firewall rules

The firewall configuration is one of the more nuanced steps because it’s easy to over-configure and lock yourself out. Proxmox includes a built-in firewall that operates at three levels: datacenter, node, and VM. By default it’s disabled. Most homelab setups don’t strictly need it (the router provides the perimeter), but enabling it adds defense in depth.

Homelab users usually enable the datacenter firewall in passive mode initially because aggressive rules can lock out the web UI. Production environments may prefer enforcing strict rules from day one with documented exceptions.

In the web UI: Datacenter → Firewall → Options:

• Set Firewall to Yes
• Set Input Policy to DROP (everything blocked unless allowed)
• Keep Output Policy at ACCEPT (host can reach outbound)

Now add rules to allow access. Datacenter → Firewall → Add:

• Direction: in
• Action: ACCEPT
• Source: your LAN subnet (e.g., 192.168.1.0/24)
• Destination: leave empty
• Protocol: tcp
• Dest. port: 8006 (web UI)
• Enable: checked

Add a similar rule for SSH (port 22). Apply changes.

Before exposing Proxmox to the internet

This isn’t an action — it’s a warning about something not to do. A common temptation after the install works: expose port 8006 through the router so the web UI is reachable from anywhere. Don’t.

The Proxmox web UI was designed for trusted networks. It uses a self-signed certificate by default, has no built-in brute-force protection on the auth endpoint, and exposes a control plane that can wipe VMs and reconfigure storage. Public exposure invites credential-stuffing bots within hours.

Homelab users usually keep the management UI on the local network and reach it via VPN when away because that single change eliminates roughly 90% of the attack surface.

The realistic options for remote access:

• WireGuard or Tailscale VPN — simplest, most secure
• SSH tunnel to the host, then access web UI via localhost:8006
• Reverse proxy (Nginx, Caddy) with auth, rate limiting, and IP allowlist — more setup, more risk if misconfigured

Whatever the choice, the management UI should not be a port-forward away from the open internet.

Step 7: Back up the /etc/pve config directory

Config backup is one of the most underrated steps. /etc/pve is where Proxmox stores all cluster configuration, VM definitions, container definitions, user permissions, and firewall rules. It’s a virtual filesystem (pmxcfs) backed by an SQLite database, so it can’t be backed up by a normal cp. A tar of the mounted contents works for restore purposes on the same host.

Quick backup to a different disk or share:

This captures all definitions in a recoverable form. Having the backup itself takes seconds and saves hours of reconstruction if the database gets corrupted. For ongoing backup strategy covering VM data (the actual disks), see our backup strategy guide.

Step 8: Disable IPv6 only if your network truly doesn’t use it

This step is the most easily wrong of all. Older Proxmox tutorials often recommend disabling IPv6 as routine hygiene. That advice is outdated and potentially harmful now. Many ISPs already run dual-stack networks, container ecosystems increasingly assume IPv6 availability, and some Proxmox features integrate better when both stacks work. If unsure whether your network uses IPv6, leave it enabled.

To check whether IPv6 is actually in use:

If only ::1 localhost appears, IPv6 isn’t routed on the LAN. The ISP’s router admin UI confirms whether dual-stack is active upstream. If both internal network and ISP are pure IPv4, disabling makes sense:

Add at the end:

Apply without reboot:

The minor startup delays of an unused IPv6 stack don’t justify breaking future services that quietly assume IPv6 availability. When in doubt, leave it alone.

Snapshots are not backups

One of the most expensive Proxmox lessons new operators learn the hard way: a VM snapshot is not a backup. Get clear on the difference before relying on either.

Snapshots in Proxmox (whether ZFS, LVM-thin, or qcow2) live on the same storage as the running VM. If the storage fails, both the VM and all its snapshots disappear together. If the host crashes hard, snapshots may not be replayable. If a ransomware payload runs inside a VM and notices snapshots exist, it can delete them.

What snapshots are good for:

• Rolling back a failed update inside a VM (minutes to recover)
• Testing risky configuration changes before commit
• Point-in-time consistency during fast operations

What snapshots are not:

• Disaster recovery (storage failure = everything gone)
• Long-term retention (snapshot chains degrade VM performance on some backends)
• Off-site protection (still on the same physical host)

A real backup writes VM data to different storage that can be physically separated from the host. Proxmox Backup Server, vzdump to NAS, or ZFS send to a separate pool: any of these qualify. Snapshots alone don’t. For the full backup strategy breakdown, see our backup strategy guide.

Common issues after installing Proxmox

Even with these steps followed in order, a few patterns show up repeatedly in Proxmox forum threads from new installs.

apt update fails with “Could not resolve ‘enterprise.proxmox.com'”. The enterprise repo line wasn’t commented out (Step 1) and the no-subscription repo file wasn’t added. Re-check /etc/apt/sources.list.d/.

Subscription popup returns after a package update. The patch from Step 2 was overwritten when proxmox-widget-toolkit got updated. Re-run the sed command and restart pveproxy.

Locked out of web UI after enabling firewall. Datacenter input policy is DROP but no rule allows your IP. Recovery: physical or IPMI console, then pve-firewall stop. Fix rules, then re-enable.

Time drift after a few days. Chronyd wasn’t running or NTP servers were unreachable. chronyc tracking shows the actual offset.

No emails arriving. Postfix relay is wrong, or Gmail app password expired, or destination is filtering as spam. Check journalctl -u postfix for the actual error message.

Next steps

The host is now stable, updated, and ready for VM workloads. Several immediate next steps follow naturally:

• Update strategy — when to update, how to test, kernel rollback: Proxmox update guide
• RAM sizing — how much RAM Proxmox actually needs versus what the docs say: RAM sizing guide
• Storage architecture — ZFS vs LVM-thin vs Ceph for production-like homelabs: storage architecture guide

For platform context, see our What is Proxmox VE explainer and ESXi to Proxmox migration guide.