Anyone running multiple virtual machines on Proxmox VE will eventually face a simple question: In what order should the VMs boot up after a host restart? If the reverse proxy starts after the web services, they will be temporarily unreachable. If monitoring starts before the application services, the first checks will immediately trigger errors. With the right configuration, this can be avoided.

What Proxmox Can Do – and What It Can’t

Proxmox VE does not support true dependencies between VMs. There is no way to say: “Start VM B only when VM A has fully booted and is reachable.” What Proxmox offers instead is a simple start order with an optional delay value.

The principle:

• VMs are started in ascending order of the order value.
• Between starts, Proxmox waits for the configured up delay in seconds.
• During shutdown, the order is reversed.

This is sufficient for most scenarios—as long as the delay values are chosen generously enough.

Configuration Parameters

Each VM has three relevant fields under Options → Start/Shutdown Order:

Additionally, Start at boot (onboot) must be enabled for these settings to take effect when the host boots up.

Via CLI, it looks like this:

1

qm set 100 --onboot 1 --startup order=1,up=60

Organizing Infrastructure into Tiers

The most practical approach is to divide the VMs into logical start groups (tiers). Services that depend on others are given a higher order value.

Example Infrastructure

Assume the following VMs are running on the host:

The Start Order

Tier 1 – Network

Nothing works without a network. The firewall must come up first:

1

qm set 100 --onboot 1 --startup order=1,up=60

A 60-second delay gives OPNsense enough time to initialize routing tables and firewall rules.

Tier 2 – Reverse Proxy

A common mistake: starting the reverse proxy after the auth service. However, without the proxy, not a single website is reachable via HTTPS—including Authentik’s own login page. So, the proxy comes before everything else:

1

qm set 110 --onboot 1 --startup order=2,up=30

Tier 3 – Authentication / SSO

Only once the proxy is running can Authentik be reached via its domain. Many downstream services use Authentik as a login provider—therefore, it must be available early:

1

qm set 111 --onboot 1 --startup order=3,up=45

Tier 4 – Application Services

All other services can then follow in stages. Services without mutual dependencies get the same order value:

1
2

qm set 113 --onboot 1 --startup order=4,up=30
qm set 114 --onboot 1 --startup order=4,up=20

Tier 5 – Monitoring

Monitoring services like Icinga are deliberately placed at the end of the start order. If they started too early, they would immediately produce errors and alerts for all services not yet running. When Icinga boots last, all other VMs are already reachable and the first checks run cleanly:

1

qm set 112 --onboot 1 --startup order=5,up=15

Everything at Once with a Bash Script

Instead of configuring each VM individually, it can be done conveniently via a script. The script must be executed directly on the Proxmox host as root:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

#!/bin/bash

# Proxmox VM Autostart + Boot Order Setup

declare -A startup=(
  # Tier 1 – Network
  [100]="order=1,up=60"

  # Tier 2 – Reverse Proxy
  [110]="order=2,up=30"

  # Tier 3 – Auth / SSO
  [111]="order=3,up=45"

  # Tier 4 – Application Services
  [113]="order=4,up=30"   # synapse
  [114]="order=4,up=20"   # mastodon

  # Tier 5 – Monitoring
  [112]="order=5,up=15"   # icinga
)

for vmid in "${!startup[@]}"; do
  qm set "$vmid" --onboot 1 --startup "${startup[$vmid]}"
done

echo ""
echo "Done. ${#startup[@]} VMs configured."

Verifying the Configuration

After execution, the configuration of individual VMs can be easily verified:

1

qm config 100 | grep -E "onboot|startup"

Or for an overview of all VMs at once:

1
2
3
4
5

for vmid in $(qm list | awk 'NR>1 {print $1}'); do
  echo -n "VMID $vmid: "
  qm config "$vmid" | grep -E "onboot|startup" | tr '\n' ' '
  echo
done

Important Notes

• The up delay is not a guarantee. Proxmox waits the specified time before triggering the next VM—not until the current VM has fully booted. For slow services or storage-intensive VMs, choose generous values.
• No true dependencies. If you really want to ensure that Service A is fully running before Service B starts, you need external solutions—such as systemd units on the VMs themselves or an Ansible playbook after boot.
• Note the shutdown order. During shutdown, Proxmox automatically reverses the order. So the proxy shuts down last—which is usually what you want.
• Identical order values are allowed. VMs with the same order value are triggered simultaneously. This is useful for independent services that can start in parallel.

Conclusion

The boot order in Proxmox is not a complex feature, but with the right tier organization, you can achieve a stable start sequence that avoids unnecessary errors when the host boots up. The most important rule: Network → Proxy → Auth → Applications → Monitoring. Maintaining this as a script keeps the configuration versionable and reproducible at any time.