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.
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.
Shared hardware, separate machines. The interesting question is whether they can reach each other — they should not.
No open ports & encryption
Nothing is forwarded in from the internet.
Remote access uses HomeLink: an outbound VPN from your house
to the hosted instance. The router still does the job routers
are for — refusing unsolicited inbound traffic.
L2 mode extends the house LAN itself when discovery and
Matter need a shared broadcast domain:
HomeLink L2.
The public Home Assistant URL can be closed.
Turning off “Open on the internet” makes
*.home.vome.io return 403. HomeLink still
reaches the instance. Away from home,
Let this network in admits the public IP the
portal is seeing until you revoke it. A verified custom
domain is gated the same way.
TLS everywhere on the public web.
The portal and Home Assistant domains are served over HTTPS
with HSTS and strict security headers.
HomeLink is per server.
WireGuard (and OpenVPN where needed) configurations are
generated server-side and scoped to that instance.
Backups can be encrypted at rest
on the way off the machine. Home Assistant's own backup
password — the emergency-kit one — is honoured on restore.
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.
One-click login
A Home Assistant refresh token is used to
mint a short-lived access token on the HA domain — not a
password pasted into the portal.
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. One-click login can be
disabled on any server at any time.
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.
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: 28 August 2026. This page is updated as controls evolve.
Tenant isolation moved to per-instance network namespaces on that date;
provisioning a brand-new instance onto it is written but not yet
exercised.