Your data stays in Europe, and out of the models.

Two locations, and we name both rather than waving at a continent. The production database, authentication and file storage run on Supabase in Zurich, Switzerland. The application servers and background workers run on Railway in Amsterdam, the Netherlands. Backups sit with the database.

Switzerland is not in the EEA. It holds an EU adequacy decision, which means personal data may be transferred there without additional safeguards — but it is not the same claim as “in the EU”, so we do not make that one. Supabase’s DPA additionally incorporates the EU, UK and Swiss Standard Contractual Clauses.

Beyond that, data leaves Europe only as transient calls to AI providers for transcription, translation and task structuring. Those calls run under data-processing agreements with explicit no-training commitments, and the providers are named individually — with their processing location and transfer mechanism — in Annex III of our DPA.

The site itself is operated by Vabumi OÜ, a company registered in Estonia. Estonian law governs the contract, and Estonian courts have jurisdiction.

Vabumi does not store guest personal data. The PMS integration reads occupancy and checkout to know which rooms need turning over, and writes clean status back. It does not copy guest names, contact details, payment data or booking records into Vabumi.

That is a design decision with a practical payoff: the smaller the personal-data footprint, the smaller your exposure, and the shorter the conversation with your DPO.

Each property is its own project, with its own spatial model, routines, staff and data. Isolation is enforced at the API layer — a membership check on every route — with Postgres row-level security policies underneath as a second, independent layer. Group administrators get one login that switches between properties; a property manager sees only their own.

Inside a property, permissions follow role: a two-tier system role (admin / member) plus operational roles tuned for hospitality — manager, housekeeper, front desk, F&B, janitor, worker — each with its own profile, and custom roles on top.

Sign-in is JWT-based through Supabase Auth: email and password, or magic link. Google Workspace and Microsoft 365 SSO are on the roadmap; SAML and SCIM provisioning are scoped separately.

All traffic is TLS 1.2 or higher. The database and object storage are encrypted at rest.

Staff who work only through WhatsApp and QR codes have no account and no credential to lose — which removes the single most common failure mode in operational software rolled out to a floor team.

AI is used for transcription, language detection, translation, task structuring and assignment suggestions. Every AI provider we send data to is listed by name in the DPA with the specific no-training commitment we rely on, quoted from that provider’s own terms. We do not paraphrase those commitments from memory, and we do not add a provider without the thirty-day notice procedure in section 6 of the DPA.

Every AI-assisted step has a manual fallback. Nothing in the operation depends on a model being available.

For the operational data your team enters, your organisation is the controller and Vabumi is the processor, under a Data Processing Agreement that takes effect when you accept our terms — there is no separate negotiation to schedule before you can start. For website visitors, account holders and billing, Vabumi is the controller; that is covered by the Privacy Policy.

Access, rectification, erasure and portability are supported through export and admin tooling. Operational events — completions, routine instances, comments — are retained as part of the operational record, which is what makes the audit trail worth having.

Automated backups and point-in-time recovery on managed Postgres in Zurich; retention windows depend on plan tier. Errors are monitored with Sentry across the API and the web app, and deploys are verified against the commit they claim to be.

What we do not have yet — a formal uptime SLA, an incident-response SLA, a published uptime history — is set out on the status page, in the same words we would use on a call.