BETA — Open to testers. Tell us what to fix on @vomehome or via a tester code.

Security & Privacy at VomeHome

VomeHome runs the smart-home brain for private households, so security and privacy are core requirements, not optional extras. This page summarises how we protect your Home Assistant instance, account data, and network traffic — including the limits of what we can honestly claim.

For a plain-language overview of the personal data we hold, why we hold it, and your rights, see our Privacy Policy. To see the no-open-ports model rather than read about it, try the interactive how-it-works exhibits.

Isolation

  • One isolated Home Assistant OS virtual machine per instance. Independent disk, kernel, network identity, and lifecycle. Hardware is shared with other tenants the way it is on any reputable host; the HA stack itself is not.
  • Each instance has its own network stack. Every running instance sits in its own network namespace — its own routing table, bridge and interfaces — and the shared bridge they used to sit on has been retired. Previously they shared that bridge and a firewall rule kept them apart: real, and working, but a configuration rather than a separate stack, and one firewall reload rebuilt it without those rules and took four servers offline.

    Separate stacks are not the whole claim and we would rather say so than imply more. The host holds one connection into each instance, so it could route between them; what prevents that is a firewall table with a default of drop, kept deliberately apart from the general-purpose firewall — which is the one that got rebuilt. If that table goes missing, instances lose their connection to us rather than gaining one to each other. It cannot fail in the direction of joining them.

    We verify this by attempting it, from inside a tenant's own stack rather than by confirming a rule exists, with a control that makes a broken test report void instead of pass. Still in progress: the code that puts a newly created instance straight onto this design is written and tested but has not yet built one, and this runs on a single host. What we measured and rejected, and what this buys: how your server is kept apart.
  • Control plane and workloads are separate. The portal, billing, and account management do not run inside your Home Assistant. Admin access is SSH-key authenticated and audit-logged.
  • Rebuilds do not reuse unknown state. Recreating a server destroys and reprovisions the VM, including a full network re-keying for HomeLink peers.
Your home outbound tunnel no inbound ports Your HA VM own disk & kernel own network identity Other tenants dropped at the host not a shared HA
Shared hardware, separate machines. The interesting question is whether they can reach each other — they should not.

Identity & access

  • Sign-in is GitHub OAuth. CSRF-protected state, server-side verification of the returned email, and a check on account age to discourage throwaway sign-ups. Multi-factor authentication follows whatever you have set on GitHub — we do not add a second password of our own.
  • Sessions are short and boring. Signed, 12-hour cookies with HttpOnly, Secure, SameSite=Lax. State-changing requests need a valid CSRF token.
  • Rate limiting on authentication, redemption, and API endpoints.
  • Ownership is checked on the server for every action, against the account and an active subscription or trial. Admin and user boundaries are enforced on every route.

