Privacy Policy

Last reviewed: August 2026 · Effective immediately for the soft-launch period.

This policy describes what personal data VomeHome collects when you use the service at portal.vome.io and the hosted Home Assistant instances we provide, why we collect it, how long we keep it, and the rights you have under the EU GDPR (and the UK GDPR where that applies to you).

1. Who we are

VomeHome is operated by Andrew Lyeklint Hancock, trading as Vome ("we", "us") — a Swedish sole trader (enskild firma) based in Skåne, Sweden. We are the data controller for the personal data described in this policy. An aktiebolag (Vome AB) is planned; until then this sole firm is the controller. If you have questions about this policy or the data we hold about you, contact privacy@vome.io.

2. What we collect

GitHub profile data (when you sign in)

Your numeric GitHub user id, username, display name, primary email address, and the date your GitHub account was created. The creation date is used to apply the soft-launch trial gate.

Account & service data

The servers you create, their tier, status, VM assignment, HomeLink subnets and peer keys, custom domain settings, trial end timestamp, and any promo codes you have redeemed.

Audit & abuse data

Activity log entries (which routes you triggered, which servers you logged into, when promos were redeemed). The IP address used at sign-in and at promo-code redemption.

Operational data on your HAOS VM

Each Home Assistant instance is your own VM. The configuration, automations, history, recordings, and device data inside it are your data. We do not copy them out for our own use; we retain disk images while your service is active and during the grace window after a trial expires. Two features do read a slice of it, with your permission and for the thing you asked for — the health check and the assistant — and what each keeps is set out below.

Health check findings

When you run a health check, our code reads your instance and stores the findings — a severity, a category, a title, one line of measured evidence and a suggested fix. That evidence line can name an entity (sensor.back_door_battery) or quote one truncated example log line, because a finding that cannot point at anything is not worth reading. The raw states, history, logs and configuration it was computed from are not stored. Reports are yours to delete, and go with the server or the account.

Support conversations

The subject and messages of any support ticket or assistant conversation you open, including anything you paste into it, plus the quotes and access grants attached to it. These are kept so the thread makes sense next time you open it, and are deleted with your account.

Instance API audit log

When something acts on your Home Assistant through the portal — an API token you issued, a button in the panel, an action you confirmed in the assistant — we record who, which server, the method and path, whether it was allowed, and the response code. Not the body of the request, and not what your Home Assistant does on its own. This exists so that "what touched my house, and when?" has an answer.

Remote access log

When someone reaches your Home Assistant through a Vome address, we record what happened at our edge: the time, the address they came from, the hostname they used, the page they asked for, their browser's user agent, and whether we let them through, refused them or blocked them for repeated failed logins. Your own Home Assistant can also report the failed logins it saw, which is how an attempt from a device on your own network shows up at all. Repeated attempts are counted rather than listed. This exists because Home Assistant cannot answer the question itself — every visitor reaches it through us, so its own "invalid authentication" notification names our plumbing and not the person. Some of these addresses belong to people who are not our customers — a guest you let in, or a stranger trying passwords. We keep the lot for 30 days and then delete it, we show it only to the owner of that home, and we do not use it for anything else.

Device addresses

If you issue a device address for a phone or tablet, we store the name you gave it, when it was created and last used, and the addresses it was created and last used from — so you can tell which one to switch off. They go with the address they belong to, and with your account.

Email delivery log

The address, type and subject of service emails we send you, and whether they were delivered, so a missing email can be traced.

Billing data

Stripe processes payment details directly. We store the subscription identifier, plan tier, and renewal status — never full card numbers.

Public score cards

If you buy and publish a score card, we store its 0–100 score, three category labels, your optional public title, and aggregate page-load / “try yours” click counts. Findings, saved server names, visitor IP addresses, cookies and fingerprints are not stored with the card. You can unpublish and republish it; deleting your account removes it.

AI features (health report summary, the Vome assistant)

These two features send a small, specific payload to our AI sub-processor and store nothing of it. The health check sends the findings its own code produced — a severity, a category, a title, one line of measured evidence (which can name an entity or quote one example log line) and the suggested fix — plus the name you gave the server. The assistant sends the messages in that conversation, our own public guides, our public version-testing notes, and your server's name, state and reported versions. Your device states, history, configuration, automations, logs, media, backups, tokens and IP address are not sent. We do not store the request or write it to our logs; the reply is stored as part of your report or your ticket, where you can read and delete it. Every report page and every assistant thread links to a page showing the exact payload, field by field.

Optional contact data

If you ask us to email you about the service, we store the email address you provide for that one purpose, with consent.

3. Why we collect it & legal basis

4. How long we keep it

• Account records — for as long as your account exists, plus a short retention window after closure for fraud prevention.
• Suspended HAOS disks — retained for the configured grace period (currently 14 days) after a trial expires, then purged.
• Activity / audit logs — up to 12 months.
• Backups you opt to take — follow your server's configured retention settings; you can delete them at any time.
• Billing records — kept for the period required by tax / accounting law (typically up to 7 years).
• Health reports, tickets and audit entries — for as long as the server and account they belong to. Deleting a server deletes its reports, tickets, grants and audit entries with it.
• AI requests — not kept by us at all. The payload is built in memory when the feature runs and dropped when the answer arrives; it is not written to our database or our logs. The answer is kept as part of the report or ticket it belongs to, and goes when you delete that.

