Security & Privacy at VomeHome

Infrastructure Model & Isolation

• Isolated HAOS VM per instance. Every customer instance is its own Home Assistant OS virtual machine (libvirt/QEMU) with 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.
• Layered network segmentation. User VMs run on an isolated host bridge (br-haos) with explicit iptables forwarding rules. Per-instance traffic is routed via portal-managed nginx maps and per-tenant WireGuard interfaces with their own routing tables.
• Least-shared architecture. The control plane (portal, billing, account management) is separated from customer runtime workloads (HAOS VMs on HA hosts). Admin operations are SSH-key authenticated and audit-logged.
• Deterministic rebuilds. Server recreation destroys and reprovisions VM resources rather than reusing unknown state, including a full network re-keying for WireGuard peers.

Transport & Encryption

• TLS everywhere. Portal and HA wildcard domains are served over HTTPS with HSTS and strict security headers.
• HomeLink VPN support. WireGuard and OpenVPN configurations are generated server-side and scoped per server.
• Backup encryption support. Backups support encryption-at-rest when `BACKUP_ENCRYPTION_KEY` is configured.

Identity & Access Control

• GitHub OAuth for sign-in. During the soft launch, account sign-in is gated through GitHub OAuth with CSRF-protected state and server-side verification of the returned email and account age. MFA inheritance follows your GitHub account settings.
• Session security. Sessions are signed, time-bounded (12 hours), and use HttpOnly, Secure, SameSite=Lax cookies. State-changing requests require valid CSRF tokens.
• Rate limiting. Authentication, redemption, and API endpoints are rate-limited to reduce brute-force and abuse risk.
• Ownership checks. Server actions are authorised against account ownership and active subscription/trial status server-side. Admin and user boundaries are enforced on every route.

One-Click Login

• Refresh-token based login bootstrap. One-click login uses a Home Assistant refresh token to obtain a short-lived access token on the HA domain.
• Same-origin token exchange. The token exchange runs in `/local/vome_login.html` on the HA server origin, so browser token storage is scoped to that HA instance.
• URL fragment transport. Bootstrap values are passed in the URL fragment (`#...`), which is not sent in HTTP request lines.
• Restricted host-side storage. HA credential files are stored per-server under /ha_users/<server_id> with restrictive file permissions.
• User control. One-click login can be disabled per server at any time.

Host Hardening

• Firewall-first posture. HA host networking uses explicit iptables forwarding/NAT rules per VM and persisted host firewall state.
• Intrusion prevention. Fail2Ban and host logs are used to detect and block abusive traffic patterns.
• SSH hardened. Operational access uses SSH keys and host-key verification to reduce MITM risk.
• Automated updates. Base OS packages are updated through host provisioning and operational maintenance routines.

Application Security

• Input validation. User input is validated before use in SQL queries, shell commands, and templates.
• Defensive defaults. Security headers, CSRF protection, and route-level authorisation checks are enabled by default.
• Automated testing. Changes are validated by automated tests and regression checks before release.
• Secret handling. Signing keys and service secrets are configured through environment/deployment config rather than source code.

Data Privacy & UK GDPR

• Your HA data stays yours. Operators do not access your Home Assistant automations, history, or device data unless you explicitly grant support access for a specific issue. Where we do (e.g. to investigate a fault), the access is logged.
• Minimal account data. We store only what we need to run the service: GitHub profile (username, display name, account creation date, email), server metadata, IP address used at sign-in / redemption (for abuse prevention), and audit logs of account-affecting actions. We do not sell or share this.
• Lawful basis. Account and billing data: contract performance. Audit/abuse logs: legitimate interest (running a safe service). Optional emails (e.g. "let me know when paid plans launch"): consent.
• Retention. Account records are kept while your account exists. Suspended HAOS disks are retained for the configured grace period and then purged. Audit logs are kept for up to 12 months. Backups follow per-server retention settings.
• Your rights. You can request access, correction, export, restriction, or deletion of your personal data, and withdraw any consent-based processing at any time. Contact privacy@vome.io. If you live in the UK or EEA, you can also complain to the Information Commissioner's Office (or your local supervisory authority).

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

Responsible Disclosure

If you believe you have found a security vulnerability in VomeHome, we encourage you to let us know right away. We will investigate all legitimate reports and do our best to fix the issue promptly.

Please email security@vome.io with details of the vulnerability. We ask that you give us reasonable time to address the issue before making any information public.