Auto-login to HA

  • Vome stores a Home Assistant login token for each hosted server — a refresh token issued during setup, not a password typed into the portal. That is what lets the dashboard open HA already signed in.
  • The exchange runs on the HA origin (/local/vome_login.html), so browser token storage is scoped to that instance.
  • Bootstrap values travel in the URL fragment (#…), which is not sent in HTTP request lines.
  • Host-side credential files live per server with restrictive permissions. Auto-login can be turned off on any server at any time; the portal then stops using the stored token and you sign in on Home Assistant yourself. To leave it off permanently, delete the refresh token in Home Assistant (your profile → Security → Refresh tokens). Turning the switch back on can mint a new one.

Host & application hardening

  • Firewall-first networking on the HA hosts, with explicit forwarding and NAT per VM.
  • Fail2Ban and host logs for abusive traffic patterns. Operational SSH uses keys and host-key verification.
  • Input is validated before it reaches SQL, shell commands, or templates. Security headers, CSRF, and route-level authorisation are on by default.
  • Secrets stay in deployment config, not in source. Changes go through automated tests before release.

Data privacy & GDPR

  • Your HA data stays yours. Operators do not access your automations, history, or device data unless you grant support access for a specific issue. Where we do, the access is logged.
  • Minimal account data. GitHub profile (username, display name, account creation date, email), server metadata, the IP used at sign-in or redemption (abuse prevention), billing identifiers once you pay, and audit logs of account-affecting actions. We do not sell or share this.
  • Lawful basis. Account and billing data: contract performance. Audit and abuse logs: legitimate interest (running a safe service). Optional emails: consent.
  • Retention. Account records while the account exists. Suspended HAOS disks for the configured grace period, then purged. Audit logs up to 12 months. Backups follow per-server retention.
  • Your rights. Access, correction, export, restriction, or deletion, and withdrawal of any consent-based processing. Contact privacy@vome.io. Complaints: the Swedish Authority for Privacy Protection (IMY), your local EEA authority, or the UK ICO where UK GDPR applies.

Full details, sub-processors, and contact information are in the Privacy Policy.

We check ourselves, and publish it

Twice a year we go through the whole product asking what we hold, who else sees it, and whether you can get all of it back — and we publish what we find, including the parts that were our fault. The first sweep found that deleting an account did not delete everything, that four things we store were missing from the policy, and that every page here told a CDN you had loaded it. All fixed, each one now with a test that fails our build if it comes back.

Read the August 2026 sweep — what we got wrong, what held up, and what is still on the list.

CHAP: your standby and your configuration

A CHAP standby is a copy of your Home Assistant, so it holds what your Home Assistant holds: logins, integration tokens, everything in .storage. Here is where that copy travels and who can read it.

Through Vome (a standby hosted by us, or a pair we watch)

  • Only your two installs take part. Each is paired with a single-use code that expires after 30 minutes and gets a credential of its own, stored by us only as a hash. Only the install running your home can send a configuration snapshot, and only its standby can fetch it.
  • One copy, kept briefly. We keep only the newest snapshot of each pair, as a file only the portal's service account can read; each new one replaces it. It travels over TLS. It is not encrypted with a key that only you hold: we could read it, and say so. If that matters to you, the local pair below keeps it in your house.
  • The first fill of a new standby is one backup of your apps' data, made under a key generated for it alone, and deleted on both installs and at Vome as soon as it has been restored.

Two installs in your house (the local pair)

  • Nothing goes to Vome. The two talk only to each other, on port 8177 of your house network, over TLS 1.3 keyed by the pairing code: nothing else on the network can connect or read it.
  • The code is for administrators. It is shown only on the Vome CHAP app's page in Home Assistant, which only administrators can open. Once the two are paired they switch to a key made for that pair, so an old code opens nothing.
  • Open to read. The app's source is public; the guide shows how it is set up.

What our October 2026 review found in it, and fixed, is below.

Our October 2026 review: what we found

We read the newest parts of Vome the way an attacker would: someone on your network, another app on your Home Assistant, a stranger filling in a form, and a hosted Home Assistant that is not behaving. Six things: five fixed on 1 October 2026 and one on 3 October.

  • The local pair's pairing code appeared in a Home Assistant notification, which every user of Home Assistant sees, not only administrators. A non-administrator with a machine on your network could have paired it and copied the configuration. It now appears only on the administrators' page (Vome CHAP 0.2.1).
  • A pairing code stayed valid for good, so one seen later could still fetch a copy or replace your standby. After pairing, the pair now uses a key of its own, and a second install with the code is turned away (Vome CHAP 0.2.1).
  • No size limits on what the other install could send, so a hostile machine with the code could have filled the disk. Snapshots are now capped, both through Vome and in the house (Vome CHAP 0.2.1).
  • The Vome app's panel answered any app on the same Home Assistant. Its port is not open to your network, but every app on a Home Assistant shares its internal network, and one could have called the panel directly — issued an agent key, unlinked the install — without the Home Assistant sign-in in front of it. The panel now answers only Home Assistant's own ingress (Vome 0.3.47).
  • Names went into our emails as markup: a VomeHire booker's name, a support ticket's subject, a Home Assistant's own name. A booker could have put a link of their choosing into a venue owner's email. Everything in an email's HTML is now escaped.
  • A hosted Home Assistant could reach internal services on our own servers. Our servers trust each other, and a hosted instance's traffic left the machine it runs on looking like that machine, so it could reach things the internet cannot: an admin page with no sign-in, and ports that only our own services should use. Nothing in an instance uses them, but nothing stopped one from trying. An instance can now reach our servers only on the public web ports, the same as anyone else, in both IPv4 and IPv6 (3 October 2026).

From Vome CHAP 0.2.1 the app keeps itself updated on both installs of a local pair; a pair made with 0.2.0 needs it updated once by hand on its standby.

AI agents & the Home Assistant API

VomeHome can give an AI coding agent scoped, audited access to your Home Assistant. The agent never receives a Home Assistant credential: it gets a revocable VomeHome token, and every read and write is brokered and policed server-side, so a read-only token genuinely cannot change anything. Locks, alarms, covers and similar sensitive domains are refused even with write access.

Read the full security review — the scope model, session isolation for the hosted endpoint, what we refuse, our August 2026 review findings, and the limitations we currently accept.

Responsible disclosure

If you believe you have found a security vulnerability in VomeHome, please tell us. We will investigate legitimate reports and do our best to fix the issue promptly.

Email security@vome.io with details. Give us reasonable time to address the issue before making any information public.

Last reviewed: 3 October 2026 (CHAP, the local pair, and what a hosted instance can reach). This page is updated as controls evolve. Tenant isolation moved to per-instance network namespaces on 28 August 2026; provisioning a brand-new instance onto it is written but not yet exercised.