Should You Run Home Assistant on a VPS? An Honest Answer

Most guides to this treat it as a straightforward install, which is misleading. Home Assistant's core job is talking to devices on a local network, and a VPS is by definition not on one. Whether that matters depends entirely on what your smart home is made of, so this guide sorts integrations into what works, what cannot work at all, and what needs a tunnel back home, then describes the architecture that suits most setups better.

The honest answer is that it depends on what your smart home is made of, and for a large fraction of setups a VPS is the wrong host. That is not a limitation of the server. It is that Home Assistant's core job is talking to devices on a local network, and a VPS is by definition not on it.

MassiveGRID Ubuntu VPS: Ubuntu 24.04 LTS · Proxmox HA cluster with automatic failover · Ceph 3x replicated NVMe storage · 85+ metros across 30+ countries · 100% uptime SLA

Cloud VPS — from $1.99/mo
Backup services · Self-host Headscale for the VPN half of this

What Breaks, and What Does Not

Sort your integrations into three groups and the decision makes itself.

Works fine on a VPS. Anything that talks to a vendor cloud API over the internet: Tesla, Nest, Tuya, most weather and calendar integrations, energy tariff data, notification services. These do not care where Home Assistant runs.

Does not work at all. Anything needing a USB radio physically attached, which means Zigbee, Z-Wave, Thread and Bluetooth. You cannot plug a dongle into a server in Frankfurt. This is the group that eliminates the VPS for most people, because a Zigbee coordinator is the backbone of a typical setup.

Works only with a tunnel back home. Local network protocols: mDNS and SSDP discovery, ESPHome devices, local-only smart plugs, Chromecast, Sonos, printers, cameras on the LAN. These need a route into your home network, which is possible and covered below.

The Add-On Store Problem

A detail that catches people out and is rarely mentioned. Home Assistant ships in several forms, and only two of them have the add-on store.

Running the Container version means no add-on store, so Mosquitto, Zigbee2MQTT, ESPHome, Node-RED and the rest become containers you deploy and update yourself. That is entirely doable and it is more work than clicking install, and it is the actual cost of choosing this path.

Sizing

Home Assistant is modest. The database is what grows, because by default it records every state change of every entity.

Move the recorder to PostgreSQL and set a retention period, or SQLite will grow until the disk fills. Ten days of history covers most practical use, and long-term statistics are kept separately anyway:

recorder:
  db_url: postgresql://hass:password@127.0.0.1/homeassistant
  purge_keep_days: 10
  commit_interval: 5
  exclude:
    domains:
      - device_tracker
      - sun

Installing the Container

With Docker in place, from our Docker guide:

mkdir -p /opt/homeassistant/config

services:
  homeassistant:
    image: ghcr.io/home-assistant/home-assistant:stable
    container_name: homeassistant
    restart: unless-stopped
    environment:
      - TZ=Europe/London
    volumes:
      - /opt/homeassistant/config:/config
      - /run/dbus:/run/dbus:ro
    ports:
      - "127.0.0.1:8123:8123"

cd /opt/homeassistant && docker compose up -d
docker compose logs -f

Note the port binding to localhost. On a home network you would use host networking so discovery works; on a VPS discovery has nothing to find, so bind locally and put a proxy in front.

The Setting That Locks You Out

Behind a reverse proxy, Home Assistant must be told to trust it. Without this, every request appears to come from the proxy's address, so the login page rejects you or the brute-force protection bans your own proxy and locks everyone out.

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 127.0.0.1
    - ::1

Restart after adding it. Be precise about the addresses listed: trusting a broad range means any client can spoof its source address, which defeats the IP ban feature entirely.

Then the proxy, with WebSocket support, because the entire interface updates over one:

server {
    listen 443 ssl;
    http2 on;
    server_name home.example.com;

    ssl_certificate     /etc/letsencrypt/live/home.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/home.example.com/privkey.pem;

    location / {
        proxy_pass          http://127.0.0.1:8123;
        proxy_http_version  1.1;
        proxy_set_header    Upgrade $http_upgrade;
        proxy_set_header    Connection "upgrade";
        proxy_set_header    Host $host;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto $scheme;
    }
}

Reaching Devices at Home

For local devices, the VPS needs a route into your home network, and a VPN is the only sane way to provide it. Port-forwarding individual devices from a home router to the internet is how smart home equipment ends up in search engines for exposed devices.

WireGuard, or Tailscale and Headscale on top of it, gives the server an address on your home LAN. Our guide to self-hosting Headscale covers building that yourself, which has the pleasing property that the coordination server can live on the same VPS.

Two consequences to accept before relying on it. Local device control now depends on your home internet connection being up, and on the VPS being up, and on the tunnel being up. That is three dependencies where there was none. And every command travels to the datacenter and back, so a light switch has perceptible latency where before it had none.

Zigbee and Z-Wave With a Remote Server

There is one workable pattern. Keep the radio at home attached to a small local machine running Zigbee2MQTT or Z-Wave JS, and have it publish to an MQTT broker that the remote Home Assistant subscribes to.

Alternatively use a network-attached coordinator that presents the radio over Ethernet rather than USB, which removes the local machine but not the local hardware.

Either way you still have a device at home that must stay running, which undermines much of the reason for moving Home Assistant to a VPS in the first place. Worth recognising rather than discovering after buying.

The Pattern That Actually Works Better

For most people the better architecture inverts this. Run Home Assistant at home, on a small local machine next to the radios where it belongs, and use the VPS for the things a home connection does that badly:

Remote access. The VPS holds a public address and a valid certificate, and reaches the local instance over the VPN. No inbound ports on the home router, no dynamic DNS.

Off-site backups. Home Assistant snapshots pushed to the VPS, which is the copy that survives a fire or a theft.

The supporting services. An MQTT broker, Grafana for energy dashboards, or a database, on hardware with real uptime.

This keeps automations working when the internet is down, which for lights, locks and heating is not a minor consideration. It is the recommendation for the majority of setups, and it still uses a VPS.

So When Is a VPS Right?

When your integrations are predominantly cloud APIs and you have few or no local-protocol devices. When you want a dashboard and automations built on data from services rather than hardware. When you have no reliable place at home to run a server, or a connection too unstable to host anything. And for a second instance used for testing configuration changes against the real thing.

If your setup is a Zigbee mesh and a rack of ESPHome sensors, run it at home and put the VPS to work on access and backups instead.

Infrastructure Either Way

Both architectures want a server that stays up. As the primary host, an outage means automations stop. As the access and backup layer, an outage means losing remote control and off-site copies.

Every MassiveGRID VPS runs on a Proxmox high-availability cluster with automatic failover, and storage is Ceph with three-way replication across independent NVMe drives, so a snapshot archive is not sitting on one disk. A footprint of 85+ metros means the server can be near you, which matters when a tunnel round trip sits between a switch and a light.

Deploy a Cloud VPS from $1.99/mo, or compare requirements across applications in our self-hosted sizing guide.