Your data is hosted in Europe, and every processor is named.

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.

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, some processing happens in the United States: WhatsApp messages (Twilio), transactional email (Resend), billing (Stripe), and calls to AI providers for transcription, translation and task structuring. Those transfers rest on the EU Standard Contractual Clauses or the EU-US Data Privacy Framework, and every provider is named individually — with its 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 takes no guest identity from your PMS. The PMS integration reads room status and the next arrival and checkout to know which rooms need turning over. It does not copy guest names, contact details, payment data or booking records into Vabumi. Guest details reach Vabumi only if your staff enter them in a task, note, photo or voice message.

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 and data. Isolation is enforced in the API layer: CI fails any API route that has no auth or tenant check, and tracks the older routes still moving to the standard check. Postgres row-level security is enabled on the tables as defence in depth against direct database access; it is not what filters each API request. Group administrators get one login that switches between every property they have access to.

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, with email and password. Invitations arrive as a one-tap link.

All traffic is encrypted in transit (TLS). The database and object storage are encrypted at rest.

Staff who work only through WhatsApp are recognised by their registered phone number and have no password 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, and task structuring and routing. 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 first publishing it under the procedure in section 6 of the DPA.

If an AI provider is down, task extraction falls back to rules, and staff can always create and assign tasks by hand.

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 handled on request. Operational events — completions, routine instances, comments — are retained as part of the operational record, which is what makes the audit trail worth having.

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 plain words.