5. Who we share it with

We do not sell your data. The sub-processors we may share specific data with:

• GitHub — handles authentication when you sign in.
• Hosting providers — operate the physical hardware our portal and HA hosts run on (within the EEA / Sweden where possible).
• Stripe — processes card/SEPA payments. Stripe acts as an independent data controller for payment details.
• SMTP2GO — delivers our service and security emails (sign-in notices, scheduled maintenance, backup alerts). It receives the address we are writing to, the subject and the message; it is named here rather than described, because "an email provider" is not a name.
• Anthropic — writes the health report summary and the assistant's replies, through the Claude API. It receives only what is listed under “AI features” above. Anthropic's commercial terms state that inputs and outputs sent through their API are not used to train their models; they may hold a copy briefly for abuse monitoring under their own policy. See their commercial terms and privacy centre.

We may disclose data when legally required to do so (court order, lawful request from a regulator). We will tell you when this happens unless legally prevented from doing so.

6. International transfers

The portal and HA host servers are operated within the EEA / Sweden where possible. GitHub, Stripe, Anthropic and similar providers may process data in the US — these transfers rely on the EU Standard Contractual Clauses (and the UK International Data Transfer Agreement where UK GDPR applies) as appropriate.

7. AI features, in full

Most people run Home Assistant so that their home is not in somebody else's cloud, so this deserves more than a line in a table.

• Nothing happens on its own. The assistant runs when you send it a message or press a fix button. The health check offers a tick-box before it runs; untick it and the summary is written by our own code on our own server, with no request made at all — not a redacted one, none. You keep the findings either way, because the findings were never the AI's work.
• The findings are ours, not the model's. Our code decides what is wrong with your system; the model is only asked to write the finished findings up in plain English, and every number it states is checked back against them before you see it.
• You can read the exact request. Each report and each assistant thread links to a page that builds the payload using the same code that sends it, shows it in full, and explains every field. If we add a field and forget to explain it, that page says so.
• We keep no copy. Not in the database, not in the logs.
• It is not training data. See Anthropic under sub-processors above.

8. Your rights

Under the EU GDPR (and UK GDPR where it applies to you) you can:

• Access the personal data we hold about you ("right of access").
• Ask us to correct inaccurate data.
• Ask us to delete your account and personal data ("right to erasure"). This is a real deletion and not a flag: your servers and their settings, health reports and findings, support threads and their messages, quotes, access grants, API tokens, instance audit entries, activity log, assistant usage, published score cards and your address in our email log are all removed. Anything we later add that holds your data is covered by the same routine — there is a test that fails our build if a new table is not. Some records (e.g. billing, which lives at Stripe) may be retained under legal obligation.
• Object to processing based on legitimate interest.
• Withdraw any consent-based processing at any time, without affecting prior lawful processing.
• Request a portable export of your data.
• Lodge a complaint with the Swedish Authority for Privacy Protection (IMY), or with your local EEA supervisory authority (or the UK ICO if UK GDPR applies to you).

Two of them are buttons rather than requests: Your data (in the menu when you are signed in) downloads everything we hold about you as a JSON file, and closes your account — instances, reports, threads and all — when you type your own email address to confirm. Neither asks us for permission and neither asks you why.

For anything else, email privacy@vome.io. We aim to respond within one calendar month.

9. Cookies, and what a page loads

We use a small number of strictly-necessary cookies for sign-in (session cookie) and CSRF protection. We do not use advertising or cross-site tracking cookies, and there is no analytics script, tag manager or session recorder on this site. If we ever introduce optional analytics, you'll see a consent prompt first.

A page here also loads no files from anybody else. Every stylesheet, script and font we use is served from this domain, so opening a Vome page tells no third party that you did — not a CDN, not a font service, not an analytics host. This matters most on the pages you did not sign up for: open a score card somebody shared and your browser talks to us and nobody else.

Until August 2026 those files came from the public jsDelivr CDN, which meant your browser announced each page load to it. We found that in our own privacy sweep and vendored the files; our content security policy now permits no external host at all, so it cannot come back by accident.

10. Who at Vome can get in

Two doors, and both leave a record:

• You let us in. From a support ticket you can grant access to one server for a fixed number of hours (24, 48, 72 or a week). The grant carries its own expiry and use count, you can revoke it at any moment, and it lapses on its own if you forget.
• An administrator views the portal as you to reproduce a problem you have reported. That is portal pages, not a login to your Home Assistant, and every time it starts it is written to the activity log.

Nobody at Vome reads your automations, history or camera feeds as a matter of course, and nothing in the product does it in the background.

11. Security

The technical controls we apply (TLS, isolated VMs, HomeLink encryption, audit logs, rate limiting, etc.) are summarised on our Security page. No system is impervious; if you discover a vulnerability, please email security@vome.io rather than posting it publicly.

12. Changes to this policy

We'll update this page as the service evolves. Significant changes will be highlighted on the dashboard. The date at the top of this page is always current.