eu-central-1 · fra1
Security & your customers’ data
Booth planning means names, roles, contact details and notes on what you discussed. That is other people’s data, held by you. This page states exactly how it is protected and who can reach it — so you can judge for yourself instead of taking our word for it.
Everything below is checked against the running production system.
Where your data is
- Database in Frankfurt
- PostgreSQL in AWS region eu-central-1 — Frankfurt, Germany.
- Application in Frankfurt
- The server code runs in region fra1, also Frankfurt. It used to run in Washington DC while the database was here; that meant personal data was processed in the United States on every request. We moved it. You can check the response header x-vercel-id yourself: it reads fra1::fra1.
- Nothing is processed outside the EU
- No analytics, no advertising trackers, no third-party scripts in the application.
Why one company cannot see another’s data
This is the part that matters most, so here is the mechanism rather than a slogan.
- The database refuses, not the code
- Every table has Row Level Security: PostgreSQL itself attaches a filter to each query, checking that the row belongs to a company you are a member of. It is not an if-statement in our application that we might forget — a mistake in the app cannot hand out rows the database will not release.
- All 22 tables, no exceptions
- Customers, meetings, visitor history, staff, rooms, rosters, travel, presence, preferences — every table carries it. We verify this against production rather than assuming it.
- Two independent locks
- On top of Row Level Security, the rights on each table are narrowed to what that table actually needs. Anonymous visitors hold nothing at all, and a signed-in account holds only the rights its work requires — it cannot empty a table, and it cannot delete from a table the application never deletes from. So a request is stopped twice, by two independent mechanisms. One mistake is not enough to expose anything.
- Separate environments
- Each company works on its own subdomain. Logging in with a valid account on someone else’s subdomain gives you no access — membership is checked per request.
Who can reach what
- An account per person
- No shared logins. Your administrator creates accounts and decides who is an administrator.
- Roles are enforced by the server
- Only administrators can add colleagues or delete a fair. Hiding a menu item is not security, so the server checks the role on every such action — not the browser.
- Deleting is deliberate
- Removing a fair takes every meeting with it, so it requires typing the fair’s name exactly, and the server checks that too.
- Passwords
- Stored only as a bcrypt hash — nobody, including us, can read your password. Changing it requires your current one, so an unattended open session is not enough to take over an account.
- Service-role access is rotated and logged
- One path in our own server code can bypass company isolation — used only for account management, the owner panel, and paging colleagues, always behind a role check. Every use is written to an audit log an administrator can read, and the key itself is rotated periodically, most recently in September 2026.
Encryption and backups
- Encrypted in transit
- HTTPS only, on every connection, with HTTP redirected.
- Encrypted at rest
- Disk-level encryption on the database and its backups (AES-256, managed by AWS in Frankfurt).
- Daily backups
- Made and retained by Supabase on the Pro plan, in the same European region.
- A copy of your environment every night
- On top of the platform backups above, BoothManager takes its own snapshot of every company each night. Your administrator can download it or put it back without us — no request, no waiting.
- Kept seven days by day, twelve months by month
- The last seven nights are kept, plus the final copy of each month for a year — because a fair deleted in January is often only missed in March.
- Restoring is deliberate, and recorded
- A restore puts rows back into live data, so it asks the administrator to type that copy’s own date and time, and the server checks it. It is then written to a log with their name. Administrators can read that log; no account can edit or erase a line.
Who else touches the data (subprocessors)
You are entitled to know this, so it is stated plainly rather than buried.
- Supabase — database, authentication
- Runs on AWS in Frankfurt. Supabase Inc. is an American company; the data itself does not leave the EU.
- Vercel — hosting the application
- Runs in Frankfurt. Vercel Inc. is an American company; the data itself does not leave the EU.
- Resend — calendar-sync mail (optional feature)
- Only touches mail for the optional calendar-sync feature: the invitation itself, and anything CC’d to a company’s own sync address. An American company — see “What is not in place yet” below for who that means can read it.
- Anthropic — AI business-card reading (optional, off by default)
- Only when a company administrator switches it on: the photo of a business card is sent to Anthropic, which reads the contact details and sends them back. This processing is not pinned to the EU — it runs in the USA or worldwide. BoothManager does not store the photo. With the switch off, cards are read on the phone itself and the photo never leaves it.
- Nothing else
- No analytics, no advertising, no CRM. The only other extras are the browser push service (Google/Apple/Mozilla, only when a colleague turns on notifications) the calendar-sync mail and the optional AI card reading above.
What is not in place yet
Stated openly, because you should hear it from us and not discover it later.
- Two-factor authentication is not required
- It can be switched on per account under personal settings, with a code from an authenticator app. We do not require it, so an account that leaves it off is protected by its password alone.
- No external audit
- No ISO 27001, no SOC 2, no pen test. BoothManager is young; we would rather say so than imply otherwise.
- Our nightly copies sit next to your live data
- They live in the same database as the environment they came from. That protects you against a mistake — a deleted fair, a wiped roster — not against the loss of the platform itself. For that there is the database provider’s point-in-time recovery, which we have not taken yet.
- Inbound calendar-sync mail passes through a shared mail account
- CC your BoothManager sync address on an invite, and it arrives through Resend, the shared mail provider behind that feature. Whoever has access to that Resend account can read the raw message — for up to 30 days, Resend’s own retention window — regardless of what BoothManager itself shows. Today that’s only us; Resend has no way to limit a team member to one customer’s mail.
Questions your security officer wants answered?
Ask. Anything on this page can be demonstrated in the running system.
← Back to home