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 Home Tunnel 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. A host's key is pinned the first time we connect to it and a changed key is refused; that first contact is trusted once and logged, not verified against anything else, and we would rather say so than write “host-key verification” and leave it there.
  • 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.
  • Known vulnerabilities in what we build on fail the build. The portal's dependencies are checked against the public advisory databases on every change, and a known problem in a pinned version stops the release. Until 20 October 2026 that check ran but could not fail anything; see the sweep below.

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.

Our 20 October 2026 sweep: what we found

Seventeen days after the last review, a second pass over everything added since: end-to-end remote access, the camera relay, live dashboards for coding agents, phone lines, the new backup paths and CHAP's switch-back. Four reviewers read the code the way an attacker would, and we audited every dependency on every component. Here is what we found, in order of how much it mattered.

Fixed on 20 October

  • A read-only coding-agent key could have minted a Home Assistant token in your name. The broker decides whether a Home Assistant command is a read or a change by its name, and the command that issues a long-lived token carried none of the words that mark a change. A key allowed only to look at your home could have asked it for a ten-year token and then used that token directly, without Vome in the middle: outside the broker, the audit log and key revocation. We found no sign that any key did. Vome now refuses every credential-issuing command to every key, your home refuses them too (Vome 0.3.67), and a command the broker does not recognise now needs the configuration permission rather than the read one.
  • A CHAP standby through Vome carried your end-to-end key to us. A home with end-to-end remote access keeps the private key for its own name under Home Assistant's storage directory, and CHAP copied that directory with the rest. The one key that end-to-end access exists to keep from us was in the snapshot we hold. It is no longer copied, in either kind of pair, and a standby that takes over issues a certificate of its own (Vome CHAP 0.2.5). If you had end-to-end access on and a standby through Vome before 20 October, turning end-to-end access off and on again issues a fresh key.
  • One visitor could shut a home's end-to-end door. The limit on open connections to a home was per home, so a stranger holding sixty-four quiet connections kept everyone else out, the owner included, and a connection that went quiet was never closed. Each visitor now gets a share of the limit, and a connection that carries nothing for ten minutes is closed.
  • A misbehaving home could have grown our relay's memory without limit. The live-dashboard watch kept every state a home sent, whatever its size, in a process every home's link shares. A stored state is now capped, and so is the largest message a home may send.
  • A password with a quote in it reached the shell on the host that runs the hosted homes. The login flow that mints a sign-in for a guest link or the owner's fallback built its command in a way that a password containing a quote or a $( could break out of. Every password that goes through it is one Vome generated, so no customer could have put one there; it was a latent fault, not a reachable one. The command now carries no secret at all.
  • Smaller things. A file deletion your home refused was written to your audit log as allowed. The blog feed reflected the request's host header unescaped. Two browser headers were missing: pages now tell the browser not to send a Vome address on to a site you click through to, and that only our own pages may ask for the microphone. A tool description overstated how private a password it stored was.
  • The dependency check could not fail the build. Our build has audited the portal's dependencies against the public advisory databases since August, but the step was written so that a finding never stopped a release, while the file that pins them said it did. It fails now. The same audit updated the token library and the voice service's web framework, removed a library nothing used, and cleared every known advisory in the relay's and the coding-agent server's dependencies bar one that does not reach the code we run.

Fixed earlier this month, and not yet told here

  • Your Home Assistant password was in our host's command log (fixed 5 October). Each time a guest link was opened, or the owner's fallback sign-in ran, the password went into the log of commands run on the server that hosts the homes, in clear. The log is on our own server, readable by our staff only, and it is now redacted; we are purging the old entries. If you used guest links before 5 October and would rather not take our word for the purge, change the password of the Home Assistant user they sign in as.
  • Your personal key was visible to every user of your Home Assistant (fixed 5 October, Vome 0.3.64). It sat in an attribute of an owner switch, which any Home Assistant user, guests included, can read, and which Home Assistant's history records. Removed; but the history keeps the old states for ten days by default and a backup keeps them for good, so if anyone other than you can read your history or backups, make a new key on vome.io.
  • A read-only key could open a Matter commissioning window or remove the home's fabric (fixed 4 October). The same classifier as above, caught for Matter first.
  • Users marked “local network only” could sign in from the internet through Vome (fixed 4 October, Vome 0.3.57), because Home Assistant saw every visitor as local. They are refused now, on every path.
  • Hosted homes were running Vome add-ons months out of date (fixed 6 October), without the fixes above. Hosted homes now keep the add-on current.

Found, and not fixed yet

  • Rate limits are counted per worker process. The portal runs four, each keeping its own count, so a limit of 2,000 reads an hour is in practice up to four times that. Moving the count to shared storage is a deployment change we will make deliberately rather than in a sweep.
  • Backup copies off-site share one account. The scripts that copy backups to our storage box use the main account's key from both the live and the staging service; a sub-account per service is the right shape and the documentation already says so. Until then staging could, in principle, remove live's copies.
  • A visitor Vome has vouched for is not login-guarded at the end-to-end door. Someone holding a valid guest link or Vome sign-in could try Home Assistant passwords without the per-visitor block that strangers get. This mirrors how the ordinary hosted path works and is a choice, but we are reconsidering it.
  • Add-on updates are not pinned. A hosted home installs whatever the Vome repository publishes, so a compromise of that repository or the image registry would reach every hosted home within hours. That is the trust you place in any add-on repository, and we say so rather than imply otherwise.

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: 20 October 2026 (everything added since 3 October, and every dependency). 